[Beta] Asuswrt-Merlin 380.60 Beta is now available

[saytr79]

380.60 Beta 1 still same issue.

Jun 21 19:01:50 WAN Connection: ISP's DHCP did not function properly.
Jun 21 19:01:50 DualWAN: skip single wan wan_led_control - WANRED off
Jun 21 19:01:50 stop_nat_rules: apply the redirect_rules!

It appears I'm having the same issue, did you find a solution ? I've done a factory reset, manually entered in the settings, turned my router off for 20+ minutes while having my IP lease released by my ISP and still no change. See my logs below.


Jun 21 20:09:23 dnsmasq-dhcp[911]: DHCPDISCOVER(br0) 10:40:f3:85:65:82
Jun 21 20:09:23 dnsmasq-dhcp[911]: DHCPOFFER(br0) 192.168.1.76 10:40:f3:85:65:82
Jun 21 20:09:24 dnsmasq-dhcp[911]: DHCPREQUEST(br0) 192.168.1.76 10:40:f3:85:65:82
Jun 21 20:09:24 dnsmasq-dhcp[911]: DHCPACK(br0) 192.168.1.76 10:40:f3:85:65:82 Computer
Jun 21 20:36:30 WAN Connection: ISP's DHCP did not function properly.
Jun 21 20:36:30 DualWAN: skip single wan wan_led_control - WANRED off
Jun 21 20:36:30 stop_nat_rules: apply the redirect_rules!
Jun 21 17:53:41 miniupnpd[1894]: ioctl(s, SIOCGIFADDR, ...): Cannot assign requested address
Jun 21 17:53:41 miniupnpd[1894]: Failed to get IP for interface eth0
Jun 21 17:53:41 miniupnpd[1894]: SendNATPMPPublicAddressChangeNotification: cannot get public IP address, stopping
Jun 21 21:53:41 dnsmasq[911]: read /etc/hosts - 5 addresses

 

[RMerlin]

My router is RT-AC68U running Asuswrt-Merlin 380.60-beta1. When the router is rebooted, it takes 15 mins for my laptop to see the 5.0GHz channel SSID. The 2.4GHz is fine. When I check the debug console after reboot, I see:

acsd: scan in progress ...
acsd: scan in progress ...
acsd: scan in progress ...
acsd: scan in progress ...
acsd: selected channel spec: 0xe06a (100/80)
acsd: Adjusted channel spec: 0xe06a (100/80)
acsd: selected DFS-exit channel spec: 0xe06a (100/80)
acsd: selected channel spec: 0xe06a (100/80)
acsd: Adjusted channel spec: 0xe06a (100/80)
acsd: selected channel spec: 0xe06a (100/80)

Then about 15 mins later, the router automatically does another ACSD scan and the problem is fixed. Now I can see the 5.0GHz channel. It appears to have picked a better channel spec (52/80). My previous firmware version was Asuswrt-Merlin 380.59 and it did not do this.

You are using a DFS channel, and you have something nearby using that frequency, forcing your router off that channel. Switch to a non-DFS channel.

 

[inaroundroom]

I've been using adaptive QoS which has worked well and insured that my work laptop has the bandwidth it requires to allow me to maintain SfB calls/desktop sharing etc.

One item I've noted though is that QoS applies to all traffic (LAN/WAN), is it possible to only enforce it on WAN traffic?

I'm currently synching data from one machine to another across the lan and this is being limited by QoS to a limit of 1.5 MB/s outbound where as without QoS enabled I'm getting around 18.1 MB/s.

 

[saytr79]

It appears I'm having the same issue, did you find a solution ? I've done a factory reset, manually entered in the settings, turned my router off for 20+ minutes while having my IP lease released by my ISP and still no change. See my logs below.


