Release Asuswrt-Merlin 386.2 is now available

[Tech9]

Figure i save you the pain and maybe the router.

AC86U routers I play with are all repaired and disposable units. I see the process is starting, but as far as I know the notification pops up later on.

 

[Hazel]

Did a dirty upgrade on a RT-AC68U from 386_2_2 to 386_2_4. VPN (ExpressVPN) does not start automatically after reboot. Any idea where to investigate?

First check the setting Automatic start at boot time on the VPN Client page is set to Yes. If that's enabled, check system log for clues, why it doesnt start automatically. Check the current time and date as well.

 

[Magnus33]

AC86U routers I play with are all repaired and disposable units. I see the process is starting, but as far as I know the notification pops up later on.

?

I am going to guess you haven't flashed many of these because that made no sense.
It informs your right away that the upgrade was unsuccessful not part of the way through its not how things work.

Don't take my word for it though as i am sure Merlin and everyone else here can confirm that for you.

Also the only reason i didn't record it tell the end was youtube has a 200mb upload limit for non-confirmed accounts.

Or you can try yourself and keep in mind that the router shall be unrecoverable as far as we know at this point.

 

[Tech9]

Or you can try yourself and keep in mind that the router shall be unrecoverable as far as we know at this point.

Okay, I trust you. That bug has to be addressed quickly. The routers I have are failed units with zero value repaired by me. I can recover wrong flash quickly with a donor flash chip, I believe. I’m running low on donors and want to test AiMesh so you temporarily saved one AC86U soul. Thank you!

 

[stefan21]

First check the setting Automatic start at boot time on the VPN Client page is set to Yes. If that's enabled, check system log for clues, why it doesnt start automatically. Check the current time and date as well.

Automatic start is enabled. I'm pretty sure it's the time disparity. VPN is trying to connect instantly while the device has booted. Syncing with the time servers (0.de.pool.ntp.org and 1.de.pool.ntp.org) is taking too long or the time delay is too long. I'll try to set the connection retry attempt to infinite. Maybe it helps.

 

[Hazel]

Automatic start is enabled. I'm pretty sure it's the time disparity. VPN is trying to connect instantly while the device has booted. Syncing with the time servers (0.de.pool.ntp.org and 1.de.pool.ntp.org) is taking too long or the time delay is too long. I'll try to set the connection retry attempt to infinite. Maybe it helps.

If time hasn't been synced yet (by ntpd or chronyd), certificates aren't valid yet. Under normal circumstances time is synced 'in time'. Are your WAN DNS servers filled? If NTP takes to long to sync for whatever reason, search the forum for a script by @Jack Yaz called ntpbootwatchdog, it can save you a lot of trouble. At least, it did in my case.

Edit: here you go - https://www.snbforums.com/threads/ntp-boot-watchdog-script.71069/

 

[stefan21]

Thank's for this hint. I'll give it a try.

 

[stefan21]

Unfortunately it didn't help.

 

[stefan21]

Is there a way to start the VPN by a script?

 

[Hazel]

Is there a way to start the VPN by a script?

There is, but you can start it manually from the UI too. Both won't work currently, because if time isn't synced, you've got other issues and the service isn't going to be started either way, by script or manually, because the certificates aren't valid yet. Your router has a default time which it uses as 'placeholder' until it's synced with the actual time, because it has no separate power source and an internal clock to remember the current time when switched off or rebooted.

So fiddling with a script won't help you, you need to find to underlying cause. And for that we need the system logs to determine what goes wrong. Go to system log messages, disable auto refresh, copy a large piece preferably from when your router reboots until after it fails to start OpenVPN Client 1 and paste it on a website like pastebin.com or one of it's many alternatives (make sure you redact any private information beforehand) and post the link here, so we can figure out what's going wrong.

As this is a release thread, I suggest you open a separate thread, as this is not a specific issues caused by your upgrade from 386.2_2 to 386.2_4 but more an unfortunate coincident. At least, I can't think of a cause as many have already upgraded to 386.2_4 and our VPN's worked fine after upgrading, so I suspect the cause to be something else. I haven't seen other reports so far.

 

[rtn66uftw]

Did a dirty upgrade on a RT-AC68U from 386_2_2 to 386_2_4. VPN (ExpressVPN) does not start automatically after reboot. Any idea where to investigate?

I am seeing the same issue with Winscribe on AC-86U. In previous versions the VPN automatically started

 

[Hazel]

Is there a way to start the VPN by a script?

I have replied, but my reply is held back, awaiting for moderation. Please check back later and please in the meantime open a new thread for your issue, as I'm pretty certain this has nothing to do with you upgrading to 386.2_4 (more about that in the post that's currently invisible and awaiting moderation).

 

[festus77]

Dirty upgrade from 386.2_2 to 386.2_4 for both router & node. No issues after 3 hours.

 

[Tech9]

Or you can try yourself and keep in mind that the router shall be unrecoverable as far as we know at this point.

I pulled the trigger actually and the firmware got rejected.
Did you make the video with already loaded AX86U firmware on this AC86U router? You have mentioned wrong firmware update on May 2nd and the video was made on May 3rd. How did you recover the router to correct AC86U firmware to make this video? We need correct information here. What I saw is what @Clark Griswald said above in post #691. What @RMerlin says is the only chance to bypass the verification is to attempt flash in recovery mode.

 

[stefan21]

I have replied, but my reply is held back, awaiting for moderation. Please check back later and please in the meantime open a new thread for your issue, as I'm pretty certain this has nothing to do with you upgrading to 386.2_4 (more about that in the post that's currently invisible and awaiting moderation).

ntp-boot-watchdog-script

For the second sript I made an error by copy and pasting - I missed the shebang at the beginning of the init script. Of course, this cannot work. Seems to be fine now. Sorry, my fault. Thank's for staying with me. Anyway I'd suggest to think over that bug for the next release. Not everybody is capable to create scripts...

regards,
stefan

 

[maxbraketorque]

After updating to 386.2_4, some internet addresses are not being resolved. I'm seeing it from at least two different machines on the network, so it appears to be something related to the routers DNS configuration which I haven't changed in at least a month.

 

[KevTech]

I removed it because Asus's FAQ was no longer there on their website, and I have no idea if they moved it elsewhere, or if it's completely missing.

Is this it?

[Wireless Router] How to connect to OpenVPN Server with your device？(For Windows) | Official Support | ASUS Global

 

[Wrkdbf_Guy]

Dirty update from 386.2.2 to 386.2.4. No issues and everything's running as expected.

 

[RMerlin]

Is this it?

[Wireless Router] How to connect to OpenVPN Server with your device？(For Windows) | Official Support | ASUS Global

Already posted a few posts earlier - https://www.snbforums.com/threads/asuswrt-merlin-386-2-is-now-available.71625/post-686246

The FAQ wasn't there at the time, and since Asus's current FAQ handler causes webui issues whenever a linked page goes missing, I removed it at the time. It will be re-added later, assuming the new page doesn't disappear or move again. Asus has apparently been revamping their VPN pages, which causes the URLs to change.

 

[jeff3820]

After updating to 386.2_4, some internet addresses are not being resolved. I'm seeing it from at least two different machines on the network, so it appears to be something related to the routers DNS configuration which I haven't changed in at least a month.

Are you seeing this when using DOT and Quad 9? On May 3 from about 10:00am to 6pm Central time Quad 9 was very flaky but only when using DOT. Some connections would fail (100% packet loss), sometimes 66% packet loss, other times it resolved well. By the evening all was fine. Today, May 4, all seems good.