[Beta] Asuswrt-Merlin 380.65 Beta is now available

[dlandon]

I'd also add the AC88U (which is pretty much the AC3100) and AC5300.

I also see this on the AC5300.

 

[RMHC]

I'd also add the AC88U (which is pretty much the AC3100) and AC5300.

Makes sense, as these three models share the same Broadcom CPU and Wi-Fi SoC chips......

 

[nagle3092]

I'm not referring to the UPnP option that configures ports through the firewall... I'm talking about network discovery (UPnP). It certainly has something to do with how printers and other devices on a network can advertise and discover each other... it was standardized in 1999 just for that purpose.
Reference: UPnP Forum, What is UPnP, UPnP in Windows


If it was one of my clients, then why does it work on the older firmware perfectly and not the new one. There had to be a change that caused the problem.

Also, I am not the only one with this issue. There have been at least 3-4 others in this same thread and there are several in the Asus firmware forum here as well as Asus' own forum with the same exact problem:

https://vip.asus.com/forum/view.asp...d_id=11&model=RT-AC88U&page=1&SLanguage=en-us

https://vip.asus.com/forum/view.asp..._id=11&model=RT-AC5300&page=1&SLanguage=en-us

https://www.snbforums.com/threads/asus-rt-5300-version-3-0-0-4-380-3941.34015/page-3

I know that as of Beta 2 I was unble to communicate with local devices like hue, harmony. Echo couldn't communicate with these devices either.

Reflashing 380.64_2 and now I can directly connect to these devices again. Until then I would say just roll back and stay on that build if you need those devices to work.

 

[eddiez]

I know that as of Beta 2 I was unble to communicate with local devices like hue, harmony. Echo couldn't communicate with these devices either.

Reflashing 380.64_2 and now I can directly connect to these devices again. Until then I would say just roll back and stay on that build if you need those devices to work.

Problem is not present on AC68 with b3

 

[effortless]

I know that as of Beta 2 I was unble to communicate with local devices like hue, harmony. Echo couldn't communicate with these devices either.

Reflashing 380.64_2 and now I can directly connect to these devices again. Until then I would say just roll back and stay on that build if you need those devices to work.

The setting in the router to enable UPnP is not the same as the UPnP protocol that is used for device advertisement and discovery. The UPnP setting on the router allows for ports to automatically get configured to allow P2P applications, interactive gaming, video conferencing, and web or proxy servers. The UPnP I'm referring to is the network discovery portion which is not disabled by turning off UPnP from the WAN settings.

If there is a problem with the network discovery (AKA UPnP), devices would have valid assigned IPs, but they wouldn't be saying... hey, hey, look at me I'm a printer or I'm a scanner or I'm an Amazon Echo or even a media server and I can see you're saying you're a PC that wants to access my services. If you want to be technical, "UPnP assumes the network runs Internet Protocol (IP) and then leverages HTTP, SOAP and XML on top of IP, in order to provide device/service description, actions, data transfer and eventing. Device search requests and advertisements are supported by running HTTP on top of UDP (port 1900) using multicast (known as HTTPMU). Responses to search requests are also sent over UDP, but are instead sent using unicast (known as HTTPU)." Something there is broken on the AC3100, AC88U and the AC5300.

http://lifehacker.com/5803975/what-is-upnp-and-how-do-i-use-it-to-stream-media-to-my-tv (example/info here)

 

[unsynaps]

Why everyone just does not go with ZeroConfig I will never know. UPnP is redundant.

 

[cybrnook]

Merlin, is the host-name format correct (0000)?

 

[cybrnook]

Also, seem normal? Don't remember WebUI choking on stock PIA ovpn files before (and before you say it, I did also try saving the CA first, and then importing ovpn....same thing):

And "default"ing a failed config sends the timer for a spin cycle:

Of course I can still manually setup the VPN tunnel by inputting the fields 1 by 1, but that's no fun. (I have to think.........)

 

[ramblefish]

Hello. What remains of the old firmware components due to not fully GPL license for the router ASUS RT-AC66U? I'm talking about it - The RT-N66U, RT-AC66U, RT-AC56U and RT-AC3200 have to reuse some older closed source components due to incomplete / missing GPL release from Asus. Look for any unusual behaviour, especially regarding wifi.

 

[ManuCH]

Problem is not present on AC68 with b3

Problem is not present on the AC3200 with B3 either.

 

[bradbort]

To those having the "scanner issue": is there a consistent way to reproduce it, or is it just random?

I'm not seeing the problem on my RT-AC3200 with 380.65_beta3.

