WiFi 160MHz

[Shino]

You need to check if it is radar detection causing it for you or the same bug as being discussed. If radar detection, it is normal and there are scripts available in the forums to have it retry 160 every so often. But that can result in downtime each time it does it.

In reality, for many users 160 just isn't practical since so much will cause it to fail back to 80. Considering you can get close to a gig on 80mhz AX and 160 has shorter range, do you actually need 160 and the headache that comes with it?

The 5G frequency band always works on channel 52, so there should be no influence of DFS.

Since I want to access LAN devices at more than 1Gbps, 160mhz is the only option.

 

[ColinTaylor]

The 5G frequency band always works on channel 52, so there should be no influence of DFS.

Channel 52 is the beginning of the DFS range. Using 160MHz bandwidth would span channels 36 to 64, 50% of which are DFS (assuming you're in the USA).

 

[Shino]

Channel 52 is the beginning of the DFS range. Using 160MHz bandwidth would span channels 36 to 64, 50% of which are DFS (assuming you're in the USA).

I know. When I restart the router, AX86U will work at 160mhz on channel 52 until it drops to 80mhz after connecting a WiFi5 device, and then it will not switch back to 160mhz.

 

[ColinTaylor]

I know. When I restart the router, AX86U will work at 160mhz on channel 52 until it drops to 80mhz after connecting a WiFi5 device, and then it will not switch back to 160mhz.

Have you tried channels 100 to 128?

 

[Shino]

Have you tried channels 100 to 128?

Due to regional restrictions, channel 36 is the only 160MHz channel available.

 

[bbunge]

I have my 5 GHz set to channel 36 at 20, 40, 80,160 MHz and it and the mesh node have been at 160 MHz for a couple of weeks. I do have several WIFI 5 clients that connect at 160MHz but most of the clients connect at 80MHz.

 

[drinkingbird]

I have my 5 GHz set to channel 36 at 20, 40, 80,160 MHz and it and the mesh node have been at 160 MHz for a couple of weeks. I do have several WIFI 5 clients that connect at 160MHz but most of the clients connect at 80MHz.

I'm assuming you mean Wifi 6 clients?

 

[drinkingbird]

The 5G frequency band always works on channel 52, so there should be no influence of DFS.

Since I want to access LAN devices at more than 1Gbps, 160mhz is the only option.

Not sure what you mean, there can very easily be influence of DFS if you are using DFS channels (whether control or extension). With 160 DFS is always a potential factor.

If the logs show it is not radar causing it to fail back to 80 then you can attempt to hardcode your router to 160 and see if it stays, or go back to an older firmware which seems to have worked for others.

 

[Shino]

Not sure what you mean, there can very easily be influence of DFS if you are using DFS channels (whether control or extension). With 160 DFS is always a potential factor.

If the logs show it is not radar causing it to fail back to 80 then you can attempt to hardcode your router to 160 and see if it stays, or go back to an older firmware which seems to have worked for others.

I said I've tried various settings, no matter specifying 160mhz or channel 36, it won't stay at 160mhz.

 

[drinkingbird]

I said I've tried various settings, no matter specifying 160mhz or channel 36, it won't stay at 160mhz.

View attachment 51748

What do your logs say - is there anything in there about radar or DFS?

If not, and hardcoding to 160 still drops back, then apparently it is a bug and you need to drop back to an older firmware if you really need 160. Just bear in mind 160 is difficult to maintain regardless.

There is a "channelhog" script that is meant to bump it back to 160 after a radar event causes it to drop to 80, you could try that too.

 

[Shino]

What do your logs say - is there anything in there about radar or DFS?

If not, and hardcoding to 160 still drops back, then apparently it is a bug and you need to drop back to an older firmware if you really need 160. Just bear in mind 160 is difficult to maintain regardless.

There is a "channelhog" script that is meant to bump it back to 160 after a radar event causes it to drop to 80, you could try that too.

I searched the logs and there is nothing related to radar or dfs, only this

acsd: eth7: NONACSD channel switching to channel spec: 0xe13a (56/80)

 

[drinkingbird]

I searched the logs and there is nothing related to radar or dfs, only this

acsd: eth7: NONACSD channel switching to channel spec: 0xe13a (56/80)

That's the router changing either channel or width due to co-channel interference. Like I said, it is difficult to maintain 160mhz, even if you don't have DFS in your area. Theoretically if you have 160 hardcoded the only thing that should drop it to 80 is DFS, but I guess if the interference is bad enough, it drops it anyway.

If you were on 56/160 before that log, then it adjusted the bandwidth but kept the same channel, due to interference.

You can try hardcoding a few different channels, the only two 160mhz channels are 36-64 and 100-128 (depending on region you may have 1 or both). There is technically a 3rd one but most stuff doesn't support it.

If both have that issue, you may just have to accept that in your area 160mhz isn't an option, or try an older firmware as mentioned earlier in this post.

You can try changing the control channel to one in the non-DFS range (36-48) and see if that helps but in reality it is the whole range of channels that matters for the most part.

 

[Shino]

That's the router changing either channel or width due to co-channel interference. Like I said, it is difficult to maintain 160mhz, even if you don't have DFS in your area. Theoretically if you have 160 hardcoded the only thing that should drop it to 80 is DFS, but I guess if the interference is bad enough, it drops it anyway.

If you were on 56/160 before that log, then it adjusted the bandwidth but kept the same channel, due to interference.

You can try hardcoding a few different channels, the only two 160mhz channels are 36-64 and 100-128 (depending on region you may have 1 or both). There is technically a 3rd one but most stuff doesn't support it.

If both have that issue, you may just have to accept that in your area 160mhz isn't an option, or try an older firmware as mentioned earlier in this post.

You can try changing the control channel to one in the non-DFS range (36-48) and see if that helps but in reality it is the whole range of channels that matters for the most part.

I specified the channel, similar to the previous case, and dropped to 80mhz after a short time. According to the results of the Site Survey, the signals occupying channels 36-64 are not strong. I tend to think that the problem lies in the AX86U itself, firmware or hardware. I can see that many similar posts have content about this model.

 

[drinkingbird]

I specified the channel, similar to the previous case, and dropped to 80mhz after a short time. According to the results of the Site Survey, the signals occupying channels 36-64 are not strong. I tend to think that the problem lies in the AX86U itself, firmware or hardware. I can see that many similar posts have content about this model.

Site survey won't show you interference from other sources. It is possible that it is a bug since others earlier in the thread found that older firmware seemed to lock at 160 better.

Looks like your two options are to try the channelhog script or downgrade to and older firmware. Or upgrade to 6e or 7 to get 6ghz.

 

[Shino]

Site survey won't show you interference from other sources. It is possible that it is a bug since others earlier in the thread found that older firmware seemed to lock at 160 better.

Looks like your two options are to try the channelhog script or downgrade to and older firmware. Or upgrade to 6e or 7 to get 6ghz.

Frustratingly, 6GHz isn't possible for the foreseeable time due to regional restrictions.

 

[Shino]

I updated the firmware to original 388.23285 and the problem persists. After downgrading to 386.5_2, it can indeed stay at 160mhz for a longer time. Is this a design or a bug? @RMerlin

 

[bbunge]

I'm assuming you mean Wifi 6 clients?

No, I do have a couple of WIFI 5 clients (Acer Chromebook and a desktop with an Intel AC9260) that connect at 160 MHz. Also have a couple of WIFI 6 Thinkbooks.

 

[Shino]

No, I do have a couple of WIFI 5 clients (Acer Chromebook and a desktop with an Intel AC9260) that connect at 160 MHz. Also have a couple of WIFI 6 Thinkbooks.

I am more confused about how you make WiFi 5 devices work at 160mhz, although WiFi 5 Wave2 supports 160mhz, it seems that AX86U does not support this protocol.

 

[ColinTaylor]

I am more confused about how you make WiFi 5 devices work at 160mhz, although WiFi 5 Wave2 supports 160mhz, it seems that AX86U does not support this protocol.

The RT-AX86U supports "WiFi 5 (802.11ac) (1024QAM) : up to 4333 Mbps" so it must be using 160MHz for that as it's a 4 stream router.

 

[Shino]

The RT-AX86U supports "WiFi 5 (802.11ac) (1024QAM) : up to 4333 Mbps" so it must be using 160MHz for that as it's a 4 stream router.

You are right, but such devices are rare, and even in the early days of WiFi 6 there are still many devices that do not support 160mhz.

I updated the firmware to original 388.23285 and the problem persists. After downgrading to 386.5_2, it can indeed stay at 160mhz for a longer time. Is this a design or a bug? @RMerlin

Since the downgrade, the AX86U has been working at 160mhz, which proves that the problem is firmware related. @RMerlin