After update to TOS5: Sometimes very slow or unresponsive Internet and LAN

Software SW help
1

A month ago I updated my Omnia from 3.x to TOS5. The omnia didn’t start afterwards so I installed TOS5 from an USB-stick and reconfigured the system to my needs.

Since then the router is not as reponsive as before and it seems to me it gets worse and worse over the time. Sometimes in the last days the lag to open a webpage takes 10 seconds or even more. But sometimes all is normal again. I don’t now where to start debugging the problem. If anyone could give me some hints where to start looking please do so! I can provide more information if needed.

I was thinking about if that might be a DNS problem, as actually some of my home IOT, two air quality sensors, show debug messages that a DNS-Server is not available and because of this they don’t get contact to ntp-servers (I have iobroker running on a raspberry, airquality sensors, tasmota devices). But my internet provider says their DNS-servers are generally working. I tried all suggested measurements like disabling DNSSEC and changing DNS to other public servers.

And local connections are sometimse very slow as well! Some days ago I saw that answering a ping from my laptop to the Omnia with an 5m cat8 cable and 1G connection took 6 - 8 seconds! As I was resently downloading some torrents with transmission I checked if transmission might be influencing it. Stopping the service at http://192.168.100.1/cgi-bin/luci/admin/system/startup in luci lowered the response time to less the 0.5 ms! Here some results ,beginning with a slow response situation:

ping

