QEMU networking: CONFIG_NET_TESTING breaks things, echo_server IPv6 address is "wrong"


Paul Sokolovsky
 

Hello,

Taking a chance, I'd like to start with drawing attention to
https://jira.zephyrproject.org/browse/ZEP-687 "docs:
Subsystems/Networking section is almost empty". Zephyr networking
information currently is sparse, disperse, bits are out of date, and
there're omissions/inconsistencies. Just linking a wiki landing
page from the official docs and letting community fill in that wiki
would be a good first step.

Anyway, waiting for real hardware support, I decided to give QEMU
networking a try. After some moderate googling, I arrived at
https://gerrit.zephyrproject.org/r/gitweb?p=net-tools.git;a=summary and
https://wiki.zephyrproject.org/view/Networking-with-Qemu . The initial
outcome: nothing works.

On a 3rd day of fiddling, with a following patch to echo_server it
finally worked:

--- a/samples/net/echo_server/prj_slip.conf
+++ b/samples/net/echo_server/prj_slip.conf
-CONFIG_NET_TESTING=y
+CONFIG_NET_TESTING=n
diff --git a/samples/net/echo_server/src/echo-server.c b/samples/net/echo_server/src/echo-server.c
index deb0d98..9ceef46 100644
--- a/samples/net/echo_server/src/echo-server.c
+++ b/samples/net/echo_server/src/echo-server.c
-#define MY_IPADDR { { { 0x20, 0x01, 0x0d, 0xb8, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0x1 } } }
+#define MY_IPADDR { { { 0x20, 0x01, 0x0d, 0xb8, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0x2 } } }

Commentary: Both
https://gerrit.zephyrproject.org/r/gitweb?p=net-tools.git;a=blob;f=README;h=38c74ad4e186794d8598f2cd0cb0302b0c0316ea;hb=HEAD
and
https://gerrit.zephyrproject.org/r/gitweb?p=net-tools.git;a=blob;f=loop-slip.sh;h=43ba09f04e592c734f992a34cbc46a4034f18b5b;hb=HEAD
configure host's side of tun interface with address 2001:db8::1, but
that's also what echo-server uses, so no talk between them.

That's however a 2nd in row issue, because with CONFIG_NET_TESTING=y, an
application thread doesn't really receive any packets, apparently due to
app's address being configured as IN6ADDR_ANY_INIT (or something else,
few minutes of looking at this NET_TESTING thing isn't enough to say
what it's doing).

In the nearby thread, Rohit Grover reported issues with getting echo on
a real hardware, so I wonder if CONFIG_NET_TESTING=y may be involved
too.

That's the source code side of the issue, another is documentation.
Both net-tools/README and the wiki page above omit some details to get
a virtual network set up seamlessly.


So, I'm not sure what the exact issue is. I may imagine following
might happen:

1. There was a simple CONFIG_NET_TESTING, for things like echo_server.
2. Later, it was made into a separate module, but echo_server possibly
wasn't updated to play with the new module well.
3. net-tools and wiki page predate CONFIG_NET_TESTING altogether.

The obvious question is what to do in this situation. I'm personally
keen to update https://wiki.zephyrproject.org/view/Networking-with-Qemu
to describe a setup which actually works now (this is mostly doing
steps in the right order, but also building with CONFIG_NET_TESTING=n).


Thanks,
Paul

Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linaro
http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog


Flavio Santes <flavio.santes@...>
 

Hello

Hello,

Taking a chance, I'd like to start with drawing attention to
https://jira.zephyrproject.org/browse/ZEP-687 "docs:
Subsystems/Networking section is almost empty". Zephyr networking
See also https://jira.zephyrproject.org/browse/ZEP-188

information currently is sparse, disperse, bits are out of date, and
there're omissions/inconsistencies. Just linking a wiki landing
page from the official docs and letting community fill in that wiki
would be a good first step.
Agree

Anyway, waiting for real hardware support, I decided to give QEMU
networking a try. After some moderate googling, I arrived at
https://gerrit.zephyrproject.org/r/gitweb?p=net-tools.git;a=summary and
https://wiki.zephyrproject.org/view/Networking-with-Qemu . The initial
outcome: nothing works.
There is support for real hardware, see:
https://gerrit.zephyrproject.org/r/gitweb?p=zephyr.git;a=blob;f=samples/net/dns_client/prj_galileo.conf

There is also a driver for enc28j60, see:
https://jira.zephyrproject.org/browse/ZEP-291
https://www.olimex.com/Products/Modules/Ethernet/ENC28J60-H/resources/ENC28J60-H.pdf

On a 3rd day of fiddling, with a following patch to echo_server it
finally worked:

--- a/samples/net/echo_server/prj_slip.conf
+++ b/samples/net/echo_server/prj_slip.conf
-CONFIG_NET_TESTING=y
+CONFIG_NET_TESTING=n
diff --git a/samples/net/echo_server/src/echo-server.c
b/samples/net/echo_server/src/echo-server.c
index deb0d98..9ceef46 100644
--- a/samples/net/echo_server/src/echo-server.c
+++ b/samples/net/echo_server/src/echo-server.c
-#define MY_IPADDR { { { 0x20, 0x01, 0x0d, 0xb8, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0x1 } }
}
+#define MY_IPADDR { { { 0x20, 0x01, 0x0d, 0xb8, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0x2 } }
}

Commentary: Both
https://gerrit.zephyrproject.org/r/gitweb?p=net-tools.git;a=blob;f=README...
and
https://gerrit.zephyrproject.org/r/gitweb?p=net-tools.git;a=blob;f=loop-s...
configure host's side of tun interface with address 2001:db8::1, but
that's also what echo-server uses, so no talk between them.

That's however a 2nd in row issue, because with CONFIG_NET_TESTING=y, an
application thread doesn't really receive any packets, apparently due to
app's address being configured as IN6ADDR_ANY_INIT (or something else,
few minutes of looking at this NET_TESTING thing isn't enough to say
what it's doing).

In the nearby thread, Rohit Grover reported issues with getting echo on
a real hardware, so I wonder if CONFIG_NET_TESTING=y may be involved
too.

That's the source code side of the issue, another is documentation.
Both net-tools/README and the wiki page above omit some details to get
a virtual network set up seamlessly.


So, I'm not sure what the exact issue is. I may imagine following
might happen:

1. There was a simple CONFIG_NET_TESTING, for things like echo_server.
2. Later, it was made into a separate module, but echo_server possibly
wasn't updated to play with the new module well.
3. net-tools and wiki page predate CONFIG_NET_TESTING altogether.

The obvious question is what to do in this situation. I'm personally
keen to update https://wiki.zephyrproject.org/view/Networking-with-Qemu
to describe a setup which actually works now (this is mostly doing
steps in the right order, but also building with CONFIG_NET_TESTING=n).


Thanks,
Paul

Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linaro
http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog
Regards,
Flavio


Paul Sokolovsky
 

On Wed, 17 Aug 2016 20:19:06 -0000
"Flavio Santes" <flavio.santes(a)intel.com> wrote:

Hello

Hello,

Taking a chance, I'd like to start with drawing attention to
https://jira.zephyrproject.org/browse/ZEP-687 "docs:
Subsystems/Networking section is almost empty". Zephyr networking
See also https://jira.zephyrproject.org/browse/ZEP-188

information currently is sparse, disperse, bits are out of date, and
there're omissions/inconsistencies. Just linking a wiki landing
page from the official docs and letting community fill in that wiki
would be a good first step.
Agree

Anyway, waiting for real hardware support, I decided to give QEMU
networking a try. After some moderate googling, I arrived at
https://gerrit.zephyrproject.org/r/gitweb?p=net-tools.git;a=summary
and https://wiki.zephyrproject.org/view/Networking-with-Qemu . The
initial outcome: nothing works.
There is support for real hardware, see:
https://gerrit.zephyrproject.org/r/gitweb?p=zephyr.git;a=blob;f=samples/net/dns_client/prj_galileo.conf

There is also a driver for enc28j60, see:
https://jira.zephyrproject.org/browse/ZEP-291
https://www.olimex.com/Products/Modules/Ethernet/ENC28J60-H/resources/ENC28J60-H.pdf
Yes, thanks, I meant for Ethernet support in FRDM-K64F which I have on
my hands now.

[]

