EmeraldDeer
Very Senior Member
If it happens again, I will check /jffs/scripts/nat-start
Code:
# cat /jffs/scripts/nat-start
#!/bin/sh
/jffs/scripts/ntpmerlin ntpredirect # ntpMerlinntpMerlin ntpMerlin - NTP Daemon for AsusWRT Merlin
- Thread starter Jack Yaz
- Start date
Swistheater
Very Senior Member
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.
Martineau
Part of the Furniture
Swistheater
Very Senior Member
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: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.
EmeraldDeer
Very Senior Member
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 lockSwistheater
Very Senior Member
imagine how much more will be going on at reboot when you add that sleep 5 or sleep 10 option.
Swistheater
Very Senior Member
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.
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.
Swistheater
Very Senior Member
that way you do not have to add sleep commands to an already time consuming process.
Martineau
Part of the Furniture
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'?
Last edited:
Swistheater
Very Senior Member
I have been looking for a place to put that sleep 15 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'?
Swistheater
Very Senior Member
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.
note I added to sleep 10 option mentioned earlier and these test were done with that option in the nat-start script.
Swistheater
Very Senior Member
Swistheater
Very Senior Member
this is when I disable it....
this is when I enable it....
this is what the iside of nat-start says
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
Last edited:
Swistheater
Very Senior Member
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/susxmlkqkhSwistheater
Very Senior Member
okay so i toggled on and off the Upnp feature and i lost my prerouted traffic
Jack Yaz
Part of the Furniture
Does this happen on the stable (i.e. non-alpha) firmware?
Swistheater
Very Senior Member
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.
Last edited:
joe68000
Regular Contributor
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...
Swistheater
Very Senior Member
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
Similar threads
| Thread starter | Title | Forum | Replies | Date |
|---|---|---|---|---|
| W | ntpMerlin ntpMerlin and timeserverd ntp_ready tests | Asuswrt-Merlin AddOns | 1 | |
| D | NTPmerlin config log not found | Asuswrt-Merlin AddOns | 2 | |
| A | ntpMerlin Problems with ntpMerlin | Asuswrt-Merlin AddOns | 9 |
Similar threads
-
ntpMerlin ntpMerlin and timeserverd ntp_ready tests
- Started by Wyehoota
- Replies: 1
-
-
Latest threads
-
Release ASUS RT-BE96U Firmware version 3.0.0.6.102_37031 (2024/11/07)- Started by DMcD-EMS-USMC
- Replies: 0
-
Release ASUS RT-AX58U Firmware Version 3.0.0.4.388_25139- Started by visortgw
- Replies: 1
-
Release ASUS GT-BE98 Pro Firmware Version 3.0.0.6_102_37031
- Started by NotTheHerbie
- Replies: 4
-
RT AX86u PRo 35mbs top dl speed
- Started by laptop
- Replies: 4
-
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!