On Thu, 4 May 2017 17:47:17 +0300
Paul Sokolovsky <Paul.Sokolovsky@...> wrote:

[]

b) My "ultimate" test was supposed to be downloading large files (tens
of MBs) from http://archive.ubuntu.com/, checking their hash (I'm
using that site as it readily offers hash values for different
algorithms), then repeating to collect enough traffic (ultimately
mentioned gigabyte). Unfortunately, I didn't have much luck with this
"ambitious" goal. Overall, I got 100% TCP hang on byte counts ranging
from 100Kbs to ~10MB.

I figured out this issue - it's because Zephyr IP stack doesn't
anticipate the possibility that its ACK may be lost. Then peer will
resend a packet Zephyr already saw, and it doesn't like that. This is
ticketed as https://jira.zephyrproject.org/browse/ZEP-2121 .

With workaround for that applied, I didn't have problems with prolonged
downloads from the real Internet:

========
...
Received already seen pkt - ACKing
Received already seen pkt - ACKing
Received already seen pkt - ACKing
Making sure FIN goes with ACK; adjusting seq by 2; now fire up Wireshark and check that all's ok
Size : 7015896
Hash : 337c37d7ec00348414224baa6bdb2d43f2a34ef5676bafcdcad916f148b5b317
Total downloaded so far: 160M
========


Summing up, basic testing with a convenient to use API (BSD Sockets)
and easy to use environment to exercise that API (MicroPython) quickly
uncovered 3 critical issues in Zephyr IP stack, and few more less
serious, which shows the potential ;-).


[]

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