Release Asuswrt-Merlin 386.7 is now available for all models

[learning_curve]

~~~ 49335 also has a number of fixes related to IPv6 DDNS support. I initially started backporting the changes, then decided not to mid-way as the changes were too complex, and would have required an extra beta cycle to properly test.

Previous offer of specific IPv6 testing still stands. From me and the IPv6 others, if, that is useful in the future.

 

[eclp]

Can someone please confirm whether the dcd tainted error with activated aiprotection still occurs with the new release? Last had this message in a continuous loop on my ax88u, only after completely deactivating aiprotection did the error no longer occur.

 

[Sneakytiki]

Can someone please confirm whether the dcd tainted error with activated aiprotection still occurs with the new release? Last had this message in a continuous loop on my ax88u, only after completely deactivating aiprotection did the error no longer occur.

That might be the only error I have not been getting, I did get it when I first did a dirty upgrade, also got some type of FPM broadcom errors. I got rid of diversion and did a complete reset with some other network updates and no longer see the message. I run AIProtection, Adguard, Skynet (may get rid of this soon, its hard to manage lists with a family and redundant), plus Unbound, YaziFI, scMerlin, and connmon. I could not get ntpMerlin or the router ntpService to work on my AX11000 for some reason. My 386.7 issues are listed below and most are fixed or not noticeable with a stable network.

I have those type of logs on a AX88U and AX11000(and I think I saw a post of it happening on a AX86U also) on 386.7. Usually when those logs start to show up hours after a reboot, devices connected to my XT8 node start to report offline even though they are connected, so I have reverted to 386.5_2 and will skip this release as this behavior has been happening on all the alphas and betas for this GPL

I got those error messages on the AX88U and an AX11000 after a day or two, although they do not seem to cause or be the cause of my network issues with 386.7. Flashing back to 386.5_2 gets rid of them, maybe just debug messages.

The deauth messages were going until I increased the distance between the routers in AIMesh by 15-20 feet. Old firmware no issues, new firmware many devices were bouncing between the routers and disconnecting. This occurred between an AC3100 as a node and the AX88U.

Increasing distance still had issues with selecting or using 160Mhz and selecting anything but auto for channel selection between the AC3100 and AX88U, using an AX11000 and an AX88U as a node got rid of the config problem for all devices. Now we only get deauth messages on two apple watches which are notorious for connecting and disconnecting from wifi. Using the AC3100 with an AX88U or AX11000 caused issues with channel selection and width of channel.

My noticeable issues with new 386.7:

​

• WAN Aggregation (two cables between router and modem) does not work with 386.7, works with all previous firmware - probably the only issue that can be reproduced or fixed by ASUS.

​

• Using AC nodes with AX primary reduces number of channels and use of 160mhz, no idea why.

​

• Had to increase distance between routers to reduce 5Ghz devices from bouncing around network and disconnecting (probably a preexisting interference issue, made visible with update)

​

• 2.4Ghz devices (especially cameras and doorbells) disconnecting (from internet, not router) when setting up router as an ntp server since they could not sync with the recording and access service. With ntpMerlin chrony was rapid firing at sites to update, large drift and offset (up to 1 second), can't synchronize; no majority. This could be something with my network and the AX11000, just disabled it to get everything up and running. Skynet or some ipv6 maybe? This is the first release I have tried ipv6. Could be a borked new router too.

​

• AIMesh wireless backhaul and 5Ghz are only stable when the backhaul is different from the 5Ghz network, both are set to auto and to automatically select channel width.

​

Keep in mind that this is a hobby of mine, I am not computer science trained so many or most errors are probably my fault. My comfort zone is infectious disease, epidemiology, and molecular biology but I did experiment quite a bit at the expense of my very patient wife and family to figure out the above.