Jun 21 20:09:23 dnsmasq-dhcp[911]: DHCPDISCOVER(br0) 10:40:f3:85:65:82
Jun 21 20:09:23 dnsmasq-dhcp[911]: DHCPOFFER(br0) 192.168.1.76 10:40:f3:85:65:82
Jun 21 20:09:24 dnsmasq-dhcp[911]: DHCPREQUEST(br0) 192.168.1.76 10:40:f3:85:65:82
Jun 21 20:09:24 dnsmasq-dhcp[911]: DHCPACK(br0) 192.168.1.76 10:40:f3:85:65:82 Computer
Jun 21 20:36:30 WAN Connection: ISP's DHCP did not function properly.
Jun 21 20:36:30 DualWAN: skip single wan wan_led_control - WANRED off
Jun 21 20:36:30 stop_nat_rules: apply the redirect_rules!
Jun 21 17:53:41 miniupnpd[1894]: ioctl(s, SIOCGIFADDR, ...): Cannot assign requested address
Jun 21 17:53:41 miniupnpd[1894]: Failed to get IP for interface eth0
Jun 21 17:53:41 miniupnpd[1894]: SendNATPMPPublicAddressChangeNotification: cannot get public IP address, stopping
Jun 21 21:53:41 dnsmasq[911]: read /etc/hosts - 5 addresses

Any thoughts Merlin & Co ?

 

[RMerlin]

Any thoughts Merlin & Co ?

Known issue mentioned a couple of times on the forums, Asus broke something in their recent code. No idea what it is, as I can't reproduce it either. It's probably something within the wanduck daemon, and that piece of code is a horrible mess.

 

[saytr79]

Known issue mentioned a couple of times on the forums, Asus broke something in their recent code. No idea what it is, as I can't reproduce it either. It's probably something within the wanduck daemon, and that piece of code is a horrible mess.

Ah, understood. I tried all of the suggested fixes on both my 87u and 88u. I get the same result after each reboot after about 30 minutes of internet access. It started with 380.59 and was hoping it was something that was addressable in 360_Beta 1 but as you said, it looks like it's something we have to wait on Asus to address.

Thanks Merlin.

 

[agh1701]

Known issue mentioned a couple of times on the forums, Asus broke something in their recent code. No idea what it is, as I can't reproduce it either. It's probably something within the wanduck daemon, and that piece of code is a horrible mess.

Does this effect all routers specifically the rt-68u?

 

[RMerlin]

Does this effect all routers specifically the rt-68u?

I don't know. So far only a very small group of people are affected, so it's impossible to tell what is causing it, or who is affected and who isn't.

I've got a pair of WAN-related fixes on Github that were suggested by another developer. We do not know if they are related to that very specific issues (as we have no info as to what is the root cause), we'll see once I release a new beta build if it helps those affected.

 

[RMerlin]

Ah, understood. I tried all of the suggested fixes on both my 87u and 88u. I get the same result after each reboot after about 30 minutes of internet access. It started with 380.59 and was hoping it was something that was addressable in 360_Beta 1 but as you said, it looks like it's something we have to wait on Asus to address.

Thanks Merlin.

If your issue started with 380.59 then it's a different issue. It might be related to the issues that have been fixed this week in my development code. Try again with the next build to see if those fixes help with your specific case.

 

[JohnNerd]

Just want to say that DLNA is working flawless here. Good work.

 

[RMerlin]

Just want to say that DLNA is working flawless here. Good work.

Did you have any problem with previous versions?

 

[Deleted member 22229]

Want to add some feed back here about the WAN disconnect issue. I have been seeing this as well thought it was my ISP or modem. It's NOT. 3 different modems the latest SB-6190. Long story short router log shows the wan disconnect errors like others have posted, i have even seen the router wan light go red when it happens. I know a comcast high level employee i had check my modem when the 3100 would log these errors and sure enough my modem had NOT disconnected from the network nor where there and logs.correctable code words and the up time did not reset. Not the modem or connection. It's the firmware and it's not Merlin's fault because this is also present in 3341 stock.

Used Kev-Tec info to restore older code and reverted back to 380.858 and all is well. Not sure what Asus did but that's a deal breaker.

 

[Shonk]

May i suggest something with the alpha/beta releases

380.60.a1 = alpha1
380.60.b1 = beta1
380.60.0 = Final

just one of my anally retentive problems
that i have to remove alpha1/beta1 from every build i compile

its much cleaner and still gets the point across that its an alpha/beta release

 

[Deleted member 48827]

Greetings, and thank you RMerlin for your excellent work!

