What's new

ntpMerlin ntpMerlin - NTP Daemon for AsusWRT Merlin

  • SNBForums Code of Conduct

    SNBForums is a community for everyone, no matter what their level of experience.

    Please be tolerant and patient of others, especially newcomers. We are all here to share and learn!

    The rules are simple: Be patient, be nice, be helpful or be gone!

Weird, it's created via nat-start so should persist
If it happens again, I will check /jffs/scripts/nat-start
Code:
# cat /jffs/scripts/nat-start
#!/bin/sh

/jffs/scripts/ntpmerlin ntpredirect # ntpMerlin
 
I think the issue lies with something should only happen at reboot , but is somehow is happening with out reboot, and the ntpmerlin script doesn't know how to account for that. --- something between the nat-start and the firewall-start from skynet.
 
If it happens again, I will check /jffs/scripts/nat-start
Code:
# cat /jffs/scripts/nat-start
#!/bin/sh

/jffs/scripts/ntpmerlin ntpredirect # ntpMerlin
Try inserting at the top of nat-start
Code:
sleep 10
 
May 24 13:11:28 nat: apply nat rules (/tmp/nat_rules_eth0_eth0)
May 24 13:11:29 custom_script: Running /jffs/scripts/firewall-start (args: eth0)

has to be where the issue is happening... it happens when you sometimes make adjustments in the router that involve this restarting.
 
May 24 13:11:28 nat: apply nat rules (/tmp/nat_rules_eth0_eth0)
May 24 13:11:29 custom_script: Running /jffs/scripts/firewall-start (args: eth0)

has to be where the issue is happening... it happens when you sometimes make adjustments in the router that involve this restarting.
Lot happening on reboot, even when just looking at ntp, nat and firewall
Code:
May  5 01:05:21 router ntpd: Started ntpd
May 23 21:45:20 router ntp: Initial clock set
May 23 21:45:20 router rc_service: ntpd_synced 1944:notify_rc restart_stubby
May 23 21:45:20 router rc_service: ntpd_synced 1944:notify_rc restart_diskmon
May 23 21:45:20 router rc_service: waitting "restart_stubby" via ntpd_synced ...
May 23 21:45:24 router S77ntpd: Waiting for NTP to sync before starting...
May 23 21:45:24 router ntpd[2349]: ntpd 4.2.8p12@1.3728-o Thu Mar 21 09:03:59 UTC 2019 (1): Starting
May 23 21:45:24 router ntpd[2349]: Command line: ntpd -c /jffs/configs/ntp.conf -g
May 23 21:45:24 router ntpd[2360]: proto: precision = 0.200 usec (-22)
May 23 21:45:24 router ntpd[2360]: switching logging to file /opt/var/spool/ntp/ntp.log
May 23 21:45:31 router rc_service: udhcpc 2615:notify_rc start_firewall
May 23 21:45:32 router custom_script: Running /jffs/scripts/service-event (args: start firewall)
May 23 21:45:32 router nat: apply nat rules (/tmp/nat_rules_eth0_eth0)
May 23 21:45:32 router custom_script: Running /jffs/scripts/nat-start
May 23 21:45:32 router rc_service: waitting "start_firewall" via udhcpc ...
May 23 21:45:32 router rc_service: udhcpc 2615:notify_rc stop_ntpd
May 23 21:45:32 router rc_service: waitting "start_firewall" via udhcpc ...
May 23 21:45:32 router rc_service: waitting "start_firewall" via udhcpc ...
May 23 21:45:32 router custom_script: Running /jffs/scripts/firewall-start (args: eth0)
May 23 21:45:35 router rc_service: udhcpc 2615:notify_rc start_ntpd
May 23 21:45:35 router rc_service: waitting "stop_ntpd" via udhcpc ...
May 23 21:45:35 router custom_script: Running /jffs/scripts/service-event (args: stop ntpd)
May 23 21:45:36 router custom_script: Running /jffs/scripts/service-event (args: start ntpd)
May 23 21:45:36 router ntpd: Started ntpd
May 23 21:45:53 router YazFi: Firewall restarted - sleeping 60s before running YazFi
May 23 21:45:55 router rc_service: udhcpc 2615:notify_rc start_firewall
May 23 21:45:55 router custom_script: Running /jffs/scripts/service-event (args: start firewall)
May 23 21:45:55 router nat: apply nat rules (/tmp/nat_rules_eth0_eth0)
May 23 21:45:55 router custom_script: Running /jffs/scripts/nat-start
May 23 21:45:55 router ntpMerlin: Lock file found (age: 23 seconds) - stopping to prevent duplicate runs
May 23 21:45:55 router custom_script: Running /jffs/scripts/firewall-start (args: eth0)
May 23 21:50:00 router ntpMerlin: Stale lock file found (>120 seconds old) - purging lock
 
