Release Asuswrt-Merlin 386.7 is now available for all models

[dave14305]

So for those of us with less of a grasp on what has been discussed in terms of IPV6 and DNSFilter, is the issue just for devices that are using only a manually entered IPV6 DNS address? And is it actually breaking resolution/or causing a router issue?

It would only affect an IPv6 device trying to use a different IPv6 server when DNSFilter is in Router mode. It creates the log messages, but the features work fine.

 

[Paliv]

It would only affect an IPv6 device trying to use a different IPv6 server when DNSFilter is in Router mode. It creates the log messages, but the features work fine.

Thanks @dave14305 , I’m always learning something here.

 

[SomeWhereOverTheRainBow]

It would only affect an IPv6 device trying to use a different IPv6 server when DNSFilter is in Router mode. It creates the log messages, but the features work fine.

I wonder if such a kernel message could be suppressed at the firmware level. Probably not, probably wouldn't want to suppress it any ways incase other anomalous messages appear that need to be seen.

 

[thecheapseats]

It would only affect an IPv6 device trying to use a different IPv6 server when DNSFilter is in Router mode. It creates the log messages, but the features work fine.

Yes it seems that way - I'm watching this discussion closely for resolve - looking forward to a less cluttered Syslog... fun with error trapping...

 

[coolest35]

Definitely not that tech savvy, but I've got 2x AX86U (1 primary, 1 node -- wired backhaul), both updated to 386.7.

I'm getting random connection drops, more frequently on 5Ghz. The syslog shows:

Jun 30 11:18:55 wlceventd: wlceventd_proc_event(469): eth7: Deauth_ind 50:84:920:3A:9F, status: 0, reason: Unspecified reason (1)
Jun 30 11:18:55 wlceventd: wlceventd_proc_event(505): eth7: Auth 50:84:920:3A:9F, status: Successful (0)
Jun 30 11:18:56 wlceventd: wlceventd_proc_event(486): eth7: Disassoc 50:84:920:3A:9F, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8)
Jun 30 11:18:56 wlceventd: wlceventd_proc_event(486): eth7: Disassoc 50:84:920:3A:9F, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8)
Jun 30 11:18:56 hostapd: eth7: STA 50:84:92:d0:3a:9f IEEE 802.11: disassociated
Jun 30 11:18:56 hostapd: eth7: STA 50:84:92:d0:3a:9f IEEE 802.11: disassociated
Jun 30 11:18:56 dnsmasq-dhcp[3270]: DHCPREQUEST(br0) 192.168.50.233 50:84:92:d0:3a:9f
Jun 30 11:18:56 dnsmasq-dhcp[3270]: Ignoring domain XXXXX.com for DHCP host name DELLXXXXXXXXXX
Jun 30 11:18:56 dnsmasq-dhcp[3270]: DHCPACK(br0) 192.168.50.233 50:84:92:d0:3a:9f DELLXXXXXXXXXX
Jun 30 11:20:30 wlceventd: wlceventd_proc_event(486): eth7: Disassoc 1A8:91:BE:85:B7, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8)
Jun 30 11:20:30 wlceventd: wlceventd_proc_event(486): eth7: Disassoc 1A8:91:BE:85:B7, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8)
Jun 30 11:20:30 hostapd: eth7: STA 1a:d8:91:be:85:b7 IEEE 802.11: disassociated
Jun 30 11:20:30 hostapd: eth7: STA 1a:d8:91:be:85:b7 IEEE 802.11: disassociated
Jun 30 11:20:42 acsd: eth7: NONACSD channel switching to channel spec: 0xe22a (44/80)
Jun 30 11:36:47 dnsmasq-dhcp[3270]: DHCPREQUEST(br0) 192.168.50.233 50:84:92:d0:3a:9f
Jun 30 11:36:47 dnsmasq-dhcp[3270]: Ignoring domain corp.XXXXXX.com for DHCP host name DELLXXXXXXXXXX
Jun 30 11:36:47 dnsmasq-dhcp[3270]: DHCPACK(br0) 192.168.50.233 50:84:92:d0:3a:9f DELLXXXXXXXXXX
Jun 30 11:36:52 dnsmasq-dhcp[3270]: DHCPREQUEST(br0) 192.168.50.183 18:26:49:77:ca:54
Jun 30 11:36:52 dnsmasq-dhcp[3270]: DHCPACK(br0) 192.168.50.183 18:26:49:77:ca:54 DESKTOP-XXXXXXXX

