AT-AC68U/384.16 OpenVPN client doesn't start if "log verbosity" < 2.

  • ATTENTION! As of November 1, 2020, you are not able to reply to threads 6 months after the thread is opened if there are more than 500 posts in the thread.
    Threads will not be locked, so posts may still be edited by their authors.
    Just start a new thread on the topic to post if you get an error message when trying to reply to a thread.


New Around Here
Nothing in the logs, as expected with verb < 2 it's not logging much anyway. Nothing if executed from the command line either.

I want no logging so adding "log-append /dev/null" as a custom option for a workaround is ok.

This caused a couple of hours of confusion though so thought I would post it here.

I seem to remember this with an older version of the firmware from a couple of years ago, but may be wrong on this.


Part of the Furniture
Does this issue persist if the router is fully reset/Initialized too? :)


New Around Here
Nothing to do with nvram (clearing this is basically what reverting to factory settings does).

Have logged a bug:

On a personal note, I hate the "just restore to factory settings", it is like the old days where reinstalling windows was the answer to everything. Merlin is linux, it doesn't need that, and it doesn't actually solve problems it's just a very very very long work around, which would not have worked in this case anyway. However, from a support perspective, I understand. It can take a long time to set up a test case, and the reporter should be doing that with open source stuff (like I have just been doing :))....


Part of the Furniture
Asuswrt isn't Linux. Restoring to factory settings put the router defaults and the variables in a state the currently installed firmware expects.

Driver updates also require a reset to factory defaults. Even SSID's may need to be retired in certain cases.

The limitations, to me, seem to be the underpowered hardware used which must be made to act as if it is, almost, Linux. :)


New Around Here
It's linux.

Source: uname, and the fact I have worked with linux professionally for ~20 years (might even have a couple of lines of code in the kernel still, although that was back in 2004).

If you look at the source code, you will see that openvpn is just an executable. It does not read anything special from the firmware (i.e. doesn't call nvram). The generation of the configs does read values from nvram, but the generation of the configs is ok.

To quote RMerlin from the case: "This is an old uclibc limitation."

I can assure you that factory resetting would not have solved this problem. I would have added the same line to /jffs/configs/hosts.add afterwards which would have caused the same problem with uclibc, and therefore ntpd and openvpn.

Latest threads

Sign Up For SNBForums Daily Digest

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