The obvious question is what to do in this situation. I'm personally
keen to update
https://wiki.zephyrproject.org/view/Networking-with-Qemu to
describe a setup which actually works now (this is mostly doing
steps in the right order, but also building with
CONFIG_NET_TESTING=n).
I've made first pass of changes to
https://wiki.zephyrproject.org/view/Networking-with-Qemu , ordering
connection bring up steps properly and adding a bit more info here and
there. Going to look into CONFIG_NET_TESTING in more detail before
adding suggestion to disable it in the wiki.


--
Best Regards,
Paul

Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linaro
http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog


Maureen Helm
 

-----Original Message-----
From: Paul Sokolovsky [mailto:paul.sokolovsky(a)linaro.org]
Sent: Thursday, August 18, 2016 10:43 AM
To: Flavio Santes <flavio.santes(a)intel.com>
Cc: devel(a)lists.zephyrproject.org
Subject: [devel] Re: Re: QEMU networking: CONFIG_NET_TESTING breaks
things, echo_server IPv6 address is "wrong"

On Wed, 17 Aug 2016 20:19:06 -0000
"Flavio Santes" <flavio.santes(a)intel.com> wrote:

Hello

Hello,

Taking a chance, I'd like to start with drawing attention to
https://jira.zephyrproject.org/browse/ZEP-687 "docs:
Subsystems/Networking section is almost empty". Zephyr networking
See also https://jira.zephyrproject.org/browse/ZEP-188

information currently is sparse, disperse, bits are out of date, and
there're omissions/inconsistencies. Just linking a wiki landing page
from the official docs and letting community fill in that wiki would
be a good first step.
Agree

Anyway, waiting for real hardware support, I decided to give QEMU
networking a try. After some moderate googling, I arrived at
https://gerrit.zephyrproject.org/r/gitweb?p=net-tools.git;a=summary
and https://wiki.zephyrproject.org/view/Networking-with-Qemu . The
initial outcome: nothing works.
There is support for real hardware, see:
https://gerrit.zephyrproject.org/r/gitweb?p=zephyr.git;a=blob;f=sample
s/net/dns_client/prj_galileo.conf

There is also a driver for enc28j60, see:
https://jira.zephyrproject.org/browse/ZEP-291
https://www.olimex.com/Products/Modules/Ethernet/ENC28J60-
H/resources/
ENC28J60-H.pdf
Yes, thanks, I meant for Ethernet support in FRDM-K64F which I have on my
hands now.
Can you share?

[]

The obvious question is what to do in this situation. I'm personally
keen to update
https://wiki.zephyrproject.org/view/Networking-with-Qemu to describe
a setup which actually works now (this is mostly doing steps in the
right order, but also building with CONFIG_NET_TESTING=n).
I've made first pass of changes to
https://wiki.zephyrproject.org/view/Networking-with-Qemu , ordering
connection bring up steps properly and adding a bit more info here and there.
Going to look into CONFIG_NET_TESTING in more detail before adding
suggestion to disable it in the wiki.


--
Best Regards,
Paul

Linaro.org | Open source software for ARM SoCs Follow Linaro:
http://www.facebook.com/pages/Linaro
http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog


Paul Sokolovsky
 

On Wed, 17 Aug 2016 17:26:39 +0300
Paul Sokolovsky <Paul.Sokolovsky(a)linaro.org> wrote:

[]

So, I'm not sure what the exact issue is. I may imagine following
might happen:

1. There was a simple CONFIG_NET_TESTING, for things like echo_server.
2. Later, it was made into a separate module, but echo_server possibly
wasn't updated to play with the new module well.
3. net-tools and wiki page predate CONFIG_NET_TESTING altogether.

The obvious question is what to do in this situation. I'm personally
keen to update
https://wiki.zephyrproject.org/view/Networking-with-Qemu to describe
a setup which actually works now (this is mostly doing steps in the
right order, but also building with CONFIG_NET_TESTING=n).
Ok, mystery [seems to be] solved. The default setup of
echo_server/echo_client is tailored towards running QEMU-QEMU
communication, as described in samples/net/README. However, QEMU-Host
setup is definitely regressed. Moreover, CONFIG_NET_TESTING, with all
its addresses flip-floppig, appears to be needed exactly for QEMU-QEMU
case, and only complicates matters for QEMU-Host case.