Any ideas on what's happening or should I revert to last stable 386.5?

TIA.

 

[gibson5094]

I have a RT-AC5300 currently on 386.5_2. Trying to update to 386.7, but I'm receiving the error:

Invalid Firmware Upload
To comply with regulatory amendments, we have modified our certification rule to ensure better firmware quality. This version is not compatible with all previously released ASUS firmware and uncertified third party firmware. Please check our official websites for the certified firmware.

Tried multiple browsers and computers, still no luck here

 

[SomeWhereOverTheRainBow]

I have a RT-AC5300 currently on 386.5_2. Trying to update to 386.7, but I'm receiving the error:

Invalid Firmware Upload
To comply with regulatory amendments, we have modified our certification rule to ensure better firmware quality. This version is not compatible with all previously released ASUS firmware and uncertified third party firmware. Please check our official websites for the certified firmware.

Tried multiple browsers and computers, still no luck here

Try unmounting an usb storages before flashing? Try rebooting if issue doesn't go away.

 

[ualdrivr]

Dirty upgrade from 386.5_2 on both main router (AC86U) and node (AC68U v3).

Forgot to remove the USB (again) before upgrading but all went without a hitch, and running smoothly so far.

Thanks RMerlin for your work!

Do you have to remove the USB drive before upgrading???? That's a first one on me. I never do and I never had issues with it.....

 

[capncybo]

Do you have to remove the USB drive before upgrading???? That's a first one on me. I never do and I never had issues with it.....

Over the years... I've heard different things regarding the USB removal recommendation.
-Heard that during a Firmware Upgrade Not doing so... increased the risk of file corruption on that USB-device
-Recently, I read the reason for removing the USB was to release some of the resources that get used up when putting the file contents of the USB into cache...
Apparently running low on the router resources can impair the devices chances of a successful firmware flash.
However, not all of these routers were create equal & I'm of the opinion that for many routers... it is no-longer necessary.
I have found through my own experimentation... one of the RT-AC86U of which I look after... was the most picky in regards to firmware flashing.

 

[N7389]

Dirty upgrade from 386.5_2 on two modes, AC86U and AC88U followed by main router AX88U, 60+ wifi devices, and all working, seamless upgrade.
Thank you Merlin for your great work

 

[ualdrivr]

Over the years... I've heard different things regarding the USB removal recommendation.
-Heard that during a Firmware Upgrade Not doing so... increased the risk of file corruption on that USB-device
-Recently, I read the reason for removing the USB was to release some of the resources that get used up when putting the file contents of the USB into cache...
Apparently running low on the router resources can impair the devices chances of a successful firmware flash.
However, not all of these routers were create equal & I'm of the opinion that for many routers... it is no-longer necessary.
I have found through my own experimentation... one of the RT-AC86U of which I look after... was the most picky in regards to firmware flashing.

That was a great explanation. Prior to upgrading my entire Router system in our house, I had for year the trusty 'ole RT-AC68U router with a Seagate 1T drive on it. I was running John's 374 LTS Fork firmware. I always upgraded with the drive connected with no issues at all. My new setup consists of the new GT-AX6000 with a RT-AX86U in a backhaul wired mesh. I did the upgrade the other day to both with Merlin's new 386.7 and again the drive stayed connected.

 

[SomeWhereOverTheRainBow]

Over the years... I've heard different things regarding the USB removal recommendation.
-Heard that during a Firmware Upgrade Not doing so... increased the risk of file corruption on that USB-device
-Recently, I read the reason for removing the USB was to release some of the resources that get used up when putting the file contents of the USB into cache...
Apparently running low on the router resources can impair the devices chances of a successful firmware flash.
However, not all of these routers were create equal & I'm of the opinion that for many routers... it is no-longer necessary.
I have found through my own experimentation... one of the RT-AC86U of which I look after... was the most picky in regards to firmware flashing.

I have ran into an issue where not atleast unmounting the usb led to a hung process preventing the flash from happening. Tried a second time, still hung process kept usb from unmounting and the flash did not take. Third time, I had to do a firmware recovery. Until this incident, I was like you where I never unmounted and flew by the seat of my pants in flashing.

 

[capncybo]

I have ran into an issue where not atleast unmounting the usb led to a hung process preventing the flash from happening. Tried a second time, still hung process kept usb from unmounting and the flash did not take. Third time, I had to do a firmware recovery. Until this incident, I was like you where I never unmounted and flew by the seat of my pants in flashing.

Thank you for sharing this information & pointing it out to others... Logically speaking... the MORE processes running & initiated via USB... obviously the greater the chances of this happening.
Especially considering the recent findings of "STUCK" processes.
Again... most common on the Ol' RT-AC86U (Fun Times)

 

[SomeWhereOverTheRainBow]

Thank you for sharing this information & pointing it out to others... Logically speaking... the MORE processes running & initiated via USB... obviously the greater the chances of this happening.
Especially considering the recent findings of "STUCK" processes.
Again... most common on the Ol' RT-AC86U (Fun Times)

This was on an Ol'RTAC5300. Apparently, it was one of the developer scripts running in the background that was performing sometype of process where it was writing to the usb. Fun stuff, in heinsight , if I had unmounted it would have given the script enough time to bale out before the routers restart unclean unmounted it and router firmware would have properly took.

 

[ualdrivr]

As I mentioned above, last Monday I upgraded both my GT-AX6000 and the wired meshed RT-AX86U to @RMerlin 's 386.7. I was on trip for the last three days. My wife was complaining of random WiFi drops throughout the day. I told her to reboot her iPhone and iPad. It kept happening though. I just came back today. I rebooted everything from Modem to routers. Everything appeared to be working again, until it didn't, again....
I just re-installed the two previous versions, 386.6 and 386.5 respectively. See what happens.... I wish that yellow exclamation mark stopped flashing... Anyone else had these issues?

 

[laracroftonline]

I went back to 386.5_2 because it's stable and I had lots of connection drops on 368.7 also my connection was 2/3 slower.

 

[Smokey613]

I went back to 386.5_2 because it's stable and I had lots of connection drops on 368.7 also my connection was 2/3 slower.

Same here, so I rolled back to 386.5_2. It is very stable and I see no reason to update at this time.

 

[capncybo]

Same here, 386.5_2 is very stable and I see no reason to update at this time.

Hmmm I'm curious... were you & Laura running the 2.4 & 5G Radios with a separate SSID for each radio on the router.
Or were you using the combined Single SSID method.
All the electronic voodo magic (I mean automatic settings) with auto-switching & multiple AP or Nodes, Especially with overlapping areas of coverage in a household...
Have me looking as to the "why" a device chooses to disconnect.
Do they assume... suddenly, they have found a superior connection. (as in a Better Signal, or faster wifi connection type)

 

[tetar]

My devices: 2 x TR-AX86U / 2.5Gbps backhaul / smatr connect dual-band 2.4Ghz + 5GHz / without factory reset.

I went back to 386.5_2, it's stable and better for me. Version 386.7 = I had a problem with Sam S22 Ultra connections (5GHz / 160MHz channel band). Frequent disconnections and slow connections, WIFI speed drops from 900Mbps ---> 150Mbps ---> 50Mbps.

 

[Wistuplu]

Thank you RMerlin for the release, and to all those that contributed e.g. as beta testers.
After 6 days, all good on my AC-86U.
Best regards