For me, with a brother MFC-2740 laser it is consistently reproducible. I have read others on this list with HP devices experiencing the same problem. I have also read others who have brother devices that are not designated MFC's, but have scanners, that don't have the problem. I'm wondering it it has something to do with FAX functionality scanning (which mine has) vs other scanner devices that don't have it...some sort of protocol difference.

At any rate, what I've seen consistently in my RT-AC3100 is:

• With the 380.64 builds by merlin, everything is fine.
• If I go up to the .65 builds that incorporate the newest ASUS firmware, it breaks the scanner over wireless ability. The scanner/PC do not seem to be able to find each other. Strangely enough, printing on the same device is not a problem.
• Sometimes, when reverting to the .64 build, I have to reboot the router in order for things to work properly again.
• I have the same issue if I just install the latest ASUS firmware. The new code breaks wireless scanning on my brother MFC.
• REbooting everything, resetting to defaults, banging my head against a desk all do not help. Resetting to the prior Merlin firmware that is not based on the most recent ASUS code does.
• I also believe that the newest code kills the wireless connectivity of my SONOS system (although I have not verified that as extensively). When I experienced it, I merely installed a sonos bridge I had around, that lets sonos run on its own mesh network, and everything was fine. Without the bridge, none of my clients could find the sonos system anymore.

 

[discovery2k]

For me, with a brother MFC-2740 laser it is consistently reproducible. I have read others on this list with HP devices experiencing the same problem. I have also read others who have brother devices that are not designated MFC's, but have scanners, that don't have the problem. I'm wondering it it has something to do with FAX functionality scanning (which mine has) vs other scanner devices that don't have it...some sort of protocol difference.

At any rate, what I've seen consistently in my RT-AC3100 is:

• With the 380.64 builds by merlin, everything is fine.
• If I go up to the .65 builds that incorporate the newest ASUS firmware, it breaks the scanner over wireless ability. The scanner/PC do not seem to be able to find each other. Strangely enough, printing on the same device is not a problem.
• Sometimes, when reverting to the .64 build, I have to reboot the router in order for things to work properly again.
• I have the same issue if I just install the latest ASUS firmware. The new code breaks wireless scanning on my brother MFC.
• REbooting everything, resetting to defaults, banging my head against a desk all do not help. Resetting to the prior Merlin firmware that is not based on the most recent ASUS code does.
• I also believe that the newest code kills the wireless connectivity of my SONOS system (although I have not verified that as extensively). When I experienced it, I merely installed a sonos bridge I had around, that lets sonos run on its own mesh network, and everything was fine. Without the bridge, none of my clients could find the sonos system anymore.

With this beta build installed on my RT-AC88U, I was having scanning and wireless discovery issues with my HP printer. My Plex media server also had discovery issues.

 

[IronSchramm]

First off, Merlin, you're firmwares are always rock solid for me, even the betas, and I apologize if this issue has been covered, I have been keeping an eye on this thread since Beta2 dropped and didn't see an exact reference or anyone providing the same log activity I'm seeing so I thought I would provide what I'm seeing.

