Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

WiFi 6E / 6GHz WiFi #2906

Open
mkg20001 opened this issue May 21, 2023 · 7 comments
Open

WiFi 6E / 6GHz WiFi #2906

mkg20001 opened this issue May 21, 2023 · 7 comments

Comments

@mkg20001
Copy link
Member

6 GHz WiFi is a thing apparently

Are there plans to support it? Does OpenWRT support it yet?

@blocktrron
Copy link
Member

OpenWrt currently does not support configuring the 6GHz band.

I'm also not aware of any 6GHz hardware by OpenWrt (yet). If you know any, please let me know ;)

@s-2
Copy link
Contributor

s-2 commented Jun 28, 2023

I remember sometime around summer of last year, I put an MT7921 PCIE card into an OpenWrt device and built an image containing the latest master of mt76 . I could see the 6GHz channels printed in iw list, and using iw reg set would enable a few more available in the European regulatory domain.
Unfortunately, UCI only supported 2g, 5g and 60g bands so there was not much I could test, looking at the CLI of hostapd scared me from digging any further back then... So it was kind of a bootstrapping problem: I don't know if iw scan would have found any AP on the 6GHz band (though I guess it should have), since I needed to create one first.

Adding support for 6g in UCI would probably require digging way too deep for my current state of knowledge, but should there be any progress on this please let me know, I am willing to test 🙂

Besides, I've been using the same card in my ubuntu 22 LTS based machine for a year now, with the old mt76 driver from that repo at least Bluetooth, 2.4G and 5G are working flawlessly, no 6G channels in iw output though. Not sure if it's worth building a kernel with current mt76, as the network manager etc. would probably need to support the band as well.

@skorpy2009
Copy link
Member

Now @blocktrron only needs to merge openwrt/openwrt#12941

@blocktrron
Copy link
Member

Predator W6 is merged in OpenWrt master and i plan on backporting the device to 23.05.

I've tried consolidating my thoughts on the next steps in https://md.darmstadt.ccc.de/gluon-6e?both - Feel free to add or comment points there.

@s-2
Copy link
Contributor

s-2 commented Aug 6, 2023

I've tried consolidating my thoughts on the next steps in https://md.darmstadt.ccc.de/gluon-6e?both

Thanks for the input, I was not aware of the additional FILS and OWE requirements.
(btw, it should probably read "usage of SAE and/or OWE" there?)

Assuming there wouldn't be compatibility issues with older devices on 6 GHz, since a new band also involves using state-of-the art client devices anyways, at least we won't be locking out older devices when deploying OWE / SAE on 6 GHz, however transition mode looks worrying;

If I understand correctly, we can't just keep operating 2.4 and 5 GHz bands unencrypted (public SSID) and with WPA2/3 (private SSID) and only use OWE (public/mesh) and SAE (private) on 6 GHz, without any transitional mode enabled, since there would be no roaming of 6 GHz-enabled devices to/from the other bands?

Regarding MAC address, how are tri-band (2.4 + 5 + 5) devices currently handled? (Or does it just affect those with 6G?)

@Djfe
Copy link
Contributor

Djfe commented Aug 10, 2023

how are tri-band (2.4 + 5 + 5) devices currently handled?

Gluon does not support tri-band devices, yet. #1661
It will choose the first 5GHz phy and ignore the second, so no MAC reserved for that one (unless you set some stuff manually, probably?)
tri-band can be troubling anyways: some devices split the 5GHz range between 2 phys, which Gluon needs to handle

for example: Linksys MR8300
ipq4019 handles channels 36-64, qca9888 handles channels 100+

@Djfe
Copy link
Contributor

Djfe commented Aug 10, 2023

Nice sheet from blocktrron!
I'm going to leave some thoughts here (man this turned out to be quite some wall of text 😯)

Specs for reference:
Enhanced Open certification (read chapter 2, it's pretty short)
OWE


(btw, it should probably read "usage of SAE and/or OWE" there?)

actually FILS is a thing: Fast Initial Link Setup
https://blogs.arubanetworks.com/solutions/wi-fi-6e-how-ap-discovery-works-in-6ghz/

Man I actually love how 6GHz is this new kind of playground where they were able to set/establish some ground rules.
Away with the legacy stuff right from the start. This should make 6GHz the best kind of wifi, yet. All clients will support all features (OFDMA, bss coloring etc. pp.)


At least Apple now appears to support OWE since this year, even if it wasn't mentioned in any changelog of iOS 16
https://support.apple.com/de-de/guide/deployment/dep3b0448c58/web
Yep, unfortunately limited to the "new" devices (2020+). iPhone 12 (current gen: iPhone 14)

That makes OWE more feasible


Private WiFi only supports SAE (maybe not even mixed?)

how is that a challenge? just offer 2.4GHz and 5GHz as mixed modes (or wpa2) under different MACs like usual.
all actual 6GHz devices have to support WPA3 anyways

oh wait, I actually remember experiencing this issue once already with my new phone:
it doesn't let you connect to wpa2 anymore unless you remove and add the network again.

still no challenge: enforce different private SSIDs for 2.4/5GHz and 6GHz and explain in config mode why it's necessary. Users like to choose frequency bands anyways ^^ (and it appears to be the optimal choice for as long as most devices won't support WPA3, yet)