64 Bytes von 192.168.100.1: icmp_seq=280 ttl=64 Zeit=5695 ms
64 Bytes von 192.168.100.1: icmp_seq=282 ttl=64 Zeit=5221 ms
64 Bytes von 192.168.100.1: icmp_seq=283 ttl=64 Zeit=5709 ms
64 Bytes von 192.168.100.1: icmp_seq=284 ttl=64 Zeit=6090 ms
64 Bytes von 192.168.100.1: icmp_seq=287 ttl=64 Zeit=5791 ms
64 Bytes von 192.168.100.1: icmp_seq=288 ttl=64 Zeit=6113 ms
64 Bytes von 192.168.100.1: icmp_seq=289 ttl=64 Zeit=6904 ms
64 Bytes von 192.168.100.1: icmp_seq=292 ttl=64 Zeit=6061 ms
64 Bytes von 192.168.100.1: icmp_seq=293 ttl=64 Zeit=6460 ms
64 Bytes von 192.168.100.1: icmp_seq=294 ttl=64 Zeit=7139 ms
64 Bytes von 192.168.100.1: icmp_seq=295 ttl=64 Zeit=7697 ms
64 Bytes von 192.168.100.1: icmp_seq=298 ttl=64 Zeit=6573 ms
64 Bytes von 192.168.100.1: icmp_seq=299 ttl=64 Zeit=6898 ms
64 Bytes von 192.168.100.1: icmp_seq=300 ttl=64 Zeit=7633 ms
64 Bytes von 192.168.100.1: icmp_seq=301 ttl=64 Zeit=8018 ms
64 Bytes von 192.168.100.1: icmp_seq=303 ttl=64 Zeit=6128 ms
64 Bytes von 192.168.100.1: icmp_seq=304 ttl=64 Zeit=6368 ms
64 Bytes von 192.168.100.1: icmp_seq=305 ttl=64 Zeit=6900 ms
64 Bytes von 192.168.100.1: icmp_seq=306 ttl=64 Zeit=7433 ms
64 Bytes von 192.168.100.1: icmp_seq=307 ttl=64 Zeit=7711 ms
64 Bytes von 192.168.100.1: icmp_seq=310 ttl=64 Zeit=5461 ms
64 Bytes von 192.168.100.1: icmp_seq=311 ttl=64 Zeit=4463 ms
64 Bytes von 192.168.100.1: icmp_seq=312 ttl=64 Zeit=3463 ms
64 Bytes von 192.168.100.1: icmp_seq=313 ttl=64 Zeit=2440 ms
(I stopped transmission here)
64 Bytes von 192.168.100.1: icmp_seq=316 ttl=64 Zeit=0.310 ms
64 Bytes von 192.168.100.1: icmp_seq=317 ttl=64 Zeit=0.363 ms
64 Bytes von 192.168.100.1: icmp_seq=318 ttl=64 Zeit=0.499 ms
64 Bytes von 192.168.100.1: icmp_seq=319 ttl=64 Zeit=0.430 ms
64 Bytes von 192.168.100.1: icmp_seq=320 ttl=64 Zeit=0.350 ms
64 Bytes von 192.168.100.1: icmp_seq=321 ttl=64 Zeit=0.490 ms
64 Bytes von 192.168.100.1: icmp_seq=322 ttl=64 Zeit=0.402 ms
64 Bytes von 192.168.100.1: icmp_seq=323 ttl=64 Zeit=0.433 ms
64 Bytes von 192.168.100.1: icmp_seq=324 ttl=64 Zeit=0.457 ms
64 Bytes von 192.168.100.1: icmp_seq=325 ttl=64 Zeit=0.428 ms
64 Bytes von 192.168.100.1: icmp_seq=326 ttl=64 Zeit=0.307 ms
64 Bytes von 192.168.100.1: icmp_seq=327 ttl=64 Zeit=0.421 ms
64 Bytes von 192.168.100.1: icmp_seq=328 ttl=64 Zeit=0.385 ms
64 Bytes von 192.168.100.1: icmp_seq=329 ttl=64 Zeit=0.317 ms
64 Bytes von 192.168.100.1: icmp_seq=330 ttl=64 Zeit=0.386 ms
64 Bytes von 192.168.100.1: icmp_seq=331 ttl=64 Zeit=0.419 ms
64 Bytes von 192.168.100.1: icmp_seq=332 ttl=64 Zeit=0.392 ms
64 Bytes von 192.168.100.1: icmp_seq=333 ttl=64 Zeit=0.342 ms
64 Bytes von 192.168.100.1: icmp_seq=334 ttl=64 Zeit=0.396 ms
64 Bytes von 192.168.100.1: icmp_seq=335 ttl=64 Zeit=0.381 ms
(Started transmission again)
64 Bytes von 192.168.100.1: icmp_seq=336 ttl=64 Zeit=280 ms
64 Bytes von 192.168.100.1: icmp_seq=337 ttl=64 Zeit=146 ms
64 Bytes von 192.168.100.1: icmp_seq=338 ttl=64 Zeit=1911 ms
64 Bytes von 192.168.100.1: icmp_seq=342 ttl=64 Zeit=851 ms
64 Bytes von 192.168.100.1: icmp_seq=343 ttl=64 Zeit=2603 ms
64 Bytes von 192.168.100.1: icmp_seq=348 ttl=64 Zeit=181 ms
64 Bytes von 192.168.100.1: icmp_seq=349 ttl=64 Zeit=553 ms
64 Bytes von 192.168.100.1: icmp_seq=350 ttl=64 Zeit=898 ms
64 Bytes von 192.168.100.1: icmp_seq=351 ttl=64 Zeit=1292 ms
64 Bytes von 192.168.100.1: icmp_seq=352 ttl=64 Zeit=1671 ms
64 Bytes von 192.168.100.1: icmp_seq=353 ttl=64 Zeit=2133 ms
64 Bytes von 192.168.100.1: icmp_seq=354 ttl=64 Zeit=2488 ms
64 Bytes von 192.168.100.1: icmp_seq=355 ttl=64 Zeit=2913 ms
64 Bytes von 192.168.100.1: icmp_seq=356 ttl=64 Zeit=3369 ms
64 Bytes von 192.168.100.1: icmp_seq=357 ttl=64 Zeit=3725 ms
64 Bytes von 192.168.100.1: icmp_seq=358 ttl=64 Zeit=4142 ms
64 Bytes von 192.168.100.1: icmp_seq=359 ttl=64 Zeit=4453 ms
64 Bytes von 192.168.100.1: icmp_seq=360 ttl=64 Zeit=4882 ms
64 Bytes von 192.168.100.1: icmp_seq=361 ttl=64 Zeit=5252 ms
64 Bytes von 192.168.100.1: icmp_seq=362 ttl=64 Zeit=5670 ms
64 Bytes von 192.168.100.1: icmp_seq=363 ttl=64 Zeit=6035 ms
64 Bytes von 192.168.100.1: icmp_seq=364 ttl=64 Zeit=6402 ms
64 Bytes von 192.168.100.1: icmp_seq=365 ttl=64 Zeit=6855 ms
64 Bytes von 192.168.100.1: icmp_seq=366 ttl=64 Zeit=7267 ms
64 Bytes von 192.168.100.1: icmp_seq=367 ttl=64 Zeit=7665 ms
64 Bytes von 192.168.100.1: icmp_seq=368 ttl=64 Zeit=6685 ms
64 Bytes von 192.168.100.1: icmp_seq=369 ttl=64 Zeit=5677 ms
64 Bytes von 192.168.100.1: icmp_seq=370 ttl=64 Zeit=4661 ms
64 Bytes von 192.168.100.1: icmp_seq=371 ttl=64 Zeit=3660 ms
64 Bytes von 192.168.100.1: icmp_seq=372 ttl=64 Zeit=2660 ms
64 Bytes von 192.168.100.1: icmp_seq=373 ttl=64 Zeit=1649 ms
(Stopped transmission)
64 Bytes von 192.168.100.1: icmp_seq=374 ttl=64 Zeit=647 ms
64 Bytes von 192.168.100.1: icmp_seq=375 ttl=64 Zeit=0.459 ms
64 Bytes von 192.168.100.1: icmp_seq=376 ttl=64 Zeit=0.444 ms
64 Bytes von 192.168.100.1: icmp_seq=377 ttl=64 Zeit=0.523 ms
64 Bytes von 192.168.100.1: icmp_seq=378 ttl=64 Zeit=0.443 ms
64 Bytes von 192.168.100.1: icmp_seq=379 ttl=64 Zeit=0.364 ms
64 Bytes von 192.168.100.1: icmp_seq=380 ttl=64 Zeit=0.372 ms
64 Bytes von 192.168.100.1: icmp_seq=381 ttl=64 Zeit=0.401 ms
64 Bytes von 192.168.100.1: icmp_seq=382 ttl=64 Zeit=0.374 ms

