Release Asuswrt-Merlin 388.1 is now available for all supported Wifi 6 models

[kelddamsbo]

This is normal, the router queries its own radio for a list of associated clients, it has no access to the info from other nodes' own radios.

Okay, that's a fair explanation, and make sense. Maybe something to the ideabank in the future for ASUS.
Another thing for the ideabank could be a setting for eco mode as there is in the app from ASUS.

 

[dbell]

There seems to be a growing consensus the culprit for "MOST" of the recent WiFi disconnects is actually the setting of any Control Channel to Auto
So... Don't.
Meanwhile just pick the last control channel selected, or choose a channel that seems clear (maybe verify with a Wifi App)

But this leads to my point.
I had asked RMerlin about what happens when the router changes channels, Can connected clients migrate to the re-assigned channel?
He didn't think so & seemed to guess they would disconnect momentarily.
I did some research but had problems finding a definitive answer.

To me what needs to become known is...
(When Control Channel=Auto)
How often these routers check if the channel should actually change.

From the reading I've done...
Alot of routers & likely older firmware simply checked during boot-up or initialization.
However, it does seem feasible that with newer Asus firmware...

These routers are changing control channels more often.

Interesting read here: https://community.infineon.com/t5/K...nouncement-CSA-in-WICED-KBA229053/ta-p/259344

Seems the channel switch announcement is a pre-emptive notice to allow connected clients to know where to jump without having to go through disassoc, probe, assoc steps which would be a momentary connection drop.

 

[skeal]

Good morning everyone.

I updated my RT-AX86U to Asuswrt Merlin 388.1 last week with no issues.

The only thing is that I have a couple of remote Wireguard clients, that I route through the own router's Wireguard client to my VPN supplier. This works well, but I cannot acces the router's LAN nor the router itself from these remote Wireguard clients, even though I've ticked the 'Access Intranet' button, as shown in the image below.

View attachment 46321

Can someone help me, please?

Edit: I've found that I have to stop Wireguard Session Manager Add-on if I want to connect to my router's LAN over router's GUI Wireguard Server.

Exactly the same issue here. Hoping someone can give us an IP Tables rule to sort this out. Anyone? @RMerlin ?

 

[skeal]

Interesting read here: https://community.infineon.com/t5/K...nouncement-CSA-in-WICED-KBA229053/ta-p/259344

Seems the channel switch announcement is a pre-emptive notice to allow connected clients to know where to jump without having to go through disassoc, probe, assoc steps which would be a momentary connection drop.

This sounds logical or WiFi would be known as terribly unreliable for connection critical things. Like streaming video or live TV.

 

[penguin22]

I assume clients would need to reconnect, unless the Wifi standard supports some method of instructing a client that the channel (and therefore the radio frequency) will change. However Wifi (the RF portion of it) isn't my area of expertise, so I'm not sure. I always used fixed channels with all of my routers.

Usually if the channel needs to change, there will be log entries from the acsd daemon saying so.

I was running 386.7_2 stably with ~3 months of uptime and no issue with client disconnects. Decided to try the 388.1 build beginning with beta 2, this is with a simple network consisting of Verizon FIOS (300/300) connected via Ethernet directly to my main AX86U with a 2.5Gbps hardwired AX86U AI-Mesh node. With beta 2, I did experience "drops" with Samsung mobile clients and also Windows laptops at times. Clients would still be connected, though showing no internet. Upgrading to the stable 388.1 build did not resolve the issue. I first attempted to troubleshoot by moving the mesh node to the most recent stock ASUS firmware, though that didn't appear to have an appreciable effect (or depreciated for that matter). I then did a roll-back of the main router to 386.7_2 several days ago and have not experienced any connection issues since doing so, with either Samsung phones, Windows laptops, or IoT devices.

