I think this functionality is rather useful for more than LWMAC. I need something like this in ContikiMAC as well.
Would it make sense to move this deduplication to the _recv function in https://github.com/RIOT-OS/RIOT/blob/master/sys/net/gnrc/link_layer/netdev/gnrc_netdev_ieee802154.c ?

In IEEE 802.15.4, the (source address, sequence number) tuple should be enough to determine if a packet is a dup, since the standard specifies that the sequence number (DSN) shall increment on each new packet transmitted, but not for retransmissions.

In IEEE 802.15.4, the (source address, sequence number) tuple should be enough to determine if a packet is a dup, since the standard specifies that the sequence number (DSN) shall increment on each new packet transmitted, but not for retransmissions.

That is it, agreed. But not enough, see below.

Would it make sense to move this deduplication to the _recv function in https://github.com/RIOT-OS/RIOT/blob/master/sys/net/gnrc/link_layer/netdev/gnrc_netdev_ieee802154.c ?

That is a good idea, but I currently foresee it maybe a little bit complicated if we merge this functionality into gnrc_netdev_ieee802154.c. The reason is that, if we want to do so, we may need a timeout module for gnrc_netdev_ieee802154.c. Why we need a timeout module? Because, there is a possibility that: in case (1) node-A firstly sends a data with a sequence number of (e.g.,) 0x25 to node-B; (2) then, node-A turns to send 255 packets to other nodes (not node-B); (3) node-A again turns to send a new packet to node-B with a sequence of exactly 0x25 (the same as the last one it sends to node-B); then, in case that node-B didn't receive any packet since the last time node-A sent to it, node-B will drop this packet (regarded as duplicate packet) while it shouldn't.

The only way to avoid this bug is that, node-B should understand that, the two packets, both from node-A, both with sequence 0x25, are not the same packet, which we should use some kind of timeout window tool to differentiate them, i.e., we only regard the two packets are the same in a narrow time window.

Would it make sense to move this deduplication to the _recv function in https://github.com/RIOT-OS/RIOT/blob/master/sys/net/gnrc/link_layer/netdev/gnrc_netdev_ieee802154.c ?

Or rather invest in the future and do it as a follow-up to #7409 instead ;-).

By the way, just to make it clear. ;-) the issues I mentioned here, for unicast and broadcast, are not the same, they are two different problems. This PR solves LWMAC duplicate bcast packet problem that I guess many low duty-cycle MACs will encounter. LWMAC doesn't have duplicate unicast packet problem due to its preamble-preambleACK-data transmission scheme.

@zhuoshuguo I think your example is a classical case of over-complicating the situation. For a MAC protocol this might be something to consider, but just as a measure of keeping duplicated packets at bay this sounds like overkill (or: if a wrong packet get's accidentally in dropped in a corner-case: so what, upper layers may resend). Also: since @gebart is proposing to add this to the recv of the IEEE 802.15.4 glue-code to GNRC, you also still can add a timing-based implementation for a MAC protocol.

@miri64 @gebart So, let me build a new PR for adding duplicate packet check for rev of IEEE 802.15.4? ;-)

@miri64 @gebart So, let me build a new PR for adding duplicate packet check for rev of IEEE 802.15.4? ;-)

I can do that as well, as a follow-up to #7409.

OK, so I leave it to you. ;-)

Done. See #7577

(or 787dff1 just for the change ;-))

Off-topic: lwMAC needs to be ported to gnrc_netif2 at some point as well (but let's merge it first).

I guess with #7577 in place and #7895 already merged, I think we can close this one. Re-open if you disagree.

Hi, Martine. Actually, I would like to keep this PR. I understand that #7577 does solve similar problems, but not completely for LWMAC broadcasting.
The reason is quite tricky:
there is a possibility that, especially in dense network,

S-1: |-Wakeup-|----------sleep-------------| D |-------------sleep-----------
                                             |
                                             v
R   : |-Wakeup-|----------sleep-------------|-Wakeup-|----------sleep-------------|
S-2: |********* broadcasting period **********|

sender-1 may wake up to the receiver's (second wakeup, in the above figure) wake-up period and sends its data just ahead of a repeated packet from sender-2 to the receiver (refresh the sequence number recorded in #7577 ). In this case, #7577 will not work to release the duplicate broadcast packet from sender-1, while the revisions in this PR can. I totally understand that this case is with little chance, and rarely to happen. But, it did happens sometimes..

I know I may be over-complicating again... :-\

Ok, then can you maybe base this PR on the other one?

Yes, definitely, I need to rebase.

But, actually I am not sure how sensitive I should be when dealing with this kind of problems. Since, #7577 has already eliminated a very hug portion of the duplicate problem. So, maybe we can close this PR, without costing extra memory introduced by this PR. It depends on how careful we want LWMAC to be when dealing with duplicate broadcast packets. :-)

Do as you like it best :-)

OK, so let me keep it here. :-)

@zhuoshuguo now that you are leaving, are there any plans for this PR?

Ping @zhuoshuguo?

@miri64 Will handle it soon~

@miri64 Rebased~

Ping~ locally tested through on samr21-xpro boards, it works for the designed bcast feature.

Needs rebase again... Sorry :(.

Ping @zhuoshuguo?

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. If you want me to ignore this issue, please mark it with the "State: don't stale" label. Thank you for your contributions.