Release Asuswrt-Merlin 386.1 is now available

[petcan3]

386.2 alpha 2 rtax86u works like a dream I have fans in the back of router

 

[dardar]

I have two RT-AC86U routers that were both running fine on 384.19 since last September or so. One of them is at a remote vacation house, and both were set up to run OpenVPN servers (using the same VPN settings for each) so that I can connect to them remotely through an OpenVPN client from my laptop wherever I am.

I did a direct update to 386.1 on the local router on Sunday morning, and although it took an hour or so for the web gui to come up normally, the router functionality seemed to be fine right after a reboot. I decided to go ahead with the update on the remote router (through a VPN connection). That has worked fine for previous upgrades, but it didn't go well this time. After the usual few minutes watching the progress bar complete, I think I tried using my normal VPN client to connect to the remote VPN server. I don't think that worked quite right, but I can't remember the entire sequence at this point. I gave it some more time but then started tweaking my VPN client settings, since my local VPN client didn't seem to be connecting correctly.

Since the router is remote (and nobody is physically in the vacation house at the moment), I won't be able to do any physical resets for a while, but I would like to troubleshoot the connection to the extent I can do that locally. For what it's worth, I have a couple Raspberry Pis at the remote location that normally connect by VPN back to my local router. I can see on my local router's VPN server that one of the RPis has reconnected since the upgrade, so I know that the remote router's wifi is working and that it has internet access.

I have updated my local OpenVPN client to v. 2.5 and have been playing with VPN configurations on my laptop to try to revive the VPN connection and get stable access to the router's web gui. By using ncp-disable and cipher AES-128-GCM, I am able to get brief connections to the web gui, but before I can get past the login screen, I get ping-restarts, and the web connection goes dead. I was able to reboot the router one time from the web gui, but nothing changed after the router had restarted.

Looking through the VPN logs doesn't show anything that is obviously wrong, but the connection just isn't stable for more than a few seconds. There is some browser dependency, with Chrome fairly reliably at least getting me to the login gui, whereas Firefox never gets that far. I have also tried using putty to ssh into the router. I got to the RSA server key warning once, but the connection immediately went dead. I have never seen the normal login prompt on the command line.

Any suggestions? I could probably have someone stop by the house at some point, but it would be hard to walk them through a reset remotely. Is there any way to disable the ping-restart from the client-side VPN? Any other suggestions why the VPN connection might be dying so quickly? If I can get a stable web interface connection, I was planning to download a fresh OpenVPN client configuration file, but is there anything else I could do that might stabilize the VPN server? Would I be better off trying to get a stable ssh command line? Thanks in advance for any suggestions!

 

[Andorul]

Did you go to Advanced Settings | Wireless | Wi-Fi Radar | Wi-Fi Site Survey, which on my computer opens a seperate Tab in Chrome call Wifi Insight, and then go under "Configure" and "Start Data Collection", along with check marking the "Start collecting data every" checkbox, and then days and times you require?

Thanks forget that

 

[mromero]

View attachment 30548
386.2 alpha 2 rtax86u works like a dream I have fans in the back of router

Ambient temp?

 

[petcan3]

Ambient temp?

68 deg F

 

[ATLga]

I have two RT-AC86U routers that were both running fine on 384.19 since last September or so. One of them is at a remote vacation house, and both were set up to run OpenVPN servers (using the same VPN settings for each) so that I can connect to them remotely through an OpenVPN client from my laptop wherever I am.

I did a direct update to 386.1 on the local router on Sunday morning, and although it took an hour or so for the web gui to come up normally, the router functionality seemed to be fine right after a reboot. I decided to go ahead with the update on the remote router (through a VPN connection). That has worked fine for previous upgrades, but it didn't go well this time. After the usual few minutes watching the progress bar complete, I think I tried using my normal VPN client to connect to the remote VPN server. I don't think that worked quite right, but I can't remember the entire sequence at this point. I gave it some more time but then started tweaking my VPN client settings, since my local VPN client didn't seem to be connecting correctly.

Since the router is remote (and nobody is physically in the vacation house at the moment), I won't be able to do any physical resets for a while, but I would like to troubleshoot the connection to the extent I can do that locally. For what it's worth, I have a couple Raspberry Pis at the remote location that normally connect by VPN back to my local router. I can see on my local router's VPN server that one of the RPis has reconnected since the upgrade, so I know that the remote router's wifi is working and that it has internet access.

I have updated my local OpenVPN client to v. 2.5 and have been playing with VPN configurations on my laptop to try to revive the VPN connection and get stable access to the router's web gui. By using ncp-disable and cipher AES-128-GCM, I am able to get brief connections to the web gui, but before I can get past the login screen, I get ping-restarts, and the web connection goes dead. I was able to reboot the router one time from the web gui, but nothing changed after the router had restarted.

