General 802.15.4/CC2538 RF driver dislikes fast ACKs

[Gr3yh0und]

Hey,
I'm using two CC2538DK, one with the gnrc_border_router fw and another with my own. However as soon as I configure both with the AUTOACK and ACK_REQ options I get problems when I am sending packets fast.
E.g. when I send two packets immediately from the client to the router, the router/slip only sends one ACK for the second packet.

Has anyone tested that?

[roberthartung]

Quick notice: the same happened to me on the AT86RF2XX where I tried to send packages as fast as possible which resulted in missing Interrupts and strange behaviours.

[Gr3yh0und]

Thanks for the feedback, so it looke like a more general issue. I am currently on the 2017.04 Release (as additional information).

[smlng]

FYI: the cc2538 does not handle ACKs, they are currently filtered out - cause the device cannot handle them, which has to be done in a software MAC layer.

In general, you get strange behaviour when sending either to fast, i.e., lots of small packets or large packets that get fragmented by 6LoWPAN for instance.

[Gr3yh0und]

It looks like the cc2538 is able to do hardware acks - or am I mistaken? I don't have much experience on that field but Contiki and OpenThread are simply setting the RFCORE_XREG_FRMCTRL0_AUTOACK which is according to here responsible for sending hw acks. Maybe thats a way how to do it as well in RIOT?

[smlng]

IIRC that's the case in RIOT as well, if a frame with ACK flag set is received the cc2538 sends an ACK back. The problem is rather the other way around, when the cc2538 sends a frame with ACK flags set and the receiver sends an ACK back, the cc2538 does not have any routines to handle the ACK internally but would pass it up to the (software) driver, that is RIOT. Currently, there is no software MAC for the cc2538 enabled that would handle such ACKs.

Please also see #5869 and reference discussion in their for further information on this.

[Gr3yh0und]

Ah thanks, for the heads up. Now I'm getting it and it makes sense though.

[stale]

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.

[PeterKietzmann]

IMO this is still present so I'm reopening it. @jia200x I'm mentioning you just so you're aware of this.