[Release] Asuswrt-Merlin 380.66 is now available

[octopus]

I have updated to 380.66 and now am seeing this in the logs
May 13 21:03:52 kernel: nvram: consolidating space!
NVRAM usage 77526 / 131072 bytes
My setup
RT-AC5300 - AB-Solution 3.8.1 - DNSCrypt

Can't se any problem there.

 

[mgttr]

Asus should eventually get around to fixing it. The issue is specific to that model, and they're aware of it.

WPS switched on after loading 380.66 on my RT-AC88U as well. One nice thing I noted is the radio temperatures are displaying properly now, instead of just saying "Disabled".

 

[rtn66uftw]

It doesn't matter what you do with your ASUS router, the facts won't change. Unless you set a static IP for its WAN port, the IP it shows comes from your modem or through it from your ISP. If you got the modem from your ISP, is very common that they push updates or do some other remote reconfiguration which can affect your own settings.

I suggest you to do factory default reset for your modem and reconfigure it in bridged mode again. If you can't do this, then you need to contact your ISP support.

Apparently our landlord put some authentication on the network. That authentication link only showed up when I did the factory reset. Upon finishing the authentication, public IP address reappeared on the router WAN. Learn something new today

 

[Darcy]

Asus may have changed the setting in NVRAM, so the firmware sets the defaults which is WPS on for 2.4ghz.

Yeah mine turned on as well.


Sent from my iPhone using Tapatalk

 

[Robotech]

Upgraded to 380.66, did factory reset. Port forwarding disabled. No Triggering. The following entries show up in the system log. Any help on origin appreciated.

UPNP, NAT-PMP and PCP forwards
Proto Port Redirect to Local Port Time left Description
UDP 59694 192.168.0.209 59694 N/A Teredo 192.168.0.209:59694->59694 UDP
UDP 28048 192.168.0.168 28048 N/A Skype UDP at 192.168.0.168:28048 (3785)
TCP 28048 192.168.0.168 28048 N/A Skype TCP at 192.168.0.168:28048 (3785)

Only one of the devices actually exist in my network. These did not show up in 380.65_4

 

[reerden]

Upgraded to 380.66, did factory reset. Port forwarding disabled. No Triggering. The following entries show up in the system log. Any help on origin appreciated.

UPNP, NAT-PMP and PCP forwards
Proto Port Redirect to Local Port Time left Description
UDP 59694 192.168.0.209 59694 N/A Teredo 192.168.0.209:59694->59694 UDP
UDP 28048 192.168.0.168 28048 N/A Skype UDP at 192.168.0.168:28048 (3785)
TCP 28048 192.168.0.168 28048 N/A Skype TCP at 192.168.0.168:28048 (3785)

Only one of the devices actually exist in my network. These did not show up in 380.65_4

This is simply UPnP forwarding ports. Those ports are standard for a Windows 10 machine. The first one is the Teredo tunnel for the Xbox app, the other two Skype.

 

[Albino_Mexican]

As usual, thanks for your hard work @RMerlin. Upgraded to 380.66 from 380.65_4 on my AC87U and now the QOS download limit cannot be set to 0 (unlimited) anymore. Have not tried clearing nvram yet but I when I get a chance I will and report back.
-----
Confirmed. This occurs even after a factory reset and manual reconfiguration.

 

[Robotech]

This is simply UPnP forwarding ports. Those ports are standard for a Windows 10 machine. The first one is the Teredo tunnel for the Xbox app, the other two Skype.

Thanks, I had disabled UPnP, but overlooked the Nat Passthrough settings. Problem solved. Again thanks for replying to a rook.

 

[reerden]

This is simply UPnP forwarding ports. Those ports are standard for a Windows 10 machine. The first one is the Teredo tunnel for the Xbox app, the other two Skype.

Are these old items from when UPnP was still enabled? The port forwarding page in system log should be empty when UPnP is disabled. You may need to reboot in order for the entries to disappear after you've disabled UPnP. If they aren't, then there might be something wrong with the NVRAM setting.

The passthrough settings have nothing to do with this. They simply determine whether Teredo is allowed.

The other "device" is probably an old IP that was given to your device. You should be able to see them on the DHCP release page.

 

[Gregory Phillips]

I believe that I'm going to squat on this firmware for a while as my RT-AC88U seems to be behaving quite nicely right now. Thanks again Merlin.

 

[Makaveli]

I seem to have lost the ability to add custom icons has anyone else noticed this.

I haven't done a factory reset yet so that will be next once I get confirmation.

 

[Adamm]

Solved

 

[paulbates]

I've been using it all day on an 88, nothing unusual to report. I've been using the strict policy rules for ovpn.

Paul

 

[sbailey4]

I seem to have lost the ability to add custom icons has anyone else noticed this.

I haven't done a factory reset yet so that will be next once I get confirmation.

Working on RT-AC66R

 

[Naftali Oziel]

Asus should eventually get around to fixing it. The issue is specific to that model, and they're aware of it.

Had the same issue with my AC68U AP, WPS enabled after firmware upgrade on my 2.4 band. After disabling WPS, rebooted, WPS remained off.

 

[Makaveli]

Working on RT-AC66R

Thanks.

I will reboot and try to format jffs. If that doesn't work then its a possible bug with this fork.

 

[cybrnook]

Thanks.

I will reboot and try to format jffs. If that doesn't work then its a possible bug with this fork.

Or you need to wipe and reconfigure as XVortex called out ;-)

 

[RMerlin]

It's now almost completely useless as even ignoring the fact its called multiple times, any IPTable's rules stored here or in a script executed from here are not applied (even with ridiculous sleep timers for debugging purposes).

firewall-start is only called once, whenever a start_firewall() call is being made. There is no other reference to that script anywhere else in the code.

 

[aspen63]

Problems with Safari persist in this release. Very unstable behaviour webUI-wise. I believe Asus just doesn't test its products with this platform.

 

[Morac]

I updated my ac-88u from 380.65.2 to 380.66. Seems to be working fine, though these started popping up in my log after a few hours. Not sure what they mean or why they started occurring.

May 13 23:10:58 kernel: net_ratelimit: 1 callbacks suppressed
May 14 00:58:03 kernel: net_ratelimit: 4 callbacks suppressed
May 14 00:59:02 kernel: net_ratelimit: 1 callbacks suppressed
May 14 01:17:44 kernel: net_ratelimit: 1 callbacks suppressed
May 14 01:21:45 kernel: net_ratelimit: 2 callbacks suppressed


Edit:

For some reason IPv6 stopped working with Comcast. That hasn't happened for a number of months. I don't think it's a coincidence that it stopped working shortly after upgrading to 380.66. I tested after updating to 380.66 and it was working, but stopped some point after that.