Looking through the VPN logs doesn't show anything that is obviously wrong, but the connection just isn't stable for more than a few seconds. There is some browser dependency, with Chrome fairly reliably at least getting me to the login gui, whereas Firefox never gets that far. I have also tried using putty to ssh into the router. I got to the RSA server key warning once, but the connection immediately went dead. I have never seen the normal login prompt on the command line.

Any suggestions? I could probably have someone stop by the house at some point, but it would be hard to walk them through a reset remotely. Is there any way to disable the ping-restart from the client-side VPN? Any other suggestions why the VPN connection might be dying so quickly? If I can get a stable web interface connection, I was planning to download a fresh OpenVPN client configuration file, but is there anything else I could do that might stabilize the VPN server? Would I be better off trying to get a stable ssh command line? Thanks in advance for any suggestions!

I think I’d have someone stop by the house and unplug it for a minute then power back up and see if it behaves normally before I did all that work. Easy approach first

 

[DrSkull]

I've upgraded recently from a netgear r8000 to a Asus ax86u. The coverage seems around the same but the netgear always had disconnects at longer ranges no matter what firmware I upgraded to and the Asus router doesn't. Weird.

So far so good on Merlin Firmware. Been running it since a week. On stock, I had problems for some reason with a Roku 4k and an laptop from 2007 disconnecting. Newer devices had no problem but since updating I've had no more disconnects. Merlin Firmware seems to be more stable on older devices.

 

[programatix]

Anyone using the printer server on RT-AC86U?

On the stock firmware, it is working great on version 384 but on version 386, the printer server still work, except after I turned off the printer for more than 1 minute, turning it back on later will cause the printer not able to print anymore. To resolve, I need to either restart the router (while the printer is on), or disable and enable the printer server via the router GUI.

My printer is connected via USB to the router.

I'm wondering if merlin's 386 has this issue too?

 

[BatKing]

Any one have issue on AC68U (A1) with CTF + FA enabled and Guest1 wifi (both 2.4 and 5Ghz) cannot be connected? Log error as following

Feb  1 09:59:31 syslog: wlceventd_proc_event(555): wl1.1: Assoc XX:XX:XX:XX:XX:XX, status: Successful (0), rssi:0
Feb  1 09:59:37 syslog: wlceventd_proc_event(490): wl1.1: Deauth_ind YY:YY:YY:YY:YY:YY, status: 0, reason: 4-way handshake timeout (f), rssi:0

After doing some test, I can confirm this is due to FA is enabled. I have 2 AC68Us running in AiMesh. was on 384.19 and everything was working fine. Since I don't use any AiProtection/QoS/Traffic Analyzer Statistic features, I always have CTF + FA enabled in Tools System Info. Its all fine on 384.19.

After upgraded to 386.1, initial dirty upgrade seems fine, but quickly I find the GN1 wifi issues. Then I remove the Node AC68u and reset it to start from scratch setup as test. The GN1 issue persist with this Factory reset AC68U. But by luck I find the issue is related to FA. GN1 works right after reset and setting up the router with only basic and guest network 1 and 2 without reboot. but once reboot, GN1 is broken (GN2 and regular Wifi are fine). The difference is after reset it is always only CTF, but once reboot, it will report CTF + FA.

There is always a mystery to me is that my 800Mhz A1 AC68U have FA supported? I remember I read somewhere Merlin stated the old AC68U A1 800Mhz CPU do not have FA. But to me it is always reported there. but the strange thing is everytime if I reset the router, the 1st time in Web UI reports CTF only. but a reboot will make it CTF + FA both enabled. so during my test, after reset and setup GN1 (without reboot router), I can connect to it fine. but once after reboot, then GN1 cannot be connected. The difference is before reboot it is CTF only and after reboot it is CTF + FA.

