Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

General 802.15.4/CC2538 RF driver dislikes fast ACKs #7304

Closed
Gr3yh0und opened this issue Jul 3, 2017 · 15 comments
Closed

General 802.15.4/CC2538 RF driver dislikes fast ACKs #7304

Gr3yh0und opened this issue Jul 3, 2017 · 15 comments
Assignees
@roberthartung
Labels
Area: drivers Area: Device drivers Area: network Area: Networking Type: bug The issue reports a bug / The PR fixes a bug (including spelling errors)

Comments

@Gr3yh0und
Copy link

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
Copy link
Member

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
Copy link
Author

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

@Gr3yh0und Gr3yh0und changed the title CC2538 RF driver dislikes fast ACKs General 802.15.4/CC2538 RF driver dislikes fast ACKs Jul 4, 2017
@smlng
Copy link
Member

smlng commented Jul 5, 2017

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
Copy link
Author

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
Copy link
Member

smlng commented Jul 11, 2017

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
Copy link
Author

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

@smlng smlng added Area: drivers Area: Device drivers Area: network Area: Networking labels Jul 13, 2017
@PeterKietzmann PeterKietzmann mentioned this issue Jul 31, 2018
Closed
46 tasks
@stale
Copy link

stale bot commented Aug 10, 2019

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.

@stale stale bot added the State: stale State: The issue / PR has no activity for >185 days label Aug 10, 2019
@stale stale bot closed this as completed Sep 10, 2019
@PeterKietzmann
Copy link
Member

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

@stale stale bot removed the State: stale State: The issue / PR has no activity for >185 days label Oct 22, 2019
@PeterKietzmann PeterKietzmann mentioned this issue Oct 22, 2019
Closed
80 tasks
@miri64 miri64 added the Type: bug The issue reports a bug / The PR fixes a bug (including spelling errors) label Oct 22, 2019
@miri64
Copy link
Member

miri64 commented Oct 22, 2019

Given #7304 (comment) this might be related to #11256.

@jia200x
Copy link
Member

jia200x commented Oct 23, 2019

Given #7304 (comment) this might be related to #11256.

IMO that completely explains the problem. The framebuffer gets a lot of IO operations with soft ACKs

@roberthartung
Copy link
Member

@miri64 I would be happy to run some tests on this!

@jia200x jia200x mentioned this issue Nov 13, 2019
Closed
14 tasks
@miri64
Copy link
Member

miri64 commented Jul 1, 2020 •
edited
Loading

@miri64 I would be happy to run some tests on this!

waits several month with reply @roberthartung That would be great!

@miri64 miri64 added this to the Release 2020.07 milestone Jul 1, 2020
@MrKevinWeiss MrKevinWeiss removed this from the Release 2021.07 milestone Jul 15, 2021
@maribu
Copy link
Member

maribu commented Sep 16, 2022

ping?

@miri64
Copy link
Member

miri64 commented Sep 19, 2022

Could have been solved with the move to 802.15.4 HAL. However, this should be tested. @jia200x maybe?

@jia200x
Copy link
Member

jia200x commented Sep 19, 2022

this is definitely not present anymore, as we have performed severe stress tests and never saw an issue like that.
I propose to just close this one.

@maribu maribu closed this as completed Sep 19, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@roberthartung roberthartung

Labels
Area: drivers Area: Device drivers Area: network Area: Networking Type: bug The issue reports a bug / The PR fixes a bug (including spelling errors)
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
8 participants
@miri64 @Gr3yh0und @jia200x @maribu @roberthartung @PeterKietzmann @smlng @MrKevinWeiss