OpenVPN Server woes/ intermediate firmware?

[martinr]

RT-AC68U. 380.68

I got a used RT-AC68U and didn't pay too much attention to the version of the stock firmware on it, except I think it was old, I then updated to the latest Asus stock firmware, and from there to Merlin 380.67 and now 380.68.

However, even if I do a factory reset and input no settings, except to start the OpenVPN servers, it's obvious something's not right. It can take considerable time "Initializing file settings of OpenVPN server now, please wait a few minutes.....". And when I can get them to run (by forcing the Apply button a second time) the server(s) won't survive a reboot: the server is stopped and the Initializing message with the swirling disc is back. Other than that, it seems to work well.

I wonder if my mistake possibly might have been to miss out the intermediate 378.55 upgrade.

I tried reverting back to 378.55, but of course that's blocked as an Invalid Firmware Upload.

If missing intermediate firmware is the problem, would the later firmwares have been installed without tge router objecting? Is there a simple way to check whether changes that 378.55 carries out have indeed been made on the router?

 

[martinr]

By powering off, holding the reset button, then powering on and holding the Reset button until the Power light flashes, I managed to upload and install 378.55 via the ASUSTek - CFE miniWeb Server.

After factory reseting through the webui, I will now be able to find out if failure to pass tgrough the 378.55 'safe houe' was the problem.

 

[martinr]

Well, that disproves that theory: rebooting, with previously running OpenVPM servers (one at 1194 udp, the other 443 TCP) even on 378.55 and no settings imported both OpenVPN servers STILL do not come back after a reboot when they were running beforehand. Instead, the "Initializing the settings of OpenVPN server now, please wait...." returns with its swirling circle on both servers UNTIL the Apply button is hit for both servers and then they run again.

So it looks as if manual intervention is required after a reboot, even on 378.55 with factory default settings, to hit the Apply button, to get the OpenVPN servers running again. Not the case with my other RT-AC68U running 378.55.

All interesting stuff!

 

[Jack Yaz]

Well, that disproves that theory: rebooting, with previously running OpenVPM servers (one at 1194 udp, the other 443 TCP) even on 378.55 and no settings imported both OpenVPN servers STILL do not come back after a reboot when they were running beforehand. Instead, the "Initializing the settings of OpenVPN server now, please wait...." returns with its swirling circle on both servers UNTIL the Apply button is hit for both servers and then they run again.

So it looks as if manual intervention is required after a reboot, even on 378.55 with factory default settings, to hit the Apply button, to get the OpenVPN servers running again. Not the case with my other RT-AC68U running 378.55.

All interesting stuff!

What does SysLog show?

 

[RMerlin]

The 378.55 firmware is only needed to accept flashing a firmware > 31 MB. Older firmwares would refuse it.

The initialization step can take a couple of minutes as stated, as the router is automatically generating a key and a DH - this can take a few minutes on a slow 800 MHz CPU.

System Log will give you more info as to what is going on if something is preventing the server from properly starting.

 

[martinr]

Many thanks, Merlin and Jack. The Syslog did indeed help: I saw from the timestamp that I'd forgotten to plug it into the modem after flashing 378.55. Somewhere along the line I managed to correct the problem, because I later flashed to 380.68, factory reset, reinstated my settings with a migratory restoration using John's utility. And now the servers survive a reboot and all's eceptionally good.

I don't know what the problem was, especially now after Merlin's comments about the intermediate firmware. I think the solution lay in simple perseverence and refamiliaring with little-used procedures eg factory resets, John's utility, critical settings ....... So it's been an excellent and timely opportunity to brush the rust off those procedures and relearn how to do things properly!

Perseverence was probably the most effective tool.

Many thanks.