I know I can turn off FA by enable Traffic Analyzer Statistic and I can use this to replicate my GN1 issue. Enable Statistic and reboot (because FA won't be disable until reboot, at least in the WebUI it is like this) then my GN1 is all fine. Turn off Traffic Analyzer Statistic and reboot, then my GN1 is broken again. I now tested on both my AC68U and both resulting the same issue. so now I am turning on Traffic Analyzer Statistic just for FA off and GN1 functioning.

Anyone have this issue?

 

[miazza]

Hi all. I have just updated the router with 386.1 and now I canno access anumore the webUI.
I tried a switch off cycle.
I trried to restart the httpd service
I can reach the login page but after having entered name and passwod the page does not load.

What can i do ?

I have ssh access .

 

[ATLga]

Hi all. I have just updated the router with 386.1 and now I canno access anumore the webUI.
I tried a switch off cycle.
I trried to restart the httpd service
I can reach the login page but after having entered name and passwod the page does not load.

What can i do ?

I have ssh access .

Read page 1 known issues
It’s answered there

 

[raion969]

After the update to 386.1 on my RT-AC5300. My Wireless devices sometimes disconnect or just show no connection ?

 

[dardar]

I think I’d have someone stop by the house and unplug it for a minute then power back up and see if it behaves normally before I did all that work. Easy approach first

Thanks, ATLga. You're right about trying the easy things first. I'll see if I can track down a neighbor to restart it. I just hope I don't need to do a full reset.

 

[bbunge]

I have two RT-AC86U routers that were both running fine on 384.19 since last September or so. One of them is at a remote vacation house, and both were set up to run OpenVPN servers (using the same VPN settings for each) so that I can connect to them remotely through an OpenVPN client from my laptop wherever I am.

I did a direct update to 386.1 on the local router on Sunday morning, and although it took an hour or so for the web gui to come up normally, the router functionality seemed to be fine right after a reboot. I decided to go ahead with the update on the remote router (through a VPN connection). That has worked fine for previous upgrades, but it didn't go well this time. After the usual few minutes watching the progress bar complete, I think I tried using my normal VPN client to connect to the remote VPN server. I don't think that worked quite right, but I can't remember the entire sequence at this point. I gave it some more time but then started tweaking my VPN client settings, since my local VPN client didn't seem to be connecting correctly.

Since the router is remote (and nobody is physically in the vacation house at the moment), I won't be able to do any physical resets for a while, but I would like to troubleshoot the connection to the extent I can do that locally. For what it's worth, I have a couple Raspberry Pis at the remote location that normally connect by VPN back to my local router. I can see on my local router's VPN server that one of the RPis has reconnected since the upgrade, so I know that the remote router's wifi is working and that it has internet access.

I have updated my local OpenVPN client to v. 2.5 and have been playing with VPN configurations on my laptop to try to revive the VPN connection and get stable access to the router's web gui. By using ncp-disable and cipher AES-128-GCM, I am able to get brief connections to the web gui, but before I can get past the login screen, I get ping-restarts, and the web connection goes dead. I was able to reboot the router one time from the web gui, but nothing changed after the router had restarted.

Looking through the VPN logs doesn't show anything that is obviously wrong, but the connection just isn't stable for more than a few seconds. There is some browser dependency, with Chrome fairly reliably at least getting me to the login gui, whereas Firefox never gets that far. I have also tried using putty to ssh into the router. I got to the RSA server key warning once, but the connection immediately went dead. I have never seen the normal login prompt on the command line.

Any suggestions? I could probably have someone stop by the house at some point, but it would be hard to walk them through a reset remotely. Is there any way to disable the ping-restart from the client-side VPN? Any other suggestions why the VPN connection might be dying so quickly? If I can get a stable web interface connection, I was planning to download a fresh OpenVPN client configuration file, but is there anything else I could do that might stabilize the VPN server? Would I be better off trying to get a stable ssh command line? Thanks in advance for any suggestions!

If you can get into the Pi via the VPN it should be possible to set up a SSH tunnel to access the router. I did this a while back with a Ubuntu server on a LAN that had an Asus AC68U that was not fully starting. I used Putty to set up the tunnel to get to the router web gui and SSH. In my case the IPV6 not starting was holding OpenVPN from starting. Took me a couple of days to figure out how to do it but saved me a 70 mile trip. Now I have a "spare" PC on the remote LAN running Teamviewer that I can access remotely to do router maintenance and other tasks.

 

[dardar]

If you can get into the Pi via the VPN it should be possible to set up a SSH tunnel to access the router. I did this a while back with a Ubuntu server on a LAN that had an Asus AC68U that was not fully starting. I used Putty to set up the tunnel to get to the router web gui and SSH. In my case the IPV6 not starting was holding OpenVPN from starting. Took me a couple of days to figure out how to do it but saved me a 70 mile trip. Now I have a "spare" PC on the remote LAN running Teamviewer that I can access remotely to do router maintenance and other tasks.

Thanks, bbunge. That was a good suggestion, although it didn't quite solve my problem. My home router uses the 192.168.25.0 subnet, and the VPN server assigns addresses for remote connections to 192.168.26.0. I tried to SSH with putty to my remote Pi's local address (192.168.26.2) and saw an immediate login prompt with the RSA key warning. (Hooray! I thought.) Unfortunately, the Pi immediately disconnected after I entered my username. It didn't even prompt me for a password.

Is there a reason that a partially updated RT-AC86U would immediately drop any device trying to connect over VPN? For what it's worth, my remote router is configured to use the 192.168.50.0 subnet, and its VPN server assigns local addresses to 192.168.51.0. I'm not a networking expert, so I'm not sure it that's the best way to do it, but I had issues when both routers were on the same subnet.

 

[SNBForums User]

Any one have issue on AC68U (A1) with CTF + FA enabled and Guest1 wifi (both 2.4 and 5Ghz) cannot be connected? Log error as following

Feb  1 09:59:31 syslog: wlceventd_proc_event(555): wl1.1: Assoc XX:XX:XX:XX:XX:XX, status: Successful (0), rssi:0
Feb  1 09:59:37 syslog: wlceventd_proc_event(490): wl1.1: Deauth_ind YY:YY:YY:YY:YY:YY, status: 0, reason: 4-way handshake timeout (f), rssi:0

After doing some test, I can confirm this is due to FA is enabled. I have 2 AC68Us running in AiMesh. was on 384.19 and everything was working fine. Since I don't use any AiProtection/QoS/Traffic Analyzer Statistic features, I always have CTF + FA enabled in Tools System Info. Its all fine on 384.19.

After upgraded to 386.1, initial dirty upgrade seems fine, but quickly I find the GN1 wifi issues. Then I remove the Node AC68u and reset it to start from scratch setup as test. The GN1 issue persist with this Factory reset AC68U. But by luck I find the issue is related to FA. GN1 works right after reset and setting up the router with only basic and guest network 1 and 2 without reboot. but once reboot, GN1 is broken (GN2 and regular Wifi are fine). The difference is after reset it is always only CTF, but once reboot, it will report CTF + FA.

There is always a mystery to me is that my 800Mhz A1 AC68U have FA supported? I remember I read somewhere Merlin stated the old AC68U A1 800Mhz CPU do not have FA. But to me it is always reported there. but the strange thing is everytime if I reset the router, the 1st time in Web UI reports CTF only. but a reboot will make it CTF + FA both enabled. so during my test, after reset and setup GN1 (without reboot router), I can connect to it fine. but once after reboot, then GN1 cannot be connected. The difference is before reboot it is CTF only and after reboot it is CTF + FA.

I know I can turn off FA by enable Traffic Analyzer Statistic and I can use this to replicate my GN1 issue. Enable Statistic and reboot (because FA won't be disable until reboot, at least in the WebUI it is like this) then my GN1 is all fine. Turn off Traffic Analyzer Statistic and reboot, then my GN1 is broken again. I now tested on both my AC68U and both resulting the same issue. so now I am turning on Traffic Analyzer Statistic just for FA off and GN1 functioning.

Anyone have this issue?

Yep, same hardware, same issue. You did some very good detective work.

 

[dh99999]

Apologies if this has been covered.
Is parental controls time limits broken on this build?
I have factory reset and added settings manually (nvram get on client list).
Any limits I set are ignored, AI is definitely enabled, is there some other setting I need to check?

There are quite a few reports of this now - it looks to be a bug in Merlin 386.1 - it is working on stock firmware (3.0.0.4.386_41634 and 9.0.0.4.386_41994).

Some very good investigative work here by @Wistuplu showing the root cause (different iptables settings) and the difference between Merlin and stock -> 386.1 Wifi time scheduling

Its not reported as a known issue, and I'm not sure if he/she's reported this as a bug - what is the best way to report this?

 

[ATLga]

There are quite a few reports of this now - it looks to be a bug in Merlin 386.1 - it is working on stock firmware (3.0.0.4.386_41634 and 9.0.0.4.386_41994).

Some very good investigative work here by @Wistuplu showing the root cause (different iptables settings) and the difference between Merlin and stock -> 386.1 Wifi time scheduling

Its not reported as a known issue, and I'm not sure if he/she's reported this as a bug - what is the best way to report this?

@RMerlin is in that other thread you point to, so I would consider it reported.

 

[IshWishDish]

After the update to 386.1 on my RT-AC5300. My Wireless devices sometimes disconnect or just show no connection ?

So glad to see someone else mention this! I just registered to report the same thing.

I did a clean upgrade to 386.1 from the latest 384 on my RT-AC5300. I took screenshots of my old settings and restarted the router and did a WPS settings reset, then upgraded. I even then told it to reset defaults from within the UI, and told it to format JFFS. So really started from scratch.

I am having really troublesome connectivity. I will say that I had EXTREME problems when I tried re-installing and enabling the YazFi script for guest networks. As soon as I enabled that, no connection would stay up for more than a few minutes. I had to restart from scratch again and not use that script for now.

I haven't found any other pattern or reason why I'm having such poor connectivity otherwise. Distance in the house seems to have seriously dropped off, plus random disconnects, plus much slower than before.

I want to note that I really respect Merlin and other contributors for all they have done - please only note this as a bug report and no criticism for the work you do.

 

[dh99999]

@RMerlin is in that other thread you point to, so I would consider it reported.

Thanks.