The client is ultimately in charge of roaming. You can influence roaming, it is hard to control it.
There are plenty of simple setups with 2.4ghz and 5ghz using the same SSID. As the setup gets more complicated and there are more access points the details matter more. If your clients are connected or trying to connect to two different APs simultaneously that will make internet very choppy. My faster clients operate on a 5ghz only SSID- it significantly simplifies things for roaming and allows for optimization of access point placement. The 2.4ghz range is different (farther reach for the same signal level) from 5ghz range. With three access points I would consider using a unique SSID for 5ghz and for 2.4ghz. Instead of 6 possible places to connect, clients will only have 3 (this is a good thing).
@auanasgheps You may already be aware of this, but the more channel width you use, the more any co-channel interference will wreak havoc on performance. Using 160mhz sounds great in practice and can surely allow for much higher bandwidth. But the chance for collision with neighboring APs using the same channels is greatly increased for each increase you make in channel width.
With 5ghz, there is a natural, yet unfortunate, tradeoff between bandwidth and latency at this point in time. If you decide 160mhz is a must, then any other AP within "hearing distance" of your AP that is using one of your channels within the 160mhz range is going to cause the APs to play a game of "I was talking first, you have to wait." By decreasing your channel width to 80mhz, you reduce the amount of collision potential by half.
Putting this rather bluntly (hopefully no one is offended), if one insists upon using 160mhz in a congested wireless environment, there should be no basis to complain about bufferbloat tests that are less than A/A+. It's a fact one must accept that occasional, if not frequent, B/C scores are likely going to be a reality with 160mhz.
Ehhh... I hear you there to a degree, but odds are if one is using 160mhz wide channels, they're also using DFS (or at least half DFS). Even in a crowded wifi environment, I'd wager 95% of the AP's are operating in UNII-1 (36-48) or UNII-3 (149-161)... meaning DFS is largely wide open. In a mixed client environment, setting 160mhz width to be a mix of UNII-1 and UNII-2a (36-48 and 52-64) would allow non-DFS compatible devices to connect through the lower channels, and 160mhz compatible to connect to the full width. Simply meaning... he'd have no more collision than if he was on 80mhz only and connecting to the same channels.
If he goes all channels within DFS, yes that introduces other possible frustrations unrelated to what we're discussing (radar), but it lowers even still the chance for collision you're describing.
Fair points! I suppose I was short-sighted to not inquire more about @auanasgheps's environment first.
@auanasgheps What does your wireless config look like with your 160mhz configuration? Is your 5ghz channel set to 'auto' or are you selecting a channel?
Also, are you within range (<=10 miles or so) of a weather radar? What about neighboring APs?
I live in a building with many homes. The 2.4ghz spectrum is a hot mess and I use it only for IoT devices. The 5ghz one is doing better: only 36-64 channels have some APs. the 100s channels are mostly free, that's why I want to focus on 160mhz!
I've set it to auto, but always picks a 100s channel.
config wifi-device 'radio1'
option type 'mac80211'
option path 'platform/soc/18000000.wifi+1'
option channel 'auto'
option band '5g'
option htmode 'HE160'
option cell_density '0'
option country 'IT'
option itxbfen '1'
lol I have no idea at all. I live in a big city and the closest airport is 9km / 6miles away (air distance). I've tested this router only briefly so I don't know I have radars around
@SiXX There seems to be something that is occurring on a regular interval that disrupts wireless integrity for a few seconds which results in a lot of packet loss and, therefore, latency spikes:
Apparently my original test was foiled by a misbehaving MacBook. Rebooted my MacBook and re-ran the tests. Things look a lot happier, although some sizable latency spikes in the above tests.
I wouldnât assume radar, only because radar would cause DFS to drop altogether⌠and often not return for 60sec or more. Do you have a windows / Linux based device you can test on just to rule out Apple oddities?
Running with WED disabled here, AQL low/high threshold of 1500. I switched to 160mhz auto (AP settled on channel 100, FWIW) and ran this bufferbloat test (though I generally prefer to run Crusader and/or Flent locally to rule out ISP latency) via WiFi:
If you check my latest comment in the other discussion, I re-ran all the test with the latest pesa1234 build and the results are excellent for me, WED disabled and no SQM to use all the sweet bandwith I have! (your results are better for sure with SQM enabled)
I don't have 160mhz Apple products, but I see the same behaviour with 80mhz: non-Apple devices are faster at least in my tests.
Just wanting to be perfectly clear with the results from my testing, my MT6000s are just "dumb APs" and I have SQM, hfo/sfo, and firewall all disabled. I do, however, run SQM on my main router/firewall (another OpenWrt device altogether), so that does come into play with any Waveform tests I post. But for the Crusader results I post, there is no SQM between my test device and my router box that is the Crusader server.
Just now I tried to upgrade to latest snapshot 7990ee3476d0. However, after the router finished upgrade and restart, it become unresponsive. Ping to LAN works, but I cannot access luci or even ssh. Anyone also experience the same with latest snapshot?
Now I'm in limbo as I have older snapshot sysupgrade backup, but I need to install mwan3 which requires latest kernel (6.6.32)
Yep same here snapshot r26556 no bueno! Had to revert. You might be able to grab a prebuilt image from the firmware selector - it's still showing r26536 then do some vi trickery to get the WAN working and upgrade / restore backup from there ....
EDIT - I kind of go through my workarounds using a default image in prior posts if you check my history.
I faced similar issue with r26556-17d8c5825e built using Image Builder for both GL-MT6000 (Flint 2) and GL-MT3000 (Beryl AX). Checking nmap showed only port 21 (ftp) open on both the devices. No ports 22 (dropbear: ssh) or 80 (luci: http) or 443 (luci: https) on any of them. However DHCP Server (odhcpd) seemed to be working.
I reverted back to an earlier build (r26488-4454361e54) following the debrick-using-uboot instructions at https://docs.gl-inet.com/router/en/4/faq/debrick/ (first I had to flash GL.iNet build and then afterwards flash vanilla OpenWrt).
The GL-MT6000 (Flint 2) files are at
MAIN SNAPSHOT r26556-17d8c5825e (newer, not working)
[FILES DELETED]
MAIN SNAPSHOT r26488-4454361e54 (older, working)
[FILES DELETED]
My windows/linux PC shows better 160mhz behavior than my Apple products. Thatâs why I mentioned it.