Network Monitoring vs NCSI (dns.msftncsi.com)

[Sky]

I often see delays getting a good time sync in my System log, so I was thinking about enabling Network Monitoring [Administration > System > Network Monitoring]. When I clicked [x] DNS Query, I was surprised to see the following entries already there:

• Resolve Hostname [dns.msftncsi.com]
• Resolved IP Addresses [131.107.255.255 112.4.20.71 fd3e:4f5a:5b81::1]
  • IP 131 resolves to Microsoft
  • IP 112 resolves to CMNET-JIANGSU (China Mobile)
  • the IP v6 doesn't appear to resolve to anyone I can find off-hand

I do know NCSI is a Microsoft service to determine connection state(s) in Windows 7 & 8. Some computers in this network were running Windows XP and Windows 7. The 7s are now on Win-10.

Which leaves me wondering:

1. What are these doing entered as values in the router for an "unused" option?
2. How would they get there since they were not entered manually by me?
   1. Leftover from Asus manufacturing?
3. Is there cause for alarm?
   1. ehhhh, I'm thinking probably not, but...?

This all seems a bit weird on its face. While I'm asking, does anyone use Network Monitoring and does it do any good?


Sky

 

[RMerlin]

What are these doing entered as values in the router for an "unused" option?

They are simply default values. Just like the router has a default username of "admin", a default LAN IP of 192.168.50.1, etc...

 

[Sky]

They are simply default values. Just like the router has a default username of "admin", a default LAN IP of 192.168.50.1, etc...

Thanks!

So is Network Monitoring actually a decent way to get more reliable Time Syncs? I've tried a variety of ntp settings but none seem to work more than a couple of weeks before they vacation in Flake-O Land, which is just outside of Seattle I believe.

 

[ColinTaylor]

I'm not sure why you think that Network Monitoring is linked to time syncing.

 

[RMerlin]

So is Network Monitoring actually a decent way to get more reliable Time Syncs?

It's unrelated, and is mostly useful for people using Dual WAN in failover mode. Other users should keep it disabled.

 

[Sky]

I'm not sure why you think that Network Monitoring is linked to time syncing.

See ASUS FAQ: [Administration] How to set up Network Detection to make sure your router’s time zone synchronizes with NTP server? (updated 2020 02-25)

 

[Sky]

It's unrelated, and is mostly useful for people using Dual WAN in failover mode. Other users should keep it disabled.

So I went ahead and gave this a try on a lark knowing full well the FAQ specs 3.0.0.4384_40000 or later and the latest OEM FW for my AC87 is 382_51939. What could go wrong? Well...

On my connection using fw 382_51939, Login > Advanced Settings | Administration > System:

1. Network Monitoring -- [x]DNS Query -- results in loss of internet connectivity;
2. Ping Target -- pool.ntp.org -- results in loss of internet connectivity; and
   
3. Ping Target -- (resolved ip) -- appears to work.

I am concerned about ping frequency. There's no way to control this in the OEM FW, and nobody likes being over-pinged. I'll let this run a few days and see if it acts as desired or spurns my advances.

EDIT 6 MAY 2020

OK, I tried it. You do know I can hear y'all laughin', right?!

I'm guessing uncontrolled spurious knocks on the ping door got me in trouble; #3 wasn't near as nice as I thought it was going to be. After about 45-min or so my poor old AC87 just sort of got confused. The Connected Status on the home page showed disconnected (from the internet). The actual connection was working fine, all the clients were connecting fine. If you weren't looking at the 87's home page you'd swear everything was okey-dokey—but it wasn't. Rebooting the router did not fix the issue, neither did reprovisioning the modem. Cold booting, router/modem/modem+router/etc., didn't work either. I finally just had to surrender and restore my prior configuration, you know—the one we all make just before we set out to play with something or other. Luckily I did have one from my last tinker a week ago. I think those settings were still current.

Moral of the story:

If you're not running the right firmware,
DO NOT TRY THIS AT HOME ​

I still have problems with the ntp sync failing. Oh well, c'est la vie.​

 

[Sky]

Maybe I'm just barking up an empty tree here trying to nail down this NTP Time Sync thing. This is what I keep seeing:

May 10 03:04:29 hour monitor: ntp sync fail, will retry after 120 sec
May 10 23:02:38 disk_monitor: Got SIGALRM...
May 11 03:00:03 reboot scheduler: [timecheck] The system is going down for reboot​

I'm not sure what triggers the SIGALRM, but that is the only entry between one scheduled reboot and the next. It's nice & smooth reboot-to-reboot (done nightly). The problem is, I never see an off-setting ntp sync successful entry. Is that not a "thing"?

Sky

 

[ColinTaylor]

The "disk_monitor: Got SIGALRM" message is perfectly normal.

 

[Sky]

The "disk_monitor: Got SIGALRM" message is perfectly normal.

That's what I figured. Any insight into the ntp sync fail? I feel like there should be something that says successful or reads out a sync value like adjusted xxxxxxxxxxx seconds or something.

 

[dave14305]

That's what I figured. Any insight into the ntp sync fail? I feel like there should be something that says successful or reads out a sync value like adjusted xxxxxxxxxxx seconds or something.

Try setting

nvram set hour_monitor_debug=1
nvram commit

then watching the syslog for more details. Once you're satisfied, remove it with

nvram unset hour_monitor_debug
nvram commit

This seems to be related to traffic limiter / analyzer.

 

[Sky]

Try setting

nvram set hour_monitor_debug=1
nvram commit

then watching the syslog for more details. Once you're satisfied, remove it with

nvram unset hour_monitor_debug
nvram commit

This seems to be related to traffic limiter / analyzer.

Umm... I am on the OEM FW. How do I implement your suggestion?

I think I should update my sig line — done

 

[ColinTaylor]

Just SSH into the router and type the commands.