I have an RT-AC66U, and have been running 65_B2 when I noticed the issue. My wife's 2011 iMac seemed to be dropping off the network repeatedly. I checked the logs on the iMac itself and saw repeated DHCP requests every 10 minutes. The router system logs would show the same behavior. I rolled back to 64_2 and the issue disappeared. Yesterday afternoon I saw that 65_B3 dropped, hoping that resolved the issue I flashed that. While watching a movie on our Vizio SmartCast TV, I noticed the included android remote was having issues connecting to either of the wireless radios. I checked the router system logs and see this, every 10 minutes:
------
Jan 29 07:44:16 dnsmasq-dhcp[246]: DHCPREQUEST(br0) 192.168.1.200 a4:8d:3b:ef:48:13
Jan 29 07:44:16 dnsmasq-dhcp[246]: DHCPACK(br0) 192.168.1.200 a4:8d:3b:ef:48:13 android-281194c4ab8425de
Jan 29 07:54:20 dnsmasq-dhcp[246]: DHCPDISCOVER(br0) a4:8d:3b:ef:48:13
Jan 29 07:54:20 dnsmasq-dhcp[246]: DHCPOFFER(br0) 192.168.1.200 a4:8d:3b:ef:48:13
Jan 29 07:54:20 dnsmasq-dhcp[246]: DHCPREQUEST(br0) 192.168.1.200 a4:8d:3b:ef:48:13
Jan 29 07:54:20 dnsmasq-dhcp[246]: DHCPACK(br0) 192.168.1.200 a4:8d:3b:ef:48:13 android-281194c4ab8425de
Jan 29 08:04:25 dnsmasq-dhcp[246]: DHCPDISCOVER(br0) a4:8d:3b:ef:48:13
Jan 29 08:04:25 dnsmasq-dhcp[246]: DHCPOFFER(br0) 192.168.1.200 a4:8d:3b:ef:48:13
Jan 29 08:04:25 dnsmasq-dhcp[246]: DHCPREQUEST(br0) 192.168.1.200 a4:8d:3b:ef:48:13
Jan 29 08:04:25 dnsmasq-dhcp[246]: DHCPACK(br0) 192.168.1.200 a4:8d:3b:ef:48:13 android-281194c4ab8425de
Jan 29 08:14:30 dnsmasq-dhcp[246]: DHCPDISCOVER(br0) a4:8d:3b:ef:48:13
Jan 29 08:14:30 dnsmasq-dhcp[246]: DHCPOFFER(br0) 192.168.1.200 a4:8d:3b:ef:48:13
Jan 29 08:14:30 dnsmasq-dhcp[246]: DHCPREQUEST(br0) 192.168.1.200 a4:8d:3b:ef:48:13
Jan 29 08:14:30 dnsmasq-dhcp[246]: DHCPACK(br0) 192.168.1.200 a4:8d:3b:ef:48:13 android-281194c4ab8425de
Jan 29 08:24:34 dnsmasq-dhcp[246]: DHCPDISCOVER(br0) a4:8d:3b:ef:48:13
Jan 29 08:24:34 dnsmasq-dhcp[246]: DHCPOFFER(br0) 192.168.1.200 a4:8d:3b:ef:48:13
Jan 29 08:24:34 dnsmasq-dhcp[246]: DHCPREQUEST(br0) 192.168.1.200 a4:8d:3b:ef:48:13
Jan 29 08:24:34 dnsmasq-dhcp[246]: DHCPACK(br0) 192.168.1.200 a4:8d:3b:ef:48:13 android-281194c4ab8425de
------

I am going to flash back to 64_2, but I just wanted to bring this to your attention. If I can provide any other helpful information please let me know.

Thanks,
-IronSchramm

 

[bigcid10]

I flashed this 380.65 b3 FW yesterday and twice I lost the wireless radios
my phone will see the ssid but can't connect ,I have to turn off the wireless 5GHz radio and turn it back on
Thank you

 

[RMerlin]

Merlin, is the host-name format correct (0000)?

Broadcom's fracked up GMAC3 architecture causes a whole bunch of problems with MAC addresses and network interfaces. This is yet another consequence of this - the WAN MAC is stored in a different nvram at boot time, and the original one is blanked out. This is most likely the same non-sense that was also breaking IPv6.

