berre

Hi @Rfreire, You're right about the bandwidth in the downstream, this seems unaffected and does not cause the crash. But if you look at the upstream traffic instead (where the crash occurs on IPv6) you'll see there's very little bandwidth being generated there, even though it's the same test. Looking forward to the results. Personally I haven't done much more on this yet.. It would be nice to see if someone else can reproduce it. /B

Hi @Rfreire See the output below. The send counter never increases when I'm running the IPv6 traffic, it dies of too quickly I guess. The IPv4 test shows that expected traffic pattern. I also tried reproducing this problem with curl and POST, e.g "curl -6 -XPOST -d @bigfile http://[ipv6-address]. This works just fine, even when I'm paralleling 4-5 streams. Idle: During IPv4 test: During IPv6 test (and crash):

Hi, I've now isolated the problem. It occurs when I'm running bbk_cli (this is a speedtest, similiar to ookla and such). When I run this test over IPv6 specfically, the whole network will break down as described earlier. Using the very same binary for IPv4 tests works just fine... It's just when I'm running the IPv6 test. This binary runs OK in for example RPI3 (not sure about kernel, but I've only tested on CentOS). Can check these details if it's interesting. I also noted it seems to occur when the upstream is being tested. Running similiar traffic patterns with iperf3 over IPv6 seems to work OK.. But this one is different as it uses HTTP protocol. About the BBK speedtest: https://ensupport.bredbandskollen.se/support/solutions/articles/1000228167-how-does-the-measurement-work-in-technical-terms- How to reproduce: Download and install BBK @ https://beta1.bredbandskollen.se/download/bbk-cli_0.3.8_armhf.deb Run the IPv6 test (the test should crash when the upstream test starts): root@tinkerboard:~# bbk_cli --v6 Start: 2018-04-27 07:48:31 [ipv6] Latency: 150.650 ms Download: 826.816 Mbit/s Upload: 8.141 Mbit/s /B

Hi, I've got several tinkerboards that I've reproduced this problem on. I'm using the tinkerboard to do network tests, this includes iperf3 traffic,dns querys (dig), https and http (echoping), and ping. All of these tests runs against IPv6 targets and IPv4 targets. These tests are scheduled to very frequently (every other minute or so). To begin with, all tests run fine.. I get good results (~1gbit throughput / low latency / no packet loss). However, after running the tests for 15-20min, suddenly all traffic will more or less stop working (80-90% packet loss). This is no matter what I'm pinging, can be the local router, some target on the internet... Doesn't matter. The only way to make the problem go away is to reboot the board, after this I can resume the tests until the problem is reproduced again after 15-20min. So I started troubleshooting, this is how far I've gotten so far: When the problem occurs, disable ALL tests and check connectivty. Still extremely bad but maybe slighly better (~30-50 packet loss on both IPv4/IPv6) Only run IPv4 tests (disable IPv6 tests) <--- This works, now I'm not getting the sudden extreme packet loss scenarios. (Hence the topic). Also worth mentioning is that I'm still having IPv6 enabled, it's just the tests themselves being disabled. Only run IPv6 tests <--- Problem is reproduced Update to latest kernel and nightly build - Problem still reproduced Run the same exact test on 6 other tinkerboards - Problem reproduced on all boards I've been tailing dmesg/journal, there's not a single message/error/warning/whatever when this problem happens.. Which is confusing. Right now: I'm trying to isolate which of the IPv6 tests are causing the problem (DNS,HTTP,HTTPS,ICMP or iperf3 traffic)....... But in the meantime I wanted to check for help here. Logs: