Networking samples are not able to connect with the TCP under qemu_x86 after 9b055ec

[ozhuraki]

Describe the bug

The echo_client sample is not able to connect with the TCP under qemu_x86 after 9b055ec

To Reproduce

Console 1:

$ cd net-tools.git
$ sudo ./net-setup.sh

Console 2:

$ cd net-tools.git
$ sudo ./echo-server -i zeth

Console 3:

$ cd samples/net/sockets/echo_client
$ mkdir build; cd build
$ cmake -DBOARD=qemu_x86 -DCONFIG_NET_IPV6=n -DCONFIG_NET_UDP=n -DOVERLAY_CONFIG="overlay-e1000.conf;overlay-linux.conf" ..
$ make run

Expected behavior

The echo-client is able to connect to the echo-server .

Environment (please complete the following information):

OS: Linux
Toolchain Zephyr SDK 0.11.2
Commit SHA eac56e4

Additional context:

Reverting 9b055ec fixes the problem.

[jukkar]

This is not a networking issue but qemu one.

[pfalcon]

Spotted that too.

[pfalcon]

On my quick look, it affects all server-side samples (i.e. ones which accept connections).

[pfalcon]

@carlescufi added the area: Networking label 1 hour ago
This is not a networking issue but qemu one.
@jukkar jukkar removed the area: Networking label 1 hour ago

Well, maybe it's not networking issue, but it's definitely an issue which affects networking, and AFAIK, that's the purpose of the labels - to enumerate areas affected by some ticket. So let me kindly re-add the Networking label.

If you think that's not the intended use of label, let's bring up the discussion of the dev mailing list.

[andrewboie]

I think we probably need to revert this patch until we can better figure out what's going on.

If it's just the server-side apps, we could perhaps look at a more targeted way to enable icount that excludes them.

It would be really good to know why enabling icount makes this fall over.

It would also be good to create a test which could reveal this issue in CI runs, rather than catching us by surprise, but I don't know if that's feasible.

cc: @wentongwu @stephanosio

[jukkar]

If it's just the server-side apps, we could perhaps look at a more targeted way to enable icount that excludes them.

In my tests, the echo-server running in qemu worked for small packets but failed to receive large packets. All echo-client connections from qemu failed.

[pfalcon]

If it's just the server-side apps,

Well, I find it more comfortable to connect from Linux box to Zephyr box, so I almost always run server-side apps for testing. @ozhuraki reported the issue for echo_client, which is the client sample. That's why I changed the title to just "networking samples", as both types appear to be affected.

[pfalcon]

In my tests, the echo-server running in qemu worked for small packets but failed to receive large packets.

I ran stuff like echo/echo_async/dumb_http_server, and universally saw RST packets from Zephyr. (Which is hard to explain indeed, how QEMU icount option could cause that.)

[pfalcon]

It would also be good to create a test which could reveal this issue in CI runs, rather than catching us by surprise, but I don't know if that's feasible.

I'm working on that from our side. Would be interesting indeed if what I have on my hands so far will catch it.

[pfalcon]

I'm working on that from our side. Would be interesting indeed if what I have on my hands so far will catch it.

Ah damn, I actually work with real hardware (frdm_k64f), skipping qemu so far due to complexity with TAP setup, etc.

[andrewboie]

Just an idea @stephanosio had, can you try removing the sleep=off in boards/x86/qemu_x86/board.cmake and see if that improves anything?

[wentongwu]

I think we probably need to revert this patch until we can better figure out what's going on.

If it's just the server-side apps, we could perhaps look at a more targeted way to enable icount that excludes them.

It would be really good to know why enabling icount makes this fall over.

It would also be good to create a test which could reveal this issue in CI runs, rather than catching us by surprise, but I don't know if that's feasible.

cc: @wentongwu @stephanosio

AFAIK icount will not work if there is communication (like TCP, layer2, etc.) between systems that depends on timer, because they are really two different time standard, icount only give deterministic output for icount enabled system self.