Ethernet/IPv4/TCP: net_receive & net_reply in server mode

[zephyrbot]

Reported by Flavio Santes:

net_reply does not work when net_receive's timeout is >= 200.

Steps to reproduce (based on echo_server):

1. Download the attached tar.gz.
2. Modify the IP address according to your configuration.
3. Compile and do everything necessary to run the binary on a Galileo Dev Board.
4. Use telnet to send some text to the application. Watch what happens when the timeout is above 150.

NOTE:

• Some applications may require a higher timeout.
• Timeout can be set to something below 150. However, sometimes even with a timeout below 150, net_reply does not work.

(Imported from Jira ZEP-469)

[zephyrbot]

by Flavio Santes:

• server_bug.tar.gz (size: 1778)

[zephyrbot]

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.

[zephyrbot]

by Flavio Santes:

Read last comment in GH-2041.

[zephyrbot]

by Jaakko Hannikainen:

This is fixed with 2880, which is now merged in the main tree.

[zephyrbot]

by Jaakko Hannikainen:

Flavio, the fixes have been merged, can this be closed?

[zephyrbot]

by Flavio Santes:

Jaakko Hannikainen As you pointed out, GH-2041 is fixed. However, in server-mode this issue is still present.

[zephyrbot]

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.

[zephyrbot]

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.

[zephyrbot]

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.

[zephyrbot]

by Andrei Laperie:

Per last comment, assigning to Flavio

[zephyrbot]

by Mark Linkmeyer:

Flavio Santes , what's the latest status? Please provide update in comments. Thx.

[zephyrbot]

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

[zephyrbot]

by Flavio Santes:

Mark Linkmeyer : IMHO, this issue must be assigned to the IP stack maintainers.

[zephyrbot]

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.
Anas Nashif

[zephyrbot]

by Flavio Santes:

Workaround applied to solve this issue must be documented. There is a Jira describing IP stack documentation issues: GH-1754

[zephyrbot]

Blocks GH-2015