Being closed source, and having read quietly through this thread, I do believe that this may be something in the specific build provided by ASUS and less likely to do with the changes by RMerlin. Supporting this is that the two devices based on a slightly older build do not appear to have the connection stability issues. It is very difficult to remote troubleshoot, especially when issues are not reported in a consistent manner by individuals. In my case, I haven't been seeing wireless connectivity dropping necessarily, at least not when it occurs, but rather internet not functioning, while wireless is remains connected, which could appear through buffering or other apparent disconnects from whichever service you are connecting to. Eventually, my phone will disconnect from wireless with a note that it would reconnect when service is restored (or something along that line), which if you toggle wireless off and on, would occur immediately.

My reason for responding to this specifc message from RMerlin is that I speculate that the thinking that the reported issues may possibly be related to auto-wireless configurations in the new build, and or the wireless version ASUS included in the closed source build, may be in the right direction. As noted, this seems to be router version specific, with AX86 series seeming to be affected in some cases (my own testing would agree with this), and perhaps dependent on wireless configuration.

In my case, I am running YaziFi with a Guest and IoT network separately, using Skynet and Unbound for recursive DNS provided by the router. I use OpenVPN, which has been stable on both builds, so appears to not be script or VPN related as well.

 

[skeal]

There seems to be a growing consensus the culprit for "MOST" of the recent WiFi disconnects is actually the setting of any Control Channel to Auto
So... Don't.
Meanwhile just pick the last control channel selected, or choose a channel that seems clear (maybe verify with a Wifi App)

But this leads to my point.
I had asked RMerlin about what happens when the router changes channels, Can connected clients migrate to the re-assigned channel?
He didn't think so & seemed to guess they would disconnect momentarily.
I did some research but had problems finding a definitive answer.

To me what needs to become known is...
(When Control Channel=Auto)
How often these routers check if the channel should actually change.

From the reading I've done...
Alot of routers & likely older firmware simply checked during boot-up or initialization.
However, it does seem feasible that with newer Asus firmware...

These routers are changing control channels more often.

In regards to 160Mhz channel bandwidth. Would it not be logical that if we are sharing these extended channels with some critical services (Weather for instance), that changing channels automatically would be a must, for fear of occupying a channel needed for the critical systems around your location? Just me wondering if common sense meets technical specs.

 

[capncybo]

In regards to 160Mhz channel bandwidth. Would it not be logical that if we are sharing these extended channels with some critical services (Weather for instance), that changing channels automatically would be a must, for fear of occupying a channel needed for the critical systems around your location? Just me wondering if common sense meets technical specs.

Certain individuals became somewhat irate when I hinted at 160Mhz being a contributing factor. But in Reality, It was the users of the 160Mhz whom were saying these more recent firmware(s) had broken their previously acceptable 160Mhz higher speed throughput. So honestly... I shy'd away from the fight.
However speaking Logically...
The more congested the airwaves... the more likely a router with (2.4 & 5) Control Channel set = Auto Will try to change to another channel.
So I ask, What contributes to additional Radio waves the most?
Probably...
#1) Wifi Backhaul (so whenever possible... ethernet those nodes & keep your network-packet-control [OFF-AIR])
#2) Using almost all the airwaves yourself via: BIG-F'N-FAT-160MHz-WIDE-BANDWIDTH

The more airwaves used... the higher the chances of radio-interference.

I theorize two possibilities.
The more recent Asus & AsusMerlin Firmware(s) may have increased the frequency (or shortened the time) between SSID Scans &
The more recent Asus & AsusMerlin Firmware(s) may have increased the SENSITIVITY of what is considered Noise or Unacceptable radio-interference.
(And it may even be a combination of Both)

But either-way, if any automated Changing of a Control Channel forces (disconnect/reconnect) with all Clients...
We should probably prevent it from occurring.

At least until Asus can better sort this stuff-out.

 

[capncybo]

