Hello Rohit,

On Mon, 22 Aug 2016 14:58:11 +0000
Rohit Grover <Rohit.Grover(a)arm.com> wrote:

I've still not been able to get a TCP stream going over uIP using the
echo-client sample. I've unearthed problems along the way (including
data-integrity issues in Zephyr's port of uIP; refer to
https://gerrit.zephyrproject.org/r/#/c/4226/ ) which suggest that
this kind of thing isn't actively tested.

I can now confirm this issue, running via QEMU virtual networking
(actually, even doing this from MicroPython Zephyr port running in
QEMU, this being initial steps to add Z's networking binding to
MicroPython).

Well, as you know, TCP was added to Z relatively recently, so some
white spots aren't surprising. In this particular case, with
"echo_server" sample app available, I guess most people (of those who
enable TCP support in it at all) test the other direction, host ->
Z-device.

What's more concerning is that the code in which you find issue
(apparently) belongs to uIP, and you know, uIP was used in many dozens
of thousands of devices over the last decade, so getting to the bottom
of the issue would be really important.

With my recent changes, I
manage to get the first packet bounce back successfully to the
echo-client. Successive packets aren't getting processed on their way
out from the client.

Can't say much about this, yet. Reverse case (multiple packers, host ->
QEMU Z device) works well. Did you pay attention that networking needs
to be used differently for micro-kernel and nano-kernel? Microkernel
can issue networking calls directly, while nano needs them to be
wrapped in a fiber. Anyway, that's what echo_server/echo_client do, so
if you use them already, shouldn't be a concern.


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