Proposed/done items:

1. Done: https://wiki.zephyrproject.org/view/Networking-with-Qemu now
describes both QEMU-Host and QEMU-QEMU cases.
2. Done: QEMU-Host includes instructions on patching echo_server to make
net-tools to work as is.
3. Suggestion: Update CONFIG_NET_TESTING's description in Kconfig to
clearly state that it's pertinent to (only) QEMU-QEMU setup.
4. Suggestion: For all test apps not running in QEMU-QEMU mode,
standardize of 2001:db8::1 to be host side, and 2001:db8::2 to be
device side (eb it QEMU or physical device).
5. Suggestion: Apparently, add separate prj_*.conf's to run samples in
QEMU-QEMU vs QEMU-Host mode.

Jukka, your comments would be appreciated.


--
Best Regards,
Paul

Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linaro
http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog


Jukka Rissanen
 

Hi Paul,

On Thu, 2016-08-18 at 22:46 +0300, Paul Sokolovsky wrote:
On Wed, 17 Aug 2016 17:26:39 +0300
Paul Sokolovsky <Paul.Sokolovsky(a)linaro.org> wrote:

[]


So, I'm not sure what the exact issue is. I may imagine following
might happen:

1. There was a simple CONFIG_NET_TESTING, for things like
echo_server.
2. Later, it was made into a separate module, but echo_server
possibly
wasn't updated to play with the new module well.
3. net-tools and wiki page predate CONFIG_NET_TESTING altogether.

The obvious question is what to do in this situation. I'm
personally
keen to update
https://wiki.zephyrproject.org/view/Networking-with-Qemu to
describe
a setup which actually works now (this is mostly doing steps in the
right order, but also building with CONFIG_NET_TESTING=n).
Ok, mystery [seems to be] solved. The default setup of
echo_server/echo_client is tailored towards running QEMU-QEMU
communication, as described in samples/net/README. However, QEMU-Host
setup is definitely regressed. Moreover, CONFIG_NET_TESTING, with all
its addresses flip-floppig, appears to be needed exactly for QEMU-
QEMU
case, and only complicates matters for QEMU-Host case.
Yes, your analysis is correct. The CONFIG_NET_TESTING was setup so that
we could automate the qemu-qemu testing. Unfortunately the
documentation about this was not very clear as you noticed.


Proposed/done items:

1. Done: https://wiki.zephyrproject.org/view/Networking-with-Qemu now
describes both QEMU-Host and QEMU-QEMU cases.
2. Done: QEMU-Host includes instructions on patching echo_server to
make
net-tools to work as is.
Thanks a lot for these.

3. Suggestion: Update CONFIG_NET_TESTING's description in Kconfig to
clearly state that it's pertinent to (only) QEMU-QEMU setup.
Yes, I can send a patch for clarifying this.

4. Suggestion: For all test apps not running in QEMU-QEMU mode,
standardize of 2001:db8::1 to be host side, and 2001:db8::2 to be
device side (eb it QEMU or physical device).
Right now the assumption has been that the server role device has been
set to 2001:db8::1 and the client is 2001:db8::2 but we can change this
of course. It probably simplifies things if the host side is
2001:db8::1 and device side is 2001:db8::2.

5. Suggestion: Apparently, add separate prj_*.conf's to run samples
in
QEMU-QEMU vs QEMU-Host mode.
True, that is definitely needed.


I can prepare proper patches for these unless you have already
something prepared in which case just send them to gerrit. Thanks for
you feedback!


Cheers,
Jukka


Jukka Rissanen
 

On Fri, 2016-08-19 at 09:57 +0300, Jukka Rissanen wrote:
Hi Paul,

On Thu, 2016-08-18 at 22:46 +0300, Paul Sokolovsky wrote:

On Wed, 17 Aug 2016 17:26:39 +0300
Paul Sokolovsky <Paul.Sokolovsky(a)linaro.org> wrote:

[]



So, I'm not sure what the exact issue is. I may imagine following
might happen:

1. There was a simple CONFIG_NET_TESTING, for things like
echo_server.
2. Later, it was made into a separate module, but echo_server
possibly
wasn't updated to play with the new module well.
3. net-tools and wiki page predate CONFIG_NET_TESTING altogether.

The obvious question is what to do in this situation. I'm
personally
keen to update
https://wiki.zephyrproject.org/view/Networking-with-Qemu to
describe
a setup which actually works now (this is mostly doing steps in
the
right order, but also building with CONFIG_NET_TESTING=n).
Ok, mystery [seems to be] solved. The default setup of
echo_server/echo_client is tailored towards running QEMU-QEMU
communication, as described in samples/net/README. However, QEMU-
Host
setup is definitely regressed. Moreover, CONFIG_NET_TESTING, with
all
its addresses flip-floppig, appears to be needed exactly for QEMU-
QEMU
case, and only complicates matters for QEMU-Host case.
Yes, your analysis is correct. The CONFIG_NET_TESTING was setup so
that
we could automate the qemu-qemu testing. Unfortunately the
documentation about this was not very clear as you noticed.



Proposed/done items:

1. Done: https://wiki.zephyrproject.org/view/Networking-with-Qemu
now
describes both QEMU-Host and QEMU-QEMU cases.
2. Done: QEMU-Host includes instructions on patching echo_server to
make
net-tools to work as is.
Thanks a lot for these.


3. Suggestion: Update CONFIG_NET_TESTING's description in Kconfig
to
clearly state that it's pertinent to (only) QEMU-QEMU setup.
Yes, I can send a patch for clarifying this.


4. Suggestion: For all test apps not running in QEMU-QEMU mode,
standardize of 2001:db8::1 to be host side, and 2001:db8::2 to be
device side (eb it QEMU or physical device).
Right now the assumption has been that the server role device has
been
set to 2001:db8::1 and the client is 2001:db8::2 but we can change
this
of course. It probably simplifies things if the host side is
2001:db8::1 and device side is 2001:db8::2.


5. Suggestion: Apparently, add separate prj_*.conf's to run samples
in
QEMU-QEMU vs QEMU-Host mode.
True, that is definitely needed.


I can prepare proper patches for these unless you have already
something prepared in which case just send them to gerrit. Thanks for
you feedback!
Patches for these items can be now found in
https://gerrit.zephyrproject.org/r/#/c/4199/


Cheers,
Jukka


Paul Sokolovsky
 

Hello Jukka,

On Fri, 19 Aug 2016 14:37:10 +0300
Jukka Rissanen <jukka.rissanen(a)linux.intel.com> wrote:

[]


I can prepare proper patches for these unless you have already
something prepared in which case just send them to gerrit. Thanks
for you feedback!
Patches for these items can be now found in
https://gerrit.zephyrproject.org/r/#/c/4199/
Thanks for proceeding with these, I didn't have anything on my side,
nor think I know enough of Z networking to prepare changes which would
blend well, so thanks for going forward on your side. I'll have a look
at them today/on Monday.

Cheers,
Jukka


--
Best Regards,
Paul

Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linaro
http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog


Paul Sokolovsky
 

Hello Jukka,

On Fri, 19 Aug 2016 14:37:10 +0300
Jukka Rissanen <jukka.rissanen(a)linux.intel.com> wrote:

[]


Patches for these items can be now found in
https://gerrit.zephyrproject.org/r/#/c/4199/
I appreciate all the improvements done to networking documentation and
testing setup via the above and other patches during this week. There're
also some further concerns/issues, which I initially shared in
post-review comments to https://gerrit.zephyrproject.org/r/#/c/4200/ ,
and would like to duplicate here so they weren't lost:

* QEMU-host networking now works out of the box, but changes for that
regressed QEMU-QEMU case. I attempt to fix that in
https://gerrit.zephyrproject.org/r/4358 , but it needs review for
changes it does regarding NETWORKING_WITH_15_4 option.

* #4199, #4200 above went to "net" branch. Any ETA/plan for merging
them to master? My guess they went to "net" to avoid (incomplete)
changes soon before 1.5.0 release, but would be nice to get an
official ack.

* Finally, the latest one: I tried QEMU networking with qemu_cortex_m3,
and it doesn't work where qemu_x86 does. Which makes me wonder if
networking with qemu_cortex_m3 is supported/known to have worked at
all.


Thanks,
Paul

Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linaro
http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog