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

[slyman]

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.

 

[L&LD]

Does this issue persist if the router is fully reset/Initialized too?

 

[slyman]

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

Have logged a bug:

https://github.com/RMerl/asuswrt-merlin.ng/issues/499

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 )....

 

[L&LD]

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.

 

[slyman]

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.