I'm new to Merlin Firmware and this forum, coming from Tomato and ASUS stock firmware. RT-AC56U_380.60_beta1 is stable and working well for me since its release. I did run across a problem with setting up the router as an OpenVPN client.

OpenVPN client with following settings break WAN connectivity for all clients whether VPN'd or not VPN'd:
Policy Rules for 2 clients:
192.168.X.X | 0.0.0.0 | VPN
192.168.X.X | 0.0.0.0 | VPN

Accept DNS Configuration: Strict

End of Log:
Jun 21 09:51:01 openvpn-routing: Completed routing policy configuration for client 1
Jun 21 09:51:01 openvpn[29046]: Initialization Sequence Completed
Jun 21 09:51:13 WAN Connection: Fail to connect with some issues.
Jun 21 09:51:13 stop_nat_rules: apply the redirect_rules!

Problem does not occur unless "Policy Rules" is enabled.
"Strict" is the only DNS configuration that causes the problem. I prefer to use "Exclusive" and that works fine; however, some VPN services (Torguard, PIA) recommend using Strict in their setup instructions, so this could cause grief for new VPN users following those instructions.

 

[RMerlin]

May i suggest something with the alpha/beta releases

380.60.a1 = alpha1
380.60.b1 = beta1
380.60.0 = Final

just one of my anally retentive problems
that i have to remove alpha1/beta1 from every build i compile

its much cleaner and still gets the point across that its an alpha/beta release

I don't see how 380.60.b1 is any cleaner than 380.60-beta1. Most people wouldn't be able to guess that b1 stands for beta.

 

[JohnNerd]

Did you have any problem with previous versions?

I think it's more responsive, but that may just be my imagination?

 

[Circuits]

Anyone else having issues with the VPN client?


Since installing this beta on my AC88U a couple days ago (and I did a factory reset and restored using nvram-save), I lose internet access through the VPN client on the router a few times a day. I have the router configured to have all traffic from my tablet go through the VPN (using PIA). Everything works fine for a while and then stops passing traffic via the VPN. The VPN status page on the router indicates that the client is still connected (and internet works from other computers not using the VPN). If I restart the VPN or the router then it starts working again, but after a while (can be 30 minutes or a few hours) it stops working again. I did not have any issue with 380.59. Any ideas if this is something in the beta or my config?


Thanks for all your work RMerlin!

 

[ViRUS2k]

Anyone else having issues with the VPN client?


Since installing this beta on my AC88U a couple days ago (and I did a factory reset and restored using nvram-save), I lose internet access through the VPN client on the router a few times a day. I have the router configured to have all traffic from my tablet go through the VPN (using PIA). Everything works fine for a while and then stops passing traffic via the VPN. The VPN status page on the router indicates that the client is still connected (and internet works from other computers not using the VPN). If I restart the VPN or the router then it starts working again, but after a while (can be 30 minutes or a few hours) it stops working again. I did not have any issue with 380.59. Any ideas if this is something in the beta or my config?


Thanks for all your work RMerlin!

resolv-retry infinite
keepalive 10 60
nobind
persist-key
persist-tun
persist-remote-ip

--- try those custom commands.... when you connect

 

[Circuits]

resolv-retry infinite
keepalive 10 60
nobind
persist-key
persist-tun
persist-remote-ip

--- try those custom commands.... when you connect

Thanks but no luck. Upon a little more digging it appears the WAN connection is having issues every so often. I do not know enough about it but could the WAN issue cause the VPN to fail and not restore? Below is the system log regarding the WAN issue.

Jun 24 13:31:35 WAN Connection: ISP's DHCP did not function properly.
Jun 24 13:31:35 DualWAN: skip single wan wan_led_control - WANRED off
Jun 24 13:31:35 stop_nat_rules: apply the redirect_rules!
Jun 24 13:31:40 WAN Connection: WAN was restored.
Jun 24 13:31:40 start_nat_rules: apply the nat_rules(/tmp/nat_rules_eth0_eth0)!​

Should I try a factory reset and enter everything in manually (instead of nvram-save)?

 

[RMerlin]

I just uploaded Beta 2. The only changes over Beta 1 are a pair of fixes related to WAN. No idea if it's related to the most frequently discussed issue that was added in recent Asus GPL, so please give this new build a try.