Lot happening on reboot, even when just looking at ntp, nat and firewall
Code:
May  5 01:05:21 router ntpd: Started ntpd
May 23 21:45:20 router ntp: Initial clock set
May 23 21:45:20 router rc_service: ntpd_synced 1944:notify_rc restart_stubby
May 23 21:45:20 router rc_service: ntpd_synced 1944:notify_rc restart_diskmon
May 23 21:45:20 router rc_service: waitting "restart_stubby" via ntpd_synced ...
May 23 21:45:24 router S77ntpd: Waiting for NTP to sync before starting...
May 23 21:45:24 router ntpd[2349]: ntpd 4.2.8p12@1.3728-o Thu Mar 21 09:03:59 UTC 2019 (1): Starting
May 23 21:45:24 router ntpd[2349]: Command line: ntpd -c /jffs/configs/ntp.conf -g
May 23 21:45:24 router ntpd[2360]: proto: precision = 0.200 usec (-22)
May 23 21:45:24 router ntpd[2360]: switching logging to file /opt/var/spool/ntp/ntp.log
May 23 21:45:31 router rc_service: udhcpc 2615:notify_rc start_firewall
May 23 21:45:32 router custom_script: Running /jffs/scripts/service-event (args: start firewall)
May 23 21:45:32 router nat: apply nat rules (/tmp/nat_rules_eth0_eth0)
May 23 21:45:32 router custom_script: Running /jffs/scripts/nat-start
May 23 21:45:32 router rc_service: waitting "start_firewall" via udhcpc ...
May 23 21:45:32 router rc_service: udhcpc 2615:notify_rc stop_ntpd
May 23 21:45:32 router rc_service: waitting "start_firewall" via udhcpc ...
May 23 21:45:32 router rc_service: waitting "start_firewall" via udhcpc ...
May 23 21:45:32 router custom_script: Running /jffs/scripts/firewall-start (args: eth0)
May 23 21:45:35 router rc_service: udhcpc 2615:notify_rc start_ntpd
May 23 21:45:35 router rc_service: waitting "stop_ntpd" via udhcpc ...
May 23 21:45:35 router custom_script: Running /jffs/scripts/service-event (args: stop ntpd)
May 23 21:45:36 router custom_script: Running /jffs/scripts/service-event (args: start ntpd)
May 23 21:45:36 router ntpd: Started ntpd
May 23 21:45:53 router YazFi: Firewall restarted - sleeping 60s before running YazFi
May 23 21:45:55 router rc_service: udhcpc 2615:notify_rc start_firewall
May 23 21:45:55 router custom_script: Running /jffs/scripts/service-event (args: start firewall)
May 23 21:45:55 router nat: apply nat rules (/tmp/nat_rules_eth0_eth0)
May 23 21:45:55 router custom_script: Running /jffs/scripts/nat-start
May 23 21:45:55 router ntpMerlin: Lock file found (age: 23 seconds) - stopping to prevent duplicate runs
May 23 21:45:55 router custom_script: Running /jffs/scripts/firewall-start (args: eth0)
May 23 21:50:00 router ntpMerlin: Stale lock file found (>120 seconds old) - purging lock
imagine how much more will be going on at reboot when you add that sleep 5 or sleep 10 option.
 
maybe adding something that checks for the proper flags to confirm ntpmerlin redirect is enabled after reboot process [ place it somewhere in a start script that happens after all this stuff or in a place that can wait for this stuff to finish...] ^
it would obviously have to be able to read that the appropriate flags are in iptables as well and possibly involving a cru schedule to periodically check for flags that it is enabled that can be enabled with in the ntpmerlin script itself.
 
that way you do not have to add sleep commands to an already time consuming process.
 
imagine how much more will be going on at reboot when you add that sleep 5 or sleep 10 option.
Zilch/nada/nowt

Currently the timing of the asynchronous requests is:
Code:
     +===apply:nat===+           +===nat-start===+
           |                             |
           |                             |
           |                        Insert rules
           |                             |
           |                     +===nat-start===+
           |
           |
     Initialise rules
           |
     +===apply:nat===+