GMAC3 is what is giving us this little gem in the router's init code:

        switch(get_model()) {
                case MODEL_RTAC87U:
                case MODEL_RTAC5300:
                case MODEL_RTAC5300R:
                case MODEL_RTAC88U:
                        nvram_set("et2mdcport", cfe_nvram_get("et1mdcport"));
                        nvram_set("et2phyaddr", cfe_nvram_get("et1phyaddr"));
                        nvram_set("et2macaddr", cfe_nvram_get("et1macaddr"));

                        nvram_set("et1macaddr", "00:00:00:00:00:00");

                        nvram_set("et0macaddr", "00:00:00:00:00:00");
                        nvram_set("et0mdcport", cfe_nvram_get("et1mdcport"));
                        nvram_set("et0phyaddr", cfe_nvram_get("et1phyaddr"));

Now, since various parts of the router were still relying on et1macaddr, we end up with broken IPv6 (DUID request was using 00:00:00:00:00:00 as its MAC), the hostname that you see, possibly other daemons also trying to use the WAN MAC to generate a unique identifier ending up reading the cleared MAC instead of the valid one.

I fixed what I could see, but short of analyzing the entire source code, this won't ever be completely fixed by me. Broadcom/Asus will have to sort it out.


Broadcom's platform performance sucks in general, so they rely on a lot of dirty hacks and weird workarounds to try to keep up. CTF, FA, GMAC3... All of these are a bunch of esoteric, blackbox technologies that seem to cause a whole lot of issues.

Qualcomm is starting to run in circles around Broadcom. They got quadcore 1.7 GHz out nearly two years before Broadcom's own quadcore CPU will hit retail devices. They also got working MU-MIMO about 18 months before Broadcom did.

And I ain't talking about the quality of their SDK code. Devs can take a look at two recent commits I've pushed to Git in the past few days... That broken code had been there for years. I also wasted nearly two weeks in the early BCM4708 days tracking down a bunch of buffer overflows also in their kernel nvram code, which was randomly causing routers to crash at boot time until you did a factory default reset.

I can see Broadcom starting to lose serious market shares in the home router world if they don't keep up with the competition any better than they've been doing lately.

 

[RMerlin]

Also, seem normal? Don't remember WebUI choking on stock PIA ovpn files before (and before you say it, I did also try saving the CA first, and then importing ovpn....same thing):

Impossible for me to tell, not knowing what's in this actual ovpn file.

 

[CiASpook]

Anyone else having issues getting DHCP on 2,4GHz?

EDIT: My printer and Windows are having issues getting IP on 2,4GHz.

 

[bobiii]

my rt5300 has the same problem with scanners. Mine is an Epson and it can't find it under beta's 1, 2 or 3. Going back to 64_2. Will have to wait for Asus to get their s____ together.

 

[cybrnook]

Impossible for me to tell, not knowing what's in this actual ovpn file.

They are pretty vanilla. Here is their hosted ovpn and CA files:

https://www.privateinternetaccess.com/openvpn/openvpn.zip

client
dev tun
proto udp
remote us-midwest.privateinternetaccess.com 1198
resolv-retry infinite
nobind
persist-key
persist-tun
cipher aes-128-cbc
auth sha1
tls-client
remote-cert-tls server
auth-user-pass
comp-lzo
verb 1
reneg-sec 0
crl-verify crl.rsa.2048.pem
ca ca.rsa.2048.crt
disable-occ

FYI, same behavior exists in the current "stable" build as well. (The GUI Snapping in and out in chrome, and OpenVPN not accepting the ovpn files)

 

[Naftali Oziel]

Broadcom's fracked up GMAC3 architecture causes a whole bunch of problems with MAC addresses and network interfaces. This is yet another consequence of this - the WAN MAC is stored in a different nvram at boot time, and the original one is blanked out. This is most likely the same non-sense that was also breaking IPv6.

GMAC3 is what is giving us this little gem in the router's init code:

        switch(get_model()) {
                case MODEL_RTAC87U:
                case MODEL_RTAC5300:
                case MODEL_RTAC5300R:
                case MODEL_RTAC88U:
                        nvram_set("et2mdcport", cfe_nvram_get("et1mdcport"));
                        nvram_set("et2phyaddr", cfe_nvram_get("et1phyaddr"));
                        nvram_set("et2macaddr", cfe_nvram_get("et1macaddr"));

                        nvram_set("et1macaddr", "00:00:00:00:00:00");

                        nvram_set("et0macaddr", "00:00:00:00:00:00");
                        nvram_set("et0mdcport", cfe_nvram_get("et1mdcport"));
                        nvram_set("et0phyaddr", cfe_nvram_get("et1phyaddr"));

Now, since various parts of the router were still relying on et1macaddr, we end up with broken IPv6 (DUID request was using 00:00:00:00:00:00 as its MAC), the hostname that you see, possibly other daemons also trying to use the WAN MAC to generate a unique identifier ending up reading the cleared MAC instead of the valid one.

I fixed what I could see, but short of analyzing the entire source code, this won't ever be completely fixed by me. Broadcom/Asus will have to sort it out.


Broadcom's platform performance sucks in general, so they rely on a lot of dirty hacks and weird workarounds to try to keep up. CTF, FA, GMAC3... All of these are a bunch of esoteric, blackbox technologies that seem to cause a whole lot of issues.

Qualcomm is starting to run in circles around Broadcom. They got quadcore 1.7 GHz out nearly two years before Broadcom's own quadcore CPU will hit retail devices. They also got working MU-MIMO about 18 months before Broadcom did.

And I ain't talking about the quality of their SDK code. Devs can take a look at two recent commits I've pushed to Git in the past few days... That broken code had been there for years. I also wasted nearly two weeks in the early BCM4708 days tracking down a bunch of buffer overflows also in their kernel nvram code, which was randomly causing routers to crash at boot time until you did a factory default reset.

I can see Broadcom starting to lose serious market shares in the home router world if they don't keep up with the competition any better than they've been doing lately.

Just to clarify, all the issues encountered with 380.65 are specific to only the models below? I ask as I was going to get other Asus models but will stay away and remain with AC68U.

RTAC87U
RTAC5300
RTAC5300R
RTAC88U