yes, this prevents roaming between 2.4/5GHz and 6GHz (one draw back for better overall security in the 6GHz range, "das Committee hat da wohl in den sauren Apfel gebissen")

actually an interesting read on roaming and wpa3 :/ (wpa3 doesn't support 802.11r, and Apple afaik doesn't support Opportunistic Key caching)
https://www.wirelessnewbies.com/post/roaming-in-wireless


Mesh is uncertain. Do we require encryption using SAE there too?

my opinion: make WPA3 default, so it's always included for 6E devices in Gluon.
6GHz is actually nice as an uplink (no DFS, so far no cellular providers, barely any users, larger channel widths are feasible)
Some mesh networks could limit themselves by doing mesh only over 6GHz (works in isolated buildings when meshing with the outside is not necessary anyways)
2.4GHz and 5GHz usually provide enough bandwidth for most clients (especially when meshing is limited to 6GHz) and are universally available
This also avoids enforcing OWE for those bands. (since 6GHz does no client network then)

In-case we need meshing on 2.4/5GHz (the default): Don't enforce SAE on 2.4/5GHz.
parallel: unencrypted mesh on 2.4/5GHz and SAE on 6GHz
I don't see any drawbacks to this approach (if necessary: give the 6GHz mesh a slightly different SSID?)

Because the existing 15 billion Wi-Fi clients will never be able to connect to 6 GHz, it appears likely that different levels of security will be used on the different frequency bands in the enterprise. WPA3 will indeed be used in 6 GHz. Yet, despite the support for WPA3 transition modes in the legacy bands, WPA2 will likely remain prevalent in the 2.4 GHz and 5 GHz bands for a very long time.
https://www.extremenetworks.com/resources/blogs/wireless-security-in-a-6-ghz-wi-fi-6e-world


OWE Transition needs to be verified

well, yes :)
OWE Transition Mode still works on 6GHz, right? We just have to announce the OWE network via the 2.4/5GHz beacons, afaik?
But that definitely needs to be verified.
If the site doesn't add support for OWE, then 6GHz should only be available for meshing and private network(s).

If there were only OWE on one band, then the client probably would never associate again with the other 2.4/5GHz bands again (either just for the same node or for all Freifunk nodes (I haven't worked with OWE, yet. I could be very wrong here, does anyone know more? If a site were to deploy OWE transition: is it possible to return and disable OWE again or will devices refuse to connect by themselves until users delete and readd the wifi network?))


Parallel is not a challenge --> Simply broadcast SSID unhidden

Possible, but Aachen would never deploy that. Most people connected to Freifunk won't look into their phones again to choose a different SSID (especially if they have a working connection). Also the device might still prefer the unencrypted over the encrypted connection for whatever reason (it saw the beacon first); they are separate SSIDs in this mode (parallel) as far as I understand it. I would still prefer a German-wide "Freifunk"-SSID so people on vacation get to profit instantly from having joined a Freifunk just once


We currently don't know if we should hide the SSID of the transition network.

yes, you should (I think)
everywhere I read so far, it said: the OWE network stays hidden (in Transition mode).

Enhanced Open Transition - This mode provides backward compatibility with the bulk of clients that do not support OWE by using two SSIDs. When an open SSID is configured on an Enhanced Open certified AP, a second hidden SSID is automatically created that uses OWE. The legacy clients connect to the open SSID with no encryption. However, within the open SSID beacon frame is an OWE information element that directs Enhanced Open clients to the hidden SSID that uses OWE. The OWE SSID is hidden to avoid confusion for the drivers of the legacy clients.
https://www.extremenetworks.com/resources/blogs/wireless-security-in-a-6-ghz-wi-fi-6e-world

the certification spec says:

2.2.1.5
Beacon frames from the OWE BSS shall have a zero length SSID and the RSNE shall indicate support for OWE
[2]

Does zero length mean it's a hidden network or is this something else?

side-note:
I just read about Freifunk Karlsruhe's tests in 2020. They actually experienced issues on some devices with transition mode enabled (despite the SSID being hidden and only announced via beacons) and therefore refrained from using it at first.
https://karlsruhe.freifunk.net/news/2020/04/05/WPA3/
But this year they finally switched over to transition mode probably due to less incompatible devices being around nowadays
https://karlsruhe.freifunk.net/news/2023/02/01/gro%C3%9Fes-firmware-update/

Good choice imho: ~80% of Android devices are on Android 10 or newer by now and can connect via OWE
https://de.statista.com/statistik/daten/studie/180113/umfrage/anteil-der-verschiedenen-android-versionen-auf-geraeten-mit-android-os/


Discoverability using RNR as a requirement?

If this get's implemented for 5GHz: how do we handle random dfs channels for outdoor devices? (channels 100+)

  • Do nodes need to know which other channels are used nearby in order to advertise them?
  • Or is it not that important and devices might discover them eventually?
  • Outdoor devices might announce their own 5GHz channel over RNR over 2.4GHz Beacons (unless it's 5GHz only)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants