Nevermind, I'm a moron, as usual ... the NTP Daemon setup makes a copy of the www directory that never gets updated. So, when I re-enabled the NTP Daemon and the menus went back to the way they were, the lightbulb finally went on.Okay, so after factory reset, I now have all the right buttons for checking for firmware, AND apparently some other changes that have happened along the way (the ones I noticed were cosmetic, perhaps there's others), and it shows the 380.64 in the firmware version box. Guess I got lucky in not having to do factory resets through a lot of upgrades, and so I was reluctant to believe that was the problem here. Lesson learned.
Traffic Monitor Daily
Traffic Monitor Monthly
AC5300
Is it normal traffic monthly didn't show anything at all?
Are you adding 'explicit-exit-notify' in your custom config? I was able to recreate the syslog entries on my fork, but only with this set. It looks like a bug in OpenVPN where it's not removing the added routes when it shuts down with explicit-exit-notify set. Then when it restarts, it finds the same routes you are trying to add and posts the error (hitting Apply causes a restart). Try removing this line if it's there and see what happens.Just rebooted, and the problem doesn't happen on a fresh boot, but simply "apply" the config (no need to change it) and it'll report errors and leave the vpn client status as "Error connecting - IP/Routing conflict"
Are you adding 'explicit-exit-notify' in your custom config? I was able to recreate the syslog entries on my fork, but only with this set. It looks like a bug in OpenVPN where it's not removing the added routes when it shuts down with explicit-exit-notify set. Then when it restarts, it finds the same routes you are trying to add and posts the error (hitting Apply causes a restart). Try removing this line if it's there and see what happens.
Do you know why they do that?" explicit-exit-notify" causes OpenVPN to skip running its updown script, which is why routes don't get cleaned up. People must not use that setting in Asuswrt's environment.
Do you know why they do that?
With qos disabled on rt-n66u I set nat acceleration to Auto but after applying setting it turns back to disable. What other settings may be incompatible with nat acceleration?
No, I don't have that set in my custom config. All I have in there, in addition to the "route" line is:Are you adding 'explicit-exit-notify' in your custom config? I was able to recreate the syslog entries on my fork, but only with this set. It looks like a bug in OpenVPN where it's not removing the added routes when it shuts down with explicit-exit-notify set. Then when it restarts, it finds the same routes you are trying to add and posts the error (hitting Apply causes a restart). Try removing this line if it's there and see what happens.
No, I don't have that set in my custom config. All I have in there, in addition to the "route" line is:
persist-key
persist-tun
disable-occ
Maybe one of those has the same side-effect?
Thanks for the info.Tools -> Sysinfo will tell you what causes NAT acceleration to be disabled.
That's interesting. You said you saw the syslog conflict entries even on my fork. I can't recreate the problem unless I include the 'explicit-exit-notify'. Without it, everything works as expected and no errors.Even after removing those 3 options and leaving just the "route" line in the custom config, the problem still persists. No problem on reboot, but if you "apply" config and openvpn is reloaded the stale routes are left behind and this error state occurs.
Welcome To SNBForums
SNBForums is a community for anyone who wants to learn about or discuss the latest in wireless routers, network storage and the ins and outs of building and maintaining a small network.
If you'd like to post a question, simply register and have at it!
While you're at it, please check out SmallNetBuilder for product reviews and our famous Router Charts, Ranker and plenty more!