I'd also add the AC88U (which is pretty much the AC3100) and AC5300.
I also see this on the AC5300.
I'd also add the AC88U (which is pretty much the AC3100) and AC5300.
I'd also add the AC88U (which is pretty much the AC3100) and AC5300.
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
Problem is not present on AC68 with b3I 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.
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
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.
Merlin, is the host-name format correct (0000)?
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"));
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.
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:
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.
Welcome To SNBForums
SNBForums is a community for anyone who wants to learn about or discuss the latest in wireless routers, network storage and the ins and outs of building and maintaining a small network.
If you'd like to post a question, simply register and have at it!
While you're at it, please check out SmallNetBuilder for product reviews and our famous Router Charts, Ranker and plenty more!