Wifi client deauthenticated from RPi 3B as 802.1x AP; reason=IE_DIFFERENT

I have a FreeRADIUS Server that I connect to from an AP in one part of my house and that works very well. And when I try to connect the Raspberry pi running OpenWRT 19.07.7 (with packages: hostapd-openssl), the connection from the RPI to the FreeRADIUS server works. Of course the RPi has its own client entry in the clients.conf of the FreeRADIUS server. It is however impossible for wifi clients to get authenticated on the RPI Wifi AP. I tried an up-to-date linux installation and an android phone (both give the same output in the system log). Only from the linux installation I can see the client logs.

System Log RPI Excerpt:

daemon.info hostapd: wlan0: STA \<MAC-ADDRESS-WIFI-CLIENT\> IEEE 802.11: associated
daemon.notice hostapd: wlan0: CTRL-EVENT-EAP-STARTED \<MAC-ADDRESS-WIFI-CLIENT\>
daemon.notice hostapd: wlan0: CTRL-EVENT-EAP-PROPOSED-METHOD vendor=0 method=1
daemon.notice hostapd: wlan0: CTRL-EVENT-EAP-SUCCESS2 \<MAC-ADDRESS-WIFI-CLIENT\>
daemon.info hostapd: wlan0: STA \<MAC-ADDRESS-WIFI-CLIENT\> IEEE 802.11: disassociated


config wifi-device 'radio0'
	option type 'mac80211'
	option hwmode '11g'
	option path 'platform/soc/3f300000.mmc/mmc_host/mmc1/mmc1:0001/mmc1:0001:1'
	option htmode 'HT20'
	option country '\<COUNTRY\>'
	option legacy_rates '1'
	option channel '6'

config wifi-iface 'wifinet0'
	option auth_server '\<SERVER-IP\>'
	option ssid '\<SSID\>'
	option device 'radio0'
	option acct_port '1813'
	option auth_port '1812'
	option acct_server '\<SERVER-IP\>'
	option network 'lan'
	option mode 'ap'
	option auth_secret '\<PASSWORD\>'
	option acct_secret '\<PASSWORD\>'
	option encryption 'wpa2'

Key reinstallation countermeasures and 802.11w Management Frame Protection are not enabled.

client wifi configuration:

WPA+WPA2 Enterprise
PEAP (auto version)+MSVCHAPv2

wifi client dmesg excerpt:

authenticate with \<MAC-ADDRESS-AP\>
send auth to \<MAC-ADDRESS-AP\> (try 1/3)
associate with \<MAC-ADDRESS-AP\> (try 1/3)
RX AssocResp from \<MAC-ADDRESS-AP\> (capab=0x411 status=0 aid=1)
Limiting TX power to 30 (30 - 0) dBm as advertised by \<MAC-ADDRESS-AP\>
deauthenticating from \<MAC-ADDRESS-AP\> by local choice (Reason: 17=IE_DIFFERENT)

As can be seen from the information here it all goes wrong when the Client deauthenticated based on the 802.1x deauthentication reason code: 17=IE_DIFFERENT. It is supposed to mean: "Information element in 4-Way Handshake different from (Re)Association Request/Probe
Response/Beacon frame" taken from https://community.cisco.com/t5/wireless-mobility-documents/802-11-association-status-802-11-deauth-reason-codes/ta-p/3148055 . The page has as explanation: "NOT SUPPORTED", which is rather useless. It looks like it is going wrong in EAPOL-KEY 4-way handshake part, as can be seen here https://docs.microsoft.com/en-us/windows/client-management/advanced-troubleshooting-802-authentication . I however am not well versed in this protocol. Does somebody understand what is going on?

  1. Do you have other APs where radius authentication works with that clients ?
    What openwrt version are you using ?
  2. I would first try to only use radius authentication and not use radius accounting to simplify the search. So I would unset / comment out the 3 acct_ settings.
  3. If you start the freeradius server in a command line with freeradius -X you get the debug output from the radius server. Here you should see what happens to authentication. I no longer use mschapv2. That authentication takes quite long and is pretty complicated. TLS with client certificates is much easier. With mschapv2 I also sometimes had the problem that authentication failed temporarily, and 5 minutes later it worked... But that was with tomato access points.
  1. Yes, all clients work with the other AP. The RPi uses OpenWRT 19.07.7.
  2. I will try that.
  3. Maybe I'll switch too; I just chose MSCHAPV2 when setting it up and it worked so I stayed, but TLS looks good too.

I did use the radiusd -X, but I can't easily post it, because of a lot of data leakage and it's an awful lot of lines.

If you have tried the radius-X, you can compare a successful authentication from a device with an unsuccessful authentication of the same device via the openwrt AP and check the differences.

But with the success2 message it looks like the radius authentication is fine and the problem happens afterwards.

shows the process.

Googling around a little bit it seems that this 17=IE_DIFFERENT occurs on pi4:


If you temporarily switch to wpa2/psk all is fine ?

I did try to find some differences, but it's pretty hard without knowing what your looking at. I didn't see anything obvious at least. I agree that it must be after that, because the EAPOL 4-way handshake fails.
I forgot to mention that it does indeed work with the wpa2-psk.

I read that post (original issue is here https://github.com/raspberrypi/linux/issues/3619). This is an open issue with the brcmfmac driver not supporting 802.11w management frame protection, which I have disabled.

I just found someone with the same looking issue (It might have another reason) here Clients abort 4-way handshake, RSN IE different in message 3/4 . This however was left unsolved. He did find something interesting, though: the reserved bit was different. Maybe I could make such a dump too and see if it is the same problem. From my first impression this seems like a reserved bit is set, instead of left reserved. As far as I know, reserved bits are there for future functionality, which is then supported by the AP and unsupported by my clients (which doesn't make much sense, because everything is up to date, unless it's in the driver). I might be completely wrong with this interpretation and this might also not be the difference between my messages. I would need to look into that.

I have looked into another post of me, and indeed I had failing mschapv2 authentication every now and then with openwrt, not only with tomato. I checked my old router logs, but I did not find anything that looks like your problem.

I just remember from the radius logs, that authentication with mschapv2 took quite long, going back and forth and sometimes did not work at all. With tls this process is really fast, and I do not have any such problems. But I have different AP hardware. It might be a wifi driver problem...

I used the following command to log more info of the process.

# wpa_supplicant -dd -u -f ~/wpa.log

I found that I indeed have the exact same problem as the person in Clients abort 4-way handshake, RSN IE different in message 3/4 . The 20th byte (starting at 0) in the "RSN IE in Beacon/ProbeResp" is 1 higher than the one in "RSN IE in 3/4 msg". indicating that the last bit in that byte is 1 and not 0.

I found a description of the information element here https://www.idc-online.com/technical_references/pdfs/data_communications/RSN.pdf . As it pertains to the last 2 bytes/octets, the problem lies in the RSN capabilities.
I found a definition for the bits in an image on this page under 21 https://mrncciew.com/2014/10/08/802-11-mgmt-beacon-frame/ . I think it is the default way of representing bytes: most to least significant from left to right, and they use the same endianess as wpa_supplicant. I had the capabilities: 0d 00 (RSN IE in Beacon/ProbeResp) and 0c 00 (RSN IE in 3/4 msg). This seems like the beacon IE has indeed the last bit set of the first byte, while the 3/4 msg doesn't. Both however have the 4th and 5th bits (starting from 0) set of the first byte.

This is where it gets really weird. Assuming the same endianess, the 4th and 5th bits mean something with the SPP and the last bit is reserved. However I misread the bytes as 00 0d and 00 0c respectively. Which would mean that pre authentication is enabled or not. I thought I would set option rsn_preauth '1' in the access point settings and it just worked. It looks like it does now only advertise 0d 00 capabilities. Nice that it works, but why? Am I misreading the endianness or is there some weird bug causing this.

1 Like

So if I read your post correctly, you got it working by setting rsn_preauth '1', but that one should change the last bit of Byte 21, not the last bit of Byte 20 starting at 0 ?

https://mrncciew.com/2014/08/21/cwsp-rsn-information-elements/ status that the Information Element has variable length, and in their example the length is 20 :-). So check the 1st Byte (starting at 0) of the Information Element, it contains the Total length. Maybe that explains your problem.

But nice to hear you got it running!!! Congratulations to this :partying_face:

The 1st byte has value 14, so that would be len=20. The length was actually 22, so assuming the first 2 bytes don't count, that would check out. The variable part would make sense according to the sources listed and I was indeed looking at the correct bytes (the last 2).

However, as network protocols often are big-endian and computers little-endian (https://en.wikipedia.org/wiki/Endianness), It might just be that the debug-messages don't compensate for this and I just read it wrong.

It looks like hexdump, The utitlity used by wpa_supplicant to dump the message to stdout, only dumps what is in memory using the CPUs endianness by default (https://unix.stackexchange.com/questions/55770/does-hexdump-respect-the-endianness-of-its-system). It might be that the byte order of the words in the IE should be reversed.

I just encountered the client version of the problem. I have a RPI 0w that I use a as a client to the my main router. Previously I just used a random config of the internet, but I had issues with it being unable to reconnect after some uptime, so I decided to investigate. I found out I was using the legacy driver (wext). Using the mac80211 driver the version of wpasupplicant currently used by raspbian (v2.8), crashes. So I installed Arch and tried the newest version of wpasupplicant (2.9). It didn't crash anymore, but I got the same issue as when connecting with any client to the "RPI3B as AP". I couldn't find anything in the logs on the RPI 0w about it, but didn't look on the AP. I had been looking on the internet and after a while I found that by enabling "Opportunistic Key Caching" I could force the preauth behaviour (https://wireless.wiki.kernel.org/en/users/Documentation/wpa_supplicant). I set the setting in wpa_supplicant.conf: okc=1 and I was connected again. I think it is time I opened a bug report. There must be some issue with the brcmfmac driver-firmware interaction on the raspberry pi, where it sets the a different IE on different levels for this "niche" usecase.