@skeal Sorry I just realized (I misunderstood your point)
Yes if using 160Mhz & DSF you will always be booted as required by law.
But with WiFi there are many misconceptions (& I struggle with them also).
Main One = Over Lapping SSID is not actually all that bad.
With electronics & wifi in particular hardly anything happens in real-time...
Things are cued, Even between competing/different SSID.
It's better to play nice & co-operate than just make noise into the neighboring channels.
When selecting a channel...
Yes try for none but, if the main channels are occupied, select the one with 3 different SSID instead of the one with 12 SSID.
Avoid the partial overlapping of adjacent channels (That is the more problematic interference AKA:Noise)

 

[capncybo]

Interesting read here: https://community.infineon.com/t5/K...nouncement-CSA-in-WICED-KBA229053/ta-p/259344

Seems the channel switch announcement is a pre-emptive notice to allow connected clients to know where to jump without having to go through disassoc, probe, assoc steps which would be a momentary connection drop.

Whooah Cool Stuff thanks... Perhaps this functionality is actually what got messed up via the more recent GPL?
I just wish I had seen it before my recent outbursts above... LOL
But it would be nice to know to what extent Asus is utilizing this technology

EDIT: After a closer read... it seems this "Channel-Switch-Announcement" may only pertain to the DFS Channels...
Yet, I would have expected a similar type of mechanism implemented for the regular channels.
Hmmmm,
So I'm back to... When or How often does the router actually check for Unacceptable noise before performing a control channel change
Perhaps it's actually more of a threshold value..
Ex) Maximum failed packets received/delivered

Darn Black-Boxes

 

[RMerlin]

Okay, that's a fair explanation, and make sense. Maybe something to the ideabank in the future for ASUS.

The AiMesh section will show you node clients.

 

[wbennett77]

FYI, for anyone that was having issues with DoT and ControlD, it looks like they have fixed the issue and all is well again according to my testing.

Would you mind sharing your dot settings. Thanks!

 

[bluzfanmr1]

Would you mind sharing your dot settings. Thanks!

 

[dbell]

The AiMesh section will show you node clients.

It does but not with any of the channel / connection characteristics that you can get in the wireless log info at the router. Getting that aggregated across all mesh participants would be nice.

 

[visortgw]

It does but not with any of the channel / connection characteristics that you can get in the wireless log info at the router. Getting that aggregated across all mesh participants would be nice.

That is available via NVRAM (ssh into AiMesh node) if needed. You can also potentially see channel as well as other characteristics via System Log, Wireless Log tab in main router GUI.

 

[dbell]

That is available via NVRAM (ssh into AiMesh node) if needed. You can also potentially see channel as well as other characteristics via System Log, Wireless Log tab in main router GUI.

Wireless log shows only devices connected to the ROUTER. We are talking about all wireless devices connected to router AND any of the mesh NODES as well in a single UI.

 

[jeton7608]

Today, while I was watching France-Morocco I checked the link speed of my S22 Ultra and it was 1.1Gbps, on my couch 8-10 meters away from my GT AX11000 router. Last week it was 1.8Gbps. A big slowdown, again.

I didn't update anything on my 5G1 network (AX Only) so I decided to check 5G2. Then, I remembered I updated the control channel to Auto. So I picked channel 153 on 5G2 network and voilá! Problem solved and back to 1.8Gbps... On 5G1 and without touching anything on that network.

So, as I said before, I don't recommend using Auto in Control Channel in AX11000. Always specify the best possible channel when you use 160Mhz.

 

[Smokey613]

I reloaded 388.1, did a reset, reconfigured everything manually and set manual wifi channels. So far, everything has been working great for last 18 hours.

Well, I had to rollback to 386.5_2 due to wifi issues again. No idea the cause but I am just staying put for now.

I really wish eero would allow manual updating of their firmware.

It may be time to look into another solution but I really enjoy the ease of the Asus management interface and addon scripts.

 

[tyspeed42]

Ok, so have a few things, hope these are not absolute irrelevant questions but here goes:

