Modify

Opened 3 years ago

Closed 3 years ago

#18343 closed defect (no_response)

WPA2 802.1x with 4addr mode hangs on rekey

Reported by: Vittorio G (VittGam) <openwrt@…> Owned by: developers
Priority: normal Milestone:
Component: base system Version: Trunk
Keywords: hostapd, wpa-supplicant, wpa2, 802.1x, 4addr Cc:

Description

Hi everyone,

I'm having a problem with 4addr mode on a WPA2 802.1x setup.

AP is an ar71xx based Dragino 2 using OpenWrt BB r42853. STA is an unmodified wr703n using OpenWrt BB r42625 (that is, hardware is unmodified, software of course is :P ).

Sometimes when there is a key handshake the connection will partially drop. Packets still flow in one direction but not in the other. (TODO: determine the exact direction, but should be AP->STA working and STA->AP not working)

Logs and config follow. Connection stopped working at 18:12:08. It started working again at 18:22:31.

On the AP I provide optional ieee80211w Management Frames Protection. On the STA I enforce it with ieee80211w = 2.

Please note that the AP is also a STA connected to an Open network (just fyi, there is policy based routing that uses this insecure connection only to connect to a VPN, which then serves br-lan).

This is happening with an unplugged eth0 on the STA, I haven't tested if it happens with a plugged eth0 too. The br-lan only contains eth0 and wlan0 though.

AP log

Fri Nov 14 18:12:08 2014 daemon.info hostapd: wlan0: STA cc:cc:cc:cc:cc:cc WPA: group key handshake completed (RSN)
Fri Nov 14 18:22:08 2014 daemon.info hostapd: wlan0: STA cc:cc:cc:cc:cc:cc WPA: group key handshake completed (RSN)
Fri Nov 14 18:22:12 2014 daemon.info hostapd: wlan0: STA cc:cc:cc:cc:cc:cc RADIUS: starting accounting session 12345678-00000000
Fri Nov 14 18:22:12 2014 daemon.info hostapd: wlan0: STA cc:cc:cc:cc:cc:cc IEEE 802.1X: authenticated - EAP type: 13 (TLS)
Fri Nov 14 18:22:21 2014 daemon.info hostapd: wlan0: STA cc:cc:cc:cc:cc:cc IEEE 802.11: deauthenticated due to local deauth request
Fri Nov 14 18:22:21 2014 kern.info kernel: [357807.510000] device wlan0.sta1 left promiscuous mode
Fri Nov 14 18:22:21 2014 kern.info kernel: [357807.520000] br-lan: port 4(wlan0.sta1) entered disabled state
Fri Nov 14 18:22:28 2014 daemon.info hostapd: wlan0: STA cc:cc:cc:cc:cc:cc IEEE 802.11: authenticated
Fri Nov 14 18:22:28 2014 daemon.info hostapd: wlan0: STA cc:cc:cc:cc:cc:cc IEEE 802.11: associated (aid 1)
Fri Nov 14 18:22:28 2014 kern.info kernel: [357814.230000] device wlan0.sta1 entered promiscuous mode
Fri Nov 14 18:22:28 2014 kern.info kernel: [357814.240000] br-lan: port 4(wlan0.sta1) entered forwarding state
Fri Nov 14 18:22:28 2014 kern.info kernel: [357814.240000] br-lan: port 4(wlan0.sta1) entered forwarding state
Fri Nov 14 18:22:29 2014 daemon.info hostapd: wlan0: STA cc:cc:cc:cc:cc:cc WPA: pairwise key handshake completed (RSN)
Fri Nov 14 18:22:29 2014 daemon.info hostapd: wlan0: STA cc:cc:cc:cc:cc:cc RADIUS: starting accounting session 12345678-00000001
Fri Nov 14 18:22:29 2014 daemon.info hostapd: wlan0: STA cc:cc:cc:cc:cc:cc IEEE 802.1X: authenticated - EAP type: 13 (TLS) (PMKSA cache)
Fri Nov 14 18:22:30 2014 kern.info kernel: [357816.240000] br-lan: port 4(wlan0.sta1) entered forwarding state

STA log

Fri Nov 14 18:22:27 2014 kern.info kernel: [ 6495.770000] wlan0: deauthenticating from aa:aa:aa:aa:aa:aa by local choice (Reason: 2=PREV_AUTH_NOT_VALID)
Fri Nov 14 18:22:27 2014 kern.info kernel: [ 6495.790000] br-lan: port 2(wlan0) entered disabled state
Fri Nov 14 18:22:27 2014 daemon.notice netifd: Network device 'wlan0' link is down
Fri Nov 14 18:22:28 2014 kern.info kernel: [ 6496.570000] wlan0: authenticate with aa:aa:aa:aa:aa:aa
Fri Nov 14 18:22:28 2014 kern.info kernel: [ 6496.590000] wlan0: send auth to aa:aa:aa:aa:aa:aa (try 1/3)
Fri Nov 14 18:22:28 2014 kern.info kernel: [ 6496.590000] wlan0: authenticated
Fri Nov 14 18:22:28 2014 kern.info kernel: [ 6496.610000] wlan0: associate with aa:aa:aa:aa:aa:aa (try 1/3)
Fri Nov 14 18:22:28 2014 kern.info kernel: [ 6496.610000] wlan0: RX AssocResp from aa:aa:aa:aa:aa:aa (capab=0x431 status=0 aid=1)
Fri Nov 14 18:22:28 2014 kern.info kernel: [ 6496.620000] wlan0: associated
Fri Nov 14 18:22:28 2014 daemon.notice netifd: Network device 'wlan0' link is up
Fri Nov 14 18:22:28 2014 daemon.notice netifd: Bridge 'br-lan' link is down
Fri Nov 14 18:22:28 2014 daemon.notice netifd: Interface 'lan' has link connectivity loss
Fri Nov 14 18:22:29 2014 kern.info kernel: [ 6497.630000] br-lan: port 2(wlan0) entered forwarding state
Fri Nov 14 18:22:29 2014 kern.info kernel: [ 6497.640000] br-lan: port 2(wlan0) entered forwarding state
Fri Nov 14 18:22:29 2014 daemon.notice netifd: Bridge 'br-lan' link is up
Fri Nov 14 18:22:29 2014 daemon.notice netifd: Interface 'lan' has link connectivity 
Fri Nov 14 18:22:31 2014 kern.info kernel: [ 6499.640000] br-lan: port 2(wlan0) entered forwarding state

AP wireless config

config wifi-device 'radio0'
	option type 'mac80211'
	option channel '0'
	option hwmode '11ng'
	option path 'platform/ar933x_wmac'
	option htmode 'HT20'
	option noscan '1'
	option country 'IT'
	option distance '3000'
	option txpower '20'
	option disabled '0'

config wifi-iface 'wifiap'
	option device 'radio0'
	option ifname 'wlan0'
	option network 'lan'
	option mode 'ap'
	option ssid 'VittGam.net'
	option rsn_preauth '0'
	option wds '1'
	option encryption 'wpa2+ccmp'
	option auth_server '1.2.3.4'
	option auth_secret 'blah'
	option auth_cache '1'
	option macaddr 'aa:aa:aa:aa:aa:aa'
	option hidden '0'
	option disabled '0'
	option isolate '0'
	option ieee80211w '1'

config wifi-iface 'wifista'
	option device 'radio0'
	option ifname 'wlan0-1'
	option network 'wwan'
	option mode 'sta'
	option ssid 'Open Insecure Wifi Network'
	option macaddr 'aa:aa:aa:aa:aa:ab' # device has 2 mac addresses assigned but mac80211 sees only the first one... TODO FIXME in the mach file
	option bssid '12:34:56:78:90:12'
	option encryption 'none'
	option disabled '0'
	option ieee80211w '1'

STA wireless config

config wifi-device 'radio0'
	option type 'mac80211'
	option channel '0'
	option hwmode '11ng'
	option path 'platform/ar933x_wmac'
	option htmode 'HT20'
	option noscan '1'
	option country 'IT'
	option distance '3000'
	option txpower '20'
	option disabled '0'

config wifi-iface 'wifista'
	option device 'radio0'
	option network 'lan'
	option mode 'sta'
	option ssid 'VittGam.net'
	option rsn_preauth '0'
	option wds '1'
	option encryption 'wpa2+ccmp'
	option ca_cert '/root/wifistacerts/cacert.pem'
	option eap_type 'tls'
	option identity 'blah'
	option client_cert '/root/wifistacerts/clientcert.pem'
	option priv_key '/root/wifistacerts/clientkey.pem'
	option bssid 'aa:aa:aa:aa:aa:aa'
	option macaddr 'cc:cc:cc:cc:cc:cc'
	option hidden '0'
	option disabled '0'
	option ieee80211w '2'

Relevant AP network config

config interface 'lan'
	option ifname 'eth0 eth1'
	option force_link '1'
	option type 'bridge'
	option proto 'static'
	option ipaddr '1.2.4.1'
	option netmask '255.255.255.0'
	option ip6addr 'aaaa::1/64'
	option ip6assign '64'
	option ip6class 'vpn'

Relevant STA network config

config interface 'lan'
	option ifname 'eth0'
	option force_link '1'
	option type 'bridge'
	option proto 'dhcp'

Thank you for your help,
Vittorio G

Attachments (0)

Change History (9)

comment:1 Changed 3 years ago by VittGam

This just happened again, but connection was only lost for 21 seconds and not for 10 minutes as before.

So the problem seems to be that the AP decides for some reason to deauthenticate the STA, but the STA does not receive the deauth. Maybe this is happening because of some MFP-related bug after the change of the group key?

I'm now going to try to disable ieee80211w MFP temporarily on the STA to see if this gets somehow better.

(By the way, is there a way to make the log on the STA more verbose?)

AP log

Sat Nov 15 05:45:39 2014 daemon.info hostapd: wlan0: STA cc:cc:cc:cc:cc:cc RADIUS: starting accounting session 12345678-00000006
Sat Nov 15 05:45:39 2014 daemon.info hostapd: wlan0: STA cc:cc:cc:cc:cc:cc IEEE 802.1X: authenticated - EAP type: 13 (TLS) (PMKSA cache)
Sat Nov 15 05:45:48 2014 daemon.info hostapd: wlan0: STA cc:cc:cc:cc:cc:cc IEEE 802.11: deauthenticated due to local deauth request
Sat Nov 15 05:45:48 2014 kern.info kernel: [398814.090000] device wlan0.sta1 left promiscuous mode
Sat Nov 15 05:45:48 2014 kern.info kernel: [398814.100000] br-lan: port 4(wlan0.sta1) entered disabled state
Sat Nov 15 05:45:57 2014 daemon.info hostapd: wlan0: STA cc:cc:cc:cc:cc:cc IEEE 802.11: authenticated
Sat Nov 15 05:45:57 2014 daemon.info hostapd: wlan0: STA cc:cc:cc:cc:cc:cc IEEE 802.11: associated (aid 1)
Sat Nov 15 05:45:57 2014 kern.info kernel: [398822.880000] device wlan0.sta1 entered promiscuous mode
Sat Nov 15 05:45:57 2014 kern.info kernel: [398822.890000] br-lan: port 4(wlan0.sta1) entered forwarding state
Sat Nov 15 05:45:57 2014 kern.info kernel: [398822.890000] br-lan: port 4(wlan0.sta1) entered forwarding state
Sat Nov 15 05:45:57 2014 daemon.info hostapd: wlan0: STA cc:cc:cc:cc:cc:cc WPA: pairwise key handshake completed (RSN)
Sat Nov 15 05:45:57 2014 daemon.info hostapd: wlan0: STA cc:cc:cc:cc:cc:cc RADIUS: starting accounting session 12345678-00000009
Sat Nov 15 05:45:57 2014 daemon.info hostapd: wlan0: STA cc:cc:cc:cc:cc:cc IEEE 802.1X: authenticated - EAP type: 13 (TLS) (PMKSA cache)
Sat Nov 15 05:45:59 2014 kern.info kernel: [398824.890000] br-lan: port 4(wlan0.sta1) entered forwarding state

STA log

Sat Nov 15 05:45:56 2014 kern.info kernel: [47504.390000] wlan0: deauthenticating from aa:aa:aa:aa:aa:aa by local choice (Reason: 2=PREV_AUTH_NOT_VALID)
Sat Nov 15 05:45:56 2014 kern.info kernel: [47504.410000] br-lan: port 2(wlan0) entered disabled state
Sat Nov 15 05:45:56 2014 daemon.notice netifd: Network device 'wlan0' link is down
Sat Nov 15 05:45:57 2014 kern.info kernel: [47505.210000] wlan0: authenticate with aa:aa:aa:aa:aa:aa
Sat Nov 15 05:45:57 2014 kern.info kernel: [47505.230000] wlan0: send auth to aa:aa:aa:aa:aa:aa (try 1/3)
Sat Nov 15 05:45:57 2014 kern.info kernel: [47505.230000] wlan0: authenticated
Sat Nov 15 05:45:57 2014 kern.info kernel: [47505.250000] wlan0: associate with aa:aa:aa:aa:aa:aa (try 1/3)
Sat Nov 15 05:45:57 2014 kern.info kernel: [47505.250000] wlan0: RX AssocResp from aa:aa:aa:aa:aa:aa (capab=0x431 status=0 aid=1)
Sat Nov 15 05:45:57 2014 kern.info kernel: [47505.260000] wlan0: associated
Sat Nov 15 05:45:57 2014 daemon.notice netifd: Network device 'wlan0' link is up
Sat Nov 15 05:45:57 2014 kern.info kernel: [47505.300000] br-lan: port 2(wlan0) entered forwarding state
Sat Nov 15 05:45:57 2014 kern.info kernel: [47505.310000] br-lan: port 2(wlan0) entered forwarding state
Sat Nov 15 05:45:59 2014 kern.info kernel: [47507.310000] br-lan: port 2(wlan0) entered forwarding state

comment:2 Changed 3 years ago by VittGam

Without MFP enabled on the STA, the connection dropped for 17 seconds on group key handshake, but then returned without disconnection.

AP log

Sat Nov 15 06:42:08 2014 daemon.info hostapd: wlan0: STA cc:cc:cc:cc:cc:cc WPA: group key handshake completed (RSN)

STA log

---nothing---

comment:3 Changed 3 years ago by VittGam

Now it dropped for just 3 seconds. I think it's normal behaviour, as this is a quite busy environment with many other Open APs on the same channel and quite a lot of stations connected to them.

So the problem here is clearly with ieee80211w Management Frame Protection.

Last edited 3 years ago by VittGam (previous) (diff)

comment:4 Changed 3 years ago by VittGam

There is still something wrong with those seconds of dropped connection though...

A long-running ping to the STA router has 2.7% of packet loss (639 dropped out of 24000 packets).

While a long-running ping to an android device connected to the same AP has 0.2% of packet loss (38 lost out of 24000).

comment:5 Changed 3 years ago by VittGam

I can confirm that the 2.7% of packet loss for the 4addr STA without ieee80211w is stable over 35000 pings, as is the 0.2% of loss for the 3addr android STA.

Also the deauthentication on the STA because of 2=PREV_AUTH_NOT_VALID happened twice, with the same log as above.

comment:6 Changed 3 years ago by VittGam

I've disabled 4addr mode and now there is 0% packet loss.

I'm going to re-enable ieee80211w=2 with 4addr disabled now to see how it performs.

comment:7 Changed 3 years ago by VittGam

I enabled ieee80211w=2 in 3addr mode. There is 0% packet loss for 3000 pings so far. (EDIT: Just 39 packets dropped out of 54725 as of now.) (EDIT 2: 58 out of 86000. I think this is enough testing...)

So the problem is with 4addr mode, and it is made worse by ieee80211w being enabled.

Last edited 3 years ago by VittGam (previous) (diff)

comment:8 Changed 3 years ago by nbd

please try current trunk

comment:9 Changed 3 years ago by nbd

  • Resolution set to no_response
  • Status changed from new to closed

Add Comment

Modify Ticket

Action
as closed .
The resolution will be deleted. Next status will be 'reopened'.
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.