Hello Richard,

Let me start with saying that I agree that Zephyr networking does have
issues. They say that any bug is shallow given enough eyes, and Zephyr
networking clearly lacks enough eyes. So, I was in about the same
situation as you 2 weeks ago - after working on other things and
holidays, I was back to networking, and trying to do something I faced
1st, 2nd, 3rd, 4th, etc. issue in row. Well, I took care to report
them, fix which I could, research the other, ping other folks who work
on networking, etc. I'm happy to report that after these 2 weeks, I see
visible improvements, thanks to both core team's and contributors'
work.

So, please join the party - we definitely need more eyes and hands.

Please see below.

On Wed, 8 Feb 2017 13:39:06 +0100
Richard Peters <mail@richardpeters.de> wrote:

Hi,

the SLIP-TAP driver seems not to be working in qemu for cortex-m
targets,too.
I can not get any network traffic between, either between to
qemu_cortex_m3 targets nor to the PC.

Has anyone tried networking in qemu with qemu_cortex_m3 target?

I did. It didn't work. Looking into that is on my to-do since July last
year. But I find that relatively complex (well, wide) task, and
there're more priority stuff anyway. So, to make qemu_cortex_m3 work,
you'd need to understand: a) basic facts about such networking, that
there should be 2 UARTs, one for console, another for networking; b)
exact details of how QEMU does UART emulation on "output" side (which
connects to POSIX object on a host); c) exact details of a MCU/board
qemu_cortex_m3 emulates, its UART setup, etc.; d) other magic
ingredients.

If you know these points well, I encourage you to look into it. If not,
you can use qemu_x86 for now and there're many more lower-hanging, and
oftentimes more important, tasks.

I don't think that this is a configuration problem.
The SLIP-TAP driver was disabled in the cortex_m3 defconfig.
I enabled it, but no luck.

Would be great to get some help on this!

Re: your other questions from the initial mail: I personally don't go
with testing beyond echo_server application so far. What's the point of
trying MQTT/ZOAP/OCF/whatever if basic TCP and pings don't work? Well,
both are working now, but I'd still recommend to start with playing
well withe echo_server. It should work well now for UDP/TCP * IPv4/IPv6
on QEMU. Just in case, walkthru is here:
https://wiki.zephyrproject.org/view/Networking-with-Qemu .

By all means, file the issues you see, but feel free to have a look
at what's already filed:

https://jira.zephyrproject.org/browse/ZEP-1673?jql=project%20%3D%20ZEP%20AND%20component%20%3D%20%22Networking%20%2F%20IP%20Stack%22%20AND%20status%20!%3D%20Closed

And somebody (well, many people!) need to triage, investigate, then
test solutions for already filed issues too ;-).

Regards,
Richard

--
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