With the addition of the 'sleep 10', we are not contributing to the system load ( assuming that the 'sleep' function isn't using old-skool spin-loop, but IRQ method), in fact rather than running concurrent tasks, we are now serialising the execution, so in all probability, actions performed by nat-start will execute quicker (less wall-clock time) as we have delayed its execution until the frenzy of competing tasks has dramatically subsided and there are more available cpu cycles.
Code:
     +===apply:nat===+           +===nat-start===+
           |                             |
           |                             |
           |                          sleep 10   
           |                             |
           |                             |
           |                             |
           |                             |
     Initialise rules                    |
           |                             |
     +===apply:nat===+                   |
                                         |
                                         |
                                         |
                                    Insert rules
                                         |
                                 +===nat-start===+

NOTE: Whilst not ideal, the use of judicious 'sleep' commands to alleviate/accomodate race-conditions is an accepted necessary evil in programming.

P.S. Surely spawning a separate task to monitor the existence of the custom rules created in nat-start would be wasteful?

However, it's up to @RMerlin to evaluate if delaying the execution request of nat-start is a viable solution? - whoah, wait a minute......does that involve a 'sleep'? :rolleyes:
that way you do not have to add sleep commands to an already time consuming process.
 
Last edited:
Zilch/nada/nowt

Currently the timing of the asynchronous requests is:
Code:
     +===apply:nat===+           +===nat-start===+
           |                             |
           |                             |
           |                        Insert rules
           |                             |
           |                     +===nat-start===+
           |
           |
     Initialise rules
           |
     +===apply:nat===+

With the addition of the 'sleep 10', we are not contributing to the system load ( assuming that the 'sleep' function isn't using old-skool spin-loop, but IRQ method), in fact rather than running concurrent tasks, we are now serialising the execution, so in all probability, actions performed by nat-start will execute quicker (less wall-clock time) as we have delayed its execution until the frenzy of competing tasks has dramatically subsided and there are more available cpu cycles.
Code:
     +===apply:nat===+           +===nat-start===+
           |                             |
           |                             |
           |                          sleep 10  
           |                             |
           |                             |
           |                             |
           |                             |
     Initialise rules                    |
           |                             |
     +===apply:nat===+                   |
                                         |
                                         |
                                         |
                                    Insert rules
                                         |
                                 +===nat-start===+

NOTE: Whilst not ideal, the use of judicious 'sleep' commands to alleviate/accomodate race-conditions is an accepted necessary evil in programming.

P.S. Surely spawning a separate task to monitor the existence of the custom rules created in nat-start would be wasteful?

However, it's up to @RMerlin to evaluate if delaying the execution request of nat-start is a viable solution? - whoah, wait a minute......does that involve a 'sleep'? :rolleyes:
I have been looking for a place to put that sleep 15 option..
 
OKay so today I checked my computer like 15 or so minutes after the morning reboot... I noted the Prerouted traffic was in the correct spot... Now I log into the router several hours later --- no reboot since the morning one, I am noticing No pre-routed traffic on the page.
note I added to sleep 10 option mentioned earlier and these test were done with that option in the nat-start script.
 
upload_2019-5-25_11-13-28.png
 
upload_2019-5-25_11-14-37.png

this is when I disable it....

this is when I enable it....
upload_2019-5-25_11-16-13.png


this is what the iside of nat-start says
upload_2019-5-25_11-17-31.png



I can confirm after only 5 hours since there was a reboot... NTPMerlin lost redirect capabilities..

The syslogs does not indicate at what point it lost the iptables data, but for now until this all gets sorted i will use the stock NTP server.
 

Attachments

  • upload_2019-5-25_11-15-22.png
    upload_2019-5-25_11-15-22.png
    218.5 KB · Views: 463
Last edited:
Code:
May 25 11:01:57 miniupnpd[6314]: upnp_event_recv: recv(): Connection reset by peer
May 25 11:01:57 miniupnpd[6314]: upnpevents_processfds: 0x2c198, remove subscriber uuid:dfa95978-19f0-4b68-b715-c88c46a8edfd after an ERROR cb: http://192.168.1.64:2869/upnp/eventing/susxmlkqkh
is the only possible place i can see any changes might have happened with the IPtables, but I cannot confirm this is what cause the issue though.
 
okay so i toggled on and off the Upnp feature and i lost my prerouted traffic
upload_2019-5-25_12-30-30.png
 
Does this happen on the stable (i.e. non-alpha) firmware?
Yes I have had it happen on the 384.11 build as well, just didnt know what caused it.

It would be enlightening to understand the dynamics of what is happening in the iptables that causes it to lose ntpmerlin redirect option when ever a upnp connection is added or removed. :confused:
 
Last edited:
I reconfigured to use this pool and removed all of the servers. So far, so good. Thanks!

I continued trying to figure out why my network required "tos maxdist 16" to get ntpd to sync. Even with that setting, ntpd would very frequently switch peers - but it least it would stay synced. Finally, I disabled everything in "LAN - Switch Control". Before, I had everything enabled. Now ntpd syncs right up and is quite stable. Not sure why I had enabled all of those features to begin with...
 
well NAT Acceleration is not necessary if you have a slow connection,, but you may suffer if you have a top teir connection and you disable it.
 

Similar threads

Latest threads

Support SNBForums w/ Amazon

If you'd like to support SNBForums, just use this link and buy anything on Amazon. Thanks!

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Top