-
Notifications
You must be signed in to change notification settings - Fork 6.6k
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.
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
Ethernet/IPv4/TCP: net_receive & net_reply in server mode #2016
Comments
by Flavio Santes:
|
by Jaakko Hannikainen: Adding fiber_yield() between receiving and sending a packet seems to fix this. Adding a yield to the net_reply() code would probably also fix GH-2041 (though, it would then yield always before sending...). I'll test it around and try to send the patch today. |
by Flavio Santes: Read last comment in GH-2041. |
by Jaakko Hannikainen: This is fixed with 2880, which is now merged in the main tree. |
by Jaakko Hannikainen: Flavio, the fixes have been merged, can this be closed? |
by Flavio Santes: Jaakko Hannikainen As you pointed out, GH-2041 is fixed. However, in server-mode this issue is still present. |
by Jaakko Hannikainen: Could you clarify the 'watch what happens' part? I'm right now seeing different kinds of unexpected behavior (corrupted packets & a segfault) when sending multiple packets at once. If I send packets one-by-one and wait for responses, the connection seems to work fine. |
by Jaakko Hannikainen: Looks like the crash is actually an application error due to misuse of ip_buf_unref. See receive_and_reply() in the echo server sample to see how the tcp packet handling should work. Still, looks like there is something going on in the ip core if it gets hit by multiple packets at once, occasionally the application replies with corrupted packets - even to ACKs telnet sends for them. |
by Flavio Santes: Jaakko Hannikainen thank you. I will review again my code and I will update the Jira's description if I found something more specific. |
by Andrei Laperie: Per last comment, assigning to Flavio |
by Mark Linkmeyer: Flavio Santes , what's the latest status? Please provide update in comments. Thx. |
by Flavio Santes: According to the last comment from Jaakko: "Still, looks like there is something going on in the ip core if it gets hit by multiple packets at once, occasionally the application replies with corrupted packets - even to ACKs telnet sends for them." We are still observing the behavior.described by Jaakko. Workaround: we are increasing the number of buffers. See comments at https://gerrit.zephyrproject.org/r/#/c/3936 |
by Flavio Santes: Mark Linkmeyer : IMHO, this issue must be assigned to the IP stack maintainers. |
by Mark Linkmeyer: Andrei Laperie , it seems this is circling back to you. I haven't dug into the details of what this is about. I'm just trying to ensure it gets driven to the Closed state by getting it properly assigned. Please see the comment history and let me know who owns driving it to closure. |
by Flavio Santes: Workaround applied to solve this issue must be documented. There is a Jira describing IP stack documentation issues: GH-1754 |
Blocks GH-2015 |
Reported by Flavio Santes:
net_reply does not work when net_receive's timeout is >= 200.
Steps to reproduce (based on echo_server):
NOTE:
(Imported from Jira ZEP-469)
The text was updated successfully, but these errors were encountered: