Enabling roaming / 802.11r functionality

Software SW bugs discussion
1

Hi,

I just tried to setup 802.11r on my Omnia using luci’s gui:

grafik
grafik1154×827 42.8 KB

Background information I got from thread1 and thread2 and I tested my core devices (Apple and Samsung) successfully in a similar surrounding with 3 floors each having a OpenWRT 18.06.2 running router/ap with enabled 802.11r.
Comparing the options of the TO (above) to those of my ap (linksys WRT1900AC, wpad (full) installed, below) shows the options of TO are lacking functionality:
grafik
grafik928×860 23.8 KB

The above shown marked options would leave the following additional wireless configuration lines for the chosen ssid on my TO:

	option ieee80211r '1'
	option ieee80211w '0'

but unfortunatelly after restarting the network this radio device would never come up again (rebooting doesn’t help, it’s all the same for the 2,4GHz- and the 5GHz-wifi-cards)…
At my ap there’s more information stored to the ssid:

	option ieee80211r '1'
	option ft_over_ds '1'
	option ft_psk_generate_local '1'

and… the radio devices will come up without any problem.

So my question is: Do you other guys also have the same problem with 802.11r on your TO?
The only modification I did to my TO was swapping the small 2,4GHz-card for a WLE1216V5-20 [mPCIe-slot 0; running on 5GHz] and configuring the WLE900VX [mPCIe-slot 1] to run on 2,4GHz.

But I believe this problem to not be related to my hardware but to the outdated wpad package: my linksys WRT1900AC runs wpad 2018-05-21-62566bc2-5 whereas the TO has only version 2016-12-19-8 available. :sleeping:

ps: I did this because of the problem that several devices keep beeing connected to the TO as if clued to its ssids (whereas the same devices do a perfect job in the abovementioned surrounding). It’s really annoying :frowning:
Unfortunatelly I was forced to have only ca. 2,5 meters in between the TO’s and the ap’s antennas in the core of my rented flat. So in this core area roaming is a problem - just contrary to the edge regions of my flat, where there is only one (TO or ap) wifi reachable…

2

Hi,

As I posted elsewhere - most of consumer devices don’t support 802.11r so there’s big chance it won’t help you even if you’ll worked it out. In similar (Czech) thread recently - Druhý router jako extender - was multiple workarounds suggested and OP successfully tried to set the same channels on both APs (together with same channel width and other radio settings) which worked for him but I would avoid such practice if there’s other solution.

3

My understanding is that you do have roaming even in the base standard and the point of 802.11r is only to make it faster (decrease the number of messages). Therefore my estimate is that if your devices didn’t roam before, 802.11r won’t help. I can’t say I really understand these things though :slight_smile:

4

802.11r would be only useful if the router is a device in motion, e.g. travel router, and it would help the device in motion with faster authentication between different AP (roaming) that belong to the same domain.

Thus, it does not improve anything for the router’s WLAN clients.

5

I precised the information in the op.
To summarise: my core devices are able to take advantage out of 802.11r functionality.

So please let us get back to the question if this is a bug or if some other users are able to use 802.11r on the TO 3.x platform.

1 Like
6

@cynerd /@paja: Could you please verify if activation of 802.11r-functionality was working for you (and if not if this is related to outdated wpad-version, please see op for details).

7

I was able to get it running. I had even presentation about it. If you want, you can read my slides: https://git.cynerd.cz/presentations/plain/2018-csnog/pres.pdf

I just want to give you a hint that running 802.11r might not be a good idea. There is still up to my knowledge not fixed vulnerability: https://hashcat.net/forum/thread-7717.html
This allows attacked to get access to network when roaming occurs and when he manages to crack sha1 sum, which is possible to do. This is fixed with wpa3 in form of different (bigger) hash being used. Unless you are planning to run wpa3 only network you are probably being affected by this.

3 Likes
8

Thank you for your slides and the advice. If I really need to deactivate 802.11r I for now have to deactivate WIFI on the TO and later on reorganize my network installation completely due to the fact that the “normal” roaming simply does not work fluently with the TO. The clients keep being glued to the TO instead of roaming to the ap, when accessible. The other way around is working. This is no offence to the TO - it might be completely due to my flat’s architecture… :frowning:
I only read about KRACK indepth - and that should be worked around for now (waiting for wpa3 to close it for good). What I’m curious about:

  1. Was this presentation intended for deployment on TO? Reading the slides I came to the conclusion you were holding back with the recommendation to deploy it? If yes, is it because of the mentioned vulnerability (cannot tell if your presentation is from 12th of June or 6th of December, 2018)?
  2. Unfortunately they do not list a CVE# inside this thread - do you know why? As 802.11r is heavily used in corporate enviroments fixes also for WPA2 would be needed urgently… edit: It seems WPA2 Enterprise is not vulnerable, so this doesn’t seem to be a real big issue. But if you use the only current way around this mess by working with strong passwords (alphanumeric + special signs) in place, WPA2 personell should also be not easily attackable, right?

But related to that there is a WPA Key Reinstallation Attack workaround implemented with LEDE 17.01.4 which was not yet propagated to the TO fork. I don’t know if this is related to the outdated wpad/hostapd packages, but maybe you could have a look at this, it could increase security. Also it doesn’t help against your mentioned vulnerability…

9

Yes clients do that. That was a reason why I was sceptical about usage. The clients won’t roam unless they scan for new APs and they do that only if signal level is under some threshold. This threshold is on most devices set to levels that pretty much is same as “barely connected”. This means that device won’t scan for new AP until old AP is almost not accessible. That prevents it from roaming. You can change these limits (at leas on Linux you can) but that introduces windows of poor performance because wifi is retuned to various frequencies to do scan and that greatly decreases throughput. You can see that situation on my slides on graphs right before clients roams (in both before and around tenth second). Comparing it to roam improvement between APs it is more significant. The interesting measurement is under resolution of what I was able to get from iperf but where without 802.11r roam took around 200ms with it enabled it took not much less than 100ms. Comparing it to 2-3s of poor performance accounting for every scan it is clear that 802.11r on its own is not that beneficial.

The industrial solution is to disconnect client from AP by central controller which forces user to roam to different AP, well up to my limited knowledge. Probably better and cleaner solution is 802.11v which should allow network to inform clients about possible APs without need for periodic scans. Unfortunately I had no time to play with that yet. I also suspect that support of that standard is going to be even worse than 802.11r.

Yes and it was 12th of June so just about a month before that vulnerability if I remember correctly. Any additional tests were delayed afterwards.

I haven’t found one. I suspect that it was evaluated as either impractical form of attack or as a variant of brute-force attack on full EAPOL handshake. Up to my knowledge the fix is not possible. All clients not supporting wpa3 are hashing PMKID field with sha1.

You want long password with high randomness. It does not matter if you use special signs or not. The important point is high randomness and length.

2 Likes