386.7 is now stable and works great on our network. Appreciate the hard work on this release. Final network is AX11000 connected to a Netgear CM2050V on Comcast Xfinity (1200/35(we get 50-60) with a AX88U node. We can get over 1200 and about 50 through the modem and 300-800 down and 50 up on wireless through the router.

 

[Darkje]

It's mostly open sourced (part of the code that sets up the routes is closed source tho), but as indicated by Dave, the code is quite complicated to follow, so I don't dare touch it, as it's all tied to the regular WAN code as well. Making any change to the Dual WAN code runs the risk of breaking regular WAN code as a whole, and to completely break the instant Asus makes more changes of their own.

I encourage people encountering Dual WAN issues to reach out to Asus about it. Asus and I discussed the Dual WAN implementation in the past, they are certainly interested in getting more feedback about it. They've been constantly making improvements to it over the years. It's just not something I am in a position to test/debug myself.

The thing is that it is known what the problem is, i do have a feeling that Asus dont want or know how to fix it. Although you said there have been made many changes. I cannot tell if this is true, but i do thrust on you opinion. Although in the official Asus section of this forum it has been awful quit from the asus side. If you take fresh tomato ( i believe you do their something also ) they have a really good multiwan system that is fully functional.

 

[capncybo]

That might be the only error I have not been getting, I did get it when I first did a dirty upgrade, also got some type of FPM broadcom errors. I got rid of diversion and did a complete reset with some other network updates and no longer see the message. I run AIProtection, Adguard, Skynet (may get rid of this soon, its hard to manage lists with a family and redundant), plus Unbound, YaziFI, scMerlin, and connmon. I could not get ntpMerlin or the router ntpService to work on my AX11000 for some reason. My 386.7 issues are listed below and most are fixed or not noticeable with a stable network.




I got those error messages on the AX88U and an AX11000 after a day or two, although they do not seem to cause or be the cause of my network issues with 386.7. Flashing back to 386.5_2 gets rid of them, maybe just debug messages.

The deauth messages were going until I increased the distance between the routers in AIMesh by 15-20 feet. Old firmware no issues, new firmware many devices were bouncing between the routers and disconnecting. This occurred between an AC3100 as a node and the AX88U.

Increasing distance still had issues with selecting or using 160Mhz and selecting anything but auto for channel selection between the AC3100 and AX88U, using an AX11000 and an AX88U as a node got rid of the config problem for all devices. Now we only get deauth messages on two apple watches which are notorious for connecting and disconnecting from wifi. Using the AC3100 with an AX88U or AX11000 caused issues with channel selection and width of channel.

My noticeable issues with new 386.7:

​

• WAN Aggregation (two cables between router and modem) does not work with 386.7, works with all previous firmware - probably the only issue that can be reproduced or fixed by ASUS.

​

• Using AC nodes with AX primary reduces number of channels and use of 160mhz, no idea why.

​

• Had to increase distance between routers to reduce 5Ghz devices from bouncing around network and disconnecting (probably a preexisting interference issue, made visible with update)

​

• 2.4Ghz devices (especially cameras and doorbells) disconnecting (from internet, not router) when setting up router as an ntp server since they could not sync with the recording and access service. With ntpMerlin chrony was rapid firing at sites to update, large drift and offset (up to 1 second), can't synchronize; no majority. This could be something with my network and the AX11000, just disabled it to get everything up and running. Skynet or some ipv6 maybe? This is the first release I have tried ipv6. Could be a borked new router too.

​

• AIMesh wireless backhaul and 5Ghz are only stable when the backhaul is different from the 5Ghz network, both are set to auto and to automatically select channel width.

​

Keep in mind that this is a hobby of mine, I am not computer science trained so many or most errors are probably my fault. My comfort zone is infectious disease, epidemiology, and molecular biology but I did experiment quite a bit at the expense of my very patient wife and family to figure out the above.

386.7 is now stable and works great on our network. Appreciate the hard work on this release. Final network is AX11000 connected to a Netgear CM2050V on Comcast Xfinity (1200/35(we get 50-60) with a AX88U node. We can get over 1200 and about 50 through the modem and 300-800 down and 50 up on wireless through the router.

Just skimmin through your post... But thinking, isn't 160mHz support more of a AX option, Meaning there might be "some-special" AC Clients that support it but... I wouldn't think nor expect 160mHz to function on every type of AC-Node. But I could be wrong.
EDIT: almost forgot, regarding increasing the distance between routers... Did you try turning down the Radio power as well?

 

[Sneakytiki]

Just skimmin through your post... But thinking, isn't 160mHz support more of a AX option, Meaning there might be "some-special" AC Clients that support it but... I wouldn't think nor expect 160mHz to function on every type of AC-Node. But I could be wrong.

Yes it never went that high on the AC3100. It still used 80 on both its back haul and the network. I could still set the primary router on 160 though. Which I did at 36 and 160 so there would not be any issues. Since the rest of the network would be fine and we only have a couple laptops that use it.

That was not possible with the update, so something changed.

 

[Tech9]

"some-special" AC Clients

It's actually a single special AC client in existence with 160MHz support on Wi-Fi 5 - Intel AC9560. Can be found in some laptops.

 

[capncybo]

If I were to guess... I might have thought that change was deliberate. Typically with electronics trying to pass data at faster rates to slower clients could cause a bottleneck, latency, potential transmission problems & of course errors.

 

[Tech9]

That was not possible with the update, so something changed.

Wireless drivers changed. It may not be a bug, but better following DFS regulations change. If you want stable Wi-Fi, use non-DFS @80MHz wide.

 

[Sneakytiki]

Wireless drivers changed. It may not be a bug, but better following DFS regulations change. If you want stable Wi-Fi, use non-DFS @80MHz wide.

I don’t think it’s a bug, some type of stability and improvement like with when my devices were bouncing between node and router because of interference until I moved the node.

Mostly posting for informational purposes so if people have similar issues maybe something I did will help.

The only thing I believe is a bug is the WAN aggregation.

 

[Darkje]

I have 160mhz enabled on ac router and I didn't find a client that connects

 

[Tech9]

The only thing I believe is a bug is the WAN aggregation.

I wouldn't even bother with WAN Aggregation on 1200/50 ISP. Just another point of failure for a better speed test.

I have 160mhz enabled on ac router and I didn't find a client that connects

See post # 669 above.

 

[Darkje]

I wouldn't even bother with WAN Aggregation on 1200/50 ISP. Just another point of failure for a better speed test.



See post # 669 above.

I know, seen it.

 

[capncybo]

IMO perhaps Enabling 160MHz should be followed up with a Stern Pop-Up warning... something like:

Are you Sure?
The Router will disconnect all 5G WiFi clients WHENEVER a wireless radar signal is detected in the area.
+ the 5G radio may not be available for > 1 minute.

So Basically flush your stability... for the hopes of faster throughput.
But ONLY on a capable client.

 

[Darkje]

IMO perhaps Enabling 160MHz should be followed up with a Stern Pop-Up warning... something like:

Are you Sure?
The Router will disconnect all 5G WiFi clients WHENEVER a wireless radar signal is detected in the area.
+ the 5G radio may not be available for > 1 minute.

So Basically flush your stability... for the hopes of faster throughput.
But ONLY on a capable client.

I don't get it, I have it enabled. And I don't find anything unstable.

 

[capncybo]

I don't get it, I have it enabled. And I don't find anything unstable.

It all depends on where you live...
In the city, near any automatic doors & sensors.
Are Police cars with Radar, or Street Signs with Radar Speed Warnings nearby?
Any Aircraft or Helicopters passing by?
If any radar waves are detected...
The router is mandated to leave, which requires the... disconnect/re-connection dance.

 

[Darkje]

It all depends on where you live...
In the city, near any automatic doors & sensors.
Are Police cars with Radar, or Street Signs with Radar Speed Warnings nearby?
Any Aircraft or Helicopters passing by?
If any radar waves are detected...
The router is mandated to leave, which requires the... disconnect/re-connection dance.

I actually enabled it to see what my node would do. Since it don't have 160mhz support.

 

[RMerlin]

It's actually a single special AC client in existence with 160MHz support on Wi-Fi 5 - Intel AC9560. Can be found in some laptops.

My Huawei P30 also supports 160 MHz channels over 802.11ac.

 

[RMerlin]

My GT-AX6000 has been set to 160 MHz for weeks now, without a single drop to 80 MHz. But I am right in the middle of the city, the airport is quite some distance away. And none of my neighbours use DFS channels, so I'm alone in that band (I saw only one neighbour pop in the DFS band a while ago, seems to have reverted back to regular channels since then).

 

[BreakingDad]

Did a dirty update from beta2 to 386.7 on my RT-AX86U. It's been running for a day and 16 hours. Functionally I don't notice any issues. I do see the following line in the log occasionally:
Jun 25 09:21:55 kernel: ^[[0;33;41mFCACHEfc_vblog_list_add ERROR: Duplicate blog: list blog<0xffffffc02f840e40> JOIN blog<0xffffffc02f82e000>^[[0m

I would be interested to know what this means as well, I am getting this on my log as well, did anyone get back to you?