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