However, if I stop transmission the Omnia has still slowly growing response times if I ping it, sometimes growing up to thesame 6-8 sec level. A similar phenomenon appears after a restart, it first works fine, but after some time it - mostly suddenly - slows down to an unusable state. No matter if I use ssh, local network or internet, all is getting unresponsive than.

Just checked if I can regulary use internet if I connect directly with my laptop through pppoe. That works without problems!

I don’t understand network technology, but at least I am used to use linux since 15 years. For me it appeared first after I installed TOS5, but I am not even sure if it has to do with the newer OS. I neither have any special software (only Nextcloud, Transmission) installed nor very special configurations (3x Wifi, about 15 static ip-adresses for the IOT things and a 1TB internal harddrive (I have the NAT perk)).

I just went back to 5.1.4 using schnapps, configured, that updates needs to be confirmed and that seems to work normal the last hours at least.
|Device|Turris Omnia|
|Serial number|47244660408|
|Turris OS version|5.1.4|
|Turris OS branch|HBS|
|Kernel version|4.14.206|

Before it was updated to 5.1.5 (Not to todays 5.1.6)
Any idea what I could check is very welcome!
Thank you!

2

Based on your ping tests, it seems clear that the issue is on a lower level than DNS. (naturally, DNS will probably also get slower as a result)

3

Thank you @vcunat! Before reading this I just played around with ping, as my Omnia got slow overnight again. I found out, if I ping a public website (here baidu.com, a usually very responsive chinese search engine) it takes about 10 seconds before ping displays the first result:

PING baidu.com (39.156.69.79) 56(84) bytes of data.
64 Bytes von 39.156.69.79 (39.156.69.79): icmp_seq=1 ttl=49 Zeit=9.87 ms
^C64 Bytes von 39.156.69.79: icmp_seq=2 ttl=49 Zeit=9.36 ms

--- baidu.com ping statistics ---
2 Pakete übertragen, 2 empfangen, 0% packet loss,  **time 15015ms**
rtt min/avg/max/mdev = 9.358/9.615/9.872/0.257 ms

But if I ping 39.156.69.79 (the IP address of baidu.com, in my understanding without DNS) I get this result:

PING 39.156.69.79 (39.156.69.79) 56(84) bytes of data.
64 Bytes von 39.156.69.79: icmp_seq=1 ttl=49 Zeit=9.47 ms

— 39.156.69.79 ping statistics —
1 Pakete übertragen, 1 empfangen, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 9.471/9.471/9.471/0.000 ms

Please see the highlighted time statistics! I tried the same with sogou.com / 118.191.216.42 or here www.turris.cz / 2001:1488:ac15:ff80::69

PING www.turris.cz(2001:1488:ac15:ff80::69 (2001:1488:ac15:ff80::69)) 56 data bytes
64 Bytes von 2001:1488:ac15:ff80::69 (2001:1488:ac15:ff80::69): icmp_seq=1 ttl=49 Zeit=380 ms
^C64 Bytes von 2001:1488:ac15:ff80::69: icmp_seq=2 ttl=49 Zeit=381 ms

— www.turris.cz ping statistics —
2 Pakete übertragen, 2 empfangen, 0% packet loss, time 16337ms
rtt min/avg/max/mdev = 379.571/380.322/381.073/0.751 ms

PING 2001:1488:ac15:ff80::69(2001:1488:ac15:ff80::69) 56 data bytes
64 Bytes von 2001:1488:ac15:ff80::69: icmp_seq=1 ttl=49 Zeit=381 ms

— 2001:1488:ac15:ff80::69 ping statistics —
2 Pakete übertragen, 1 empfangen, 50% packet loss, time 1000ms
rtt min/avg/max/mdev = 381.242/381.242/381.242/0.000 ms

Doesn’t that mean that DNS might part of the problem?
Could anybody tell me what the levels below DNS are? TCP/IP, right?

I am still running 5.1.4 at the moment.

1 Like
4

I tried HBT testing, used it for one day but I had the same problems. I installed TOS 3.11 from an USB-stick and everything works well again. If I’ve more time to spent I will try a fresh installation of TOS5, in case I’ve made any mistakes installing it the first time. But any hints are welcome, which parts of TOS’s network software and configuration has changed and could be related to the problems described.

Thank you :slight_smile:

5

I’m sorry for my lag. From the timings it would really appear that these ping tests spend most of the time in DNS, but it’s not clear why just from this.

It’s a bit suspicious that your IPv6 appears to have much higher latency than IPv4, and that could slow down DNS resolver unless IPv6 gets explicitly disabled inside, but even so I wouldn’t expect the effect to be so bad to wait around 15 seconds.

Well, if you get into the problem again, we can try narrowing the cause. I can’t see what to do until then.

6

No problem with the lag, @vcunat! I might have time next week to install TOS 5 again. Right now still running TOS 3 without problems. I’ll write here if I try it again. Thank you!