TOS 7 ARM Official Release Announcement

[Gremlin]

So users with multiple Tnas models running TOS7 will have multiple groups of network activity every 15 seconds just to say I have network connectivity. A bit galling when my router will flash an led to serve the same purpose.

[FredMutter]

So users with multiple Tnas models running TOS7 will have multiple groups of network activity every 15 seconds just to say I have network connectivity. A bit galling when my router will flash an led to serve the same purpose.

I totally agree with you

This is expected background behavior used purely for network status monitoring.

And if there is no connection, how does this monitoring help us—or help your software?
It just generates unnecessary network traffic every 15 seconds. What would actually happen if the monitoring reported that there was no connection?
I think this is a very short-sighted design decision.
Why does TOS need to generate network traffic just to determine something the operating system can already determine from the network interface and existing traffic?



Microsoft Windows solution:
Windows’ passive probe can run every 15 seconds, but it examines existing network traffic rather than generating traffic
Active probes are triggered by events such as connecting to a network, a network/interface change, proxy changes, etc.

[pennypacker]

Agreed with both posters above. Numerous issues with this approach...

• TOS doesn't need to be checking for network connectivity AFAICT - especially with remote access turned off.
• Checking multiple domains every 15 seconds is *way* over the top
• There should be a user configurable setting at least to control this behaviour given the 2 previous points
• Preferably it shouldn't happen in the first place
• What does TOS do when the network check fails?

I have submitted a bug report to the support email mentioned at the start of the thread. This needs further scrutiny IMHO.

Edit: I have disabled the only 2 apps that could have a conceivable reason for testing internet connectivity (Plex and CloudSync) and this has no effect on the deluge of DNS requests.

[TMroy]

The normal interval for network connectivity checks is 5 minutes, not 15 seconds. As for why it appeared to be 15 seconds, our estimate is that TOS attempted to connect to a server but timed out, and kept retrying — and the retry interval happened to be 15 seconds. We'll need to verify this again. Thanks for your feedback!

[pennypacker]

Would you like some logs from my DNS server? I can give you say, 30 mins in CSV?

[TMroy]

Sure, please send it to our support mail account. thank you!

[pennypacker]

OK, done. I've replied to the original bug report that I emailed.

[EriChan]

Thank you very much for providing the detailed DNS logs.

After analyzing the logs, we confirmed that when certain probe endpoints experience timeouts or packet loss, the retry mechanism is triggered aggressively at 15-second intervals, resulting in the excessive DNS query volume over 24 hours.

We will evaluate and implement optimization solutions for this behavior in upcoming versions.

Thank you again for your valuable feedback and cooperation!

[pennypacker]

Terrific! Thanks for your speedy investigation. Looking forward to the upcoming fix

[Flyingbike]

Dear all,
I posted on this DNS issue before finding this topic :

I run this version.

I recently switched from ISP DNS to self-hosted pihole and I quickly noticed my F2-423 was requesting A LOT

Code: Select all

2026-08-29 18:40:36		AAAA	ipv6.baidu.com.lan	********.lan	25.3 µs	
2026-08-29 18:40:36		AAAA	www.google.com	********.lan	12.9 µs	
2026-08-29 18:40:36		AAAA	ipv6.baidu.com	********.lan	12.9 µs	
2026-08-29 18:40:36		AAAA	www.cloudflare.com	********.lan	65.1 µs	
2026-08-29 18:40:21		AAAA	ipv6.baidu.com.lan	********.lan	55.6 µs	
2026-08-29 18:40:21		AAAA	www.google.com	********.lan	36.5 µs	
2026-08-29 18:40:21		A	www.baidu.com	********.lan	28.6 µs	
2026-08-29 18:40:21		AAAA	ipv6.baidu.com	********.lan	35.8 µs	
2026-08-29 18:40:21		AAAA	www.cloudflare.com	********.lan	56.3 µs	
2026-08-29 18:40:06		AAAA	ipv6.baidu.com.lan	********.lan	52.5 µs	
2026-08-29 18:40:06		AAAA	www.google.com	********.lan	47.9 µs	
2026-08-29 18:40:06		AAAA	ipv6.baidu.com	********.lan	26.7 µs	
2026-08-29 18:40:06		AAAA	www.cloudflare.com	********.lan	42.2 µs	
2026-08-29 18:39:51		AAAA	ipv6.baidu.com.lan	********.lan	50.5 µs	
2026-08-29 18:39:51		AAAA	www.google.com	********.lan	36.7 µs	
2026-08-29 18:39:51		A	www.baidu.com	********.lan	24.6 µs	
2026-08-29 18:39:51		AAAA	ipv6.baidu.com	********.lan	26.5 µs	
2026-08-29 18:39:51		AAAA	www.cloudflare.com	********.lan	50.1 µs	
2026-08-29 18:39:36		AAAA	ipv6.baidu.com.lan	********.lan	53.6 µs	
2026-08-29 18:39:36		AAAA	www.google.com	********.lan	12.4 µs	
2026-08-29 18:39:36		AAAA	ipv6.baidu.com	********.lan	11.7 µs	
2026-08-29 18:39:36		AAAA	www.cloudflare.com	********.lan	34.3 µs	
2026-08-29 18:39:21		AAAA	ipv6.baidu.com.lan	********.lan	61.5 µs	
2026-08-29 18:39:21		A	www.baidu.com	********.lan	27.9 µs	
2026-08-29 18:39:21		AAAA	www.google.com	********.lan	48.2 µs

Every 15 seconds.


Why so frequently ?

And additionally, why AAAA when ipv6 is deactivated on this device ?

This is orchestrated by TOSDaemon through gitlab.local/golibrary/wanip and probed domains are hard coded.


It seems I am not the first one to notice.
viewtopic.php?p=59673#p59673, the explanation of packet loss or timeout in this other topic is incorrect. The DNS answers correctly and the domains are reachable.

It surely needs an explanation and a correction.

THanks