Does anyone know of a way to modify my cert config to use a set of ip address instead of the host name given by PIA? Like a Round Robbin. I have found that some PIA servers when it changes them when using the host adddress i get TLS errors. So Ive made a list of the good ip's that are not causing connection errors, i added them to the config as such : remote 191.96.106.80 1198 instead of listing just the hostname address I have listed 5 ip's.

Sorry if this is out of the questions for this firmware.

Also VPN Director isn't allowing my rules to allow ip's through the wan instead of the VPN. I just started noticing this when my vpn went down and my connection was still live although I have that set it kill the connection if VPN goes down. If I need to change the setting. This is how I have it set up.

John9527 help me set all this up a while ago on my ac routers , so if so if something i need to change for the vpn director to function and allow those ip's under rules to be allowed through the wan, then my vpn once down all connections blocked. I do have this checked (Killswitch - Block routed clients if tunnel goes down) and (Redirect Internet traffic through tunnel) set to policy rules: These are my rules below.

Router 192.168.1.1 WAN
Enabled VP-Server 10. . . 0/24 WAN
Enabled AppleTV bedroom 192.168.1.191 WAN
Enabled Apple TV 2 4K livingroom 192.169.1.72 WAN
Enabled Home-Lan 192.168.1.0/24 OVPN1

Thanks

 

[gxcare]

Just to share my experience regarding WiFi issues on this release, in my case (single RT-AX86U, no mesh) everything works perfectly as long as I don't enable the 160 MHz for the 5 GHz band. In this case after some time (hours) my phone (Samsung S21) reports to be connected to the WiFi but Internet access is not available. If I force the WiFi reconnection on the phone everything works again. I have tested with all the combinations of DFS and fixed/auto channels but the result is the same. I haven't tested the 160 MHz with other firmware versions.

 

[skeal]

In regards to 160Mhz channel bandwidth. Would it not be logical that if we are sharing these extended channels with some critical services (Weather for instance), that changing channels automatically would be a must, for fear of occupying a channel needed for the critical systems around your location? Just me wondering if common sense meets technical specs.

@skeal Sorry I just realized (I misunderstood your point)
Yes if using 160Mhz & DSF you will always be booted as required by law.
But with WiFi there are many misconceptions (& I struggle with them also).
Main One = Over Lapping SSID is not actually all that bad.
With electronics & wifi in particular hardly anything happens in real-time...
Things are cued, Even between competing/different SSID.
It's better to play nice & co-operate than just make noise into the neighboring channels.
When selecting a channel...
Yes try for none but, if the main channels are occupied, select the one with 3 different SSID instead of the one with 12 SSID.
Avoid the partial overlapping of adjacent channels (That is the more problematic interference AKA:Noise)

So I see this in my log today.

Dec 15 06:53:30 RT-AX88U-E770 wlceventd: wlceventd_proc_event(632): eth7: Radar detected

I've never seen it before, (I was using 160Mhz with auto channel selection enabled and DFS). This is proof that my post above is correct. I did notice my Cell Phone a 160Mhz device didn't lose connection when this happened, but every other 5G device connected to the router did. My wireless log shows the same devices connected, however now at 80Mhz and on a non-DFS channel. Something is messed up with the auto changing of channels, when a weather radar is in range, (while using 160Mhz and DFS). So I can verify strangeness when using this sort of setup. In my case the weather station is about 10 miles south of me. I found that if I reboot the router the channel bandwidth goes back to 160Mhz with DFS, but this will very likely happen again. I will for the sake of sanity change to 80Mhz with auto channel and DFS enabled and see how that goes. I want to verify if auto channel on my AX88U is not advisable. I changed to a static channel, the reason is that even with DFS enabled, auto channel selected the same old channel it always has for months now (channel 44) so I disabled DFS as well. Like @RMerlin said, he uses a static channel himself. I am now back to where I was when I loaded this 388.1. If it works don't fix/break it.