Re: Wireless connection (WPA-EAP) stops working after a while

Sam Leffler wrote:
Daniel Thiele wrote:
Hi,

I have a problem with my wireless connection. I am running FreeBSD
8.0-CURRENT (from Mar 22) with wpa_supplicant v0.6.8 using an Atheros
based ExpressCard (D-Link DWA-643 via ath(4)) and alternatively a Ralink
based USB adapter (Linksys WUSB54GC-EU via rum(4)).

At home using the Atheros card together with a FreeBSD (7.1) based
access point (using rum(4) in hostap mode) and the wpa_supplicant.conf
(attached at the end of this email) settings for SSID="home" I don't
have any problems. With a Linksys WRT54GL-DE access point
running the OpenWRT White Russian 0.9 firmware and OpenVPN over an open
wireless LAN also works flawlessly.

At the university, however, (SSID="IDA" in the wpa_supplicant.conf at
the end of this email) the wireless connection only works for about an
hour. The vague term "wireless connection" in this case means, that the
WPA connection is opened and associated, then I get an IP address via
dhclient. There is a message about "OpenSSL: tls_connection_handshake -
Failed to read possible Application Data
error:00000000:lib(0):func(0):reason(0)" and "TLS: Unsupported Phase2
EAP method 'MSCHAPv2'" but the authentication seems to succeed:

<...stuff deleted...>


Mar 23 14:28:45 impala wpa_supplicant[429]: EAP-MSCHAPV2: Authentication
succeeded
Mar 23 14:28:45 impala wpa_supplicant[429]: EAP-TLV: TLV Result -
Success - EAP-TLV/Phase2 Completed
Mar 23 14:28:46 impala wpa_supplicant[429]: CTRL-EVENT-EAP-SUCCESS EAP
authentication completed successfully
Mar 23 14:28:46 impala wpa_supplicant[429]: WPA: Failed to set PTK to
the driver.
Mar 23 14:28:46 impala wpa_supplicant[429]: WPA: Key negotiation
completed with 00:1b:2f:ef:d3:c9 [PTK=CCMP GTK=TKIP]

This doesn't look good. For some reason the PTK key was not plumbed; this means the ioctl that made the request failed. Unfortunately there's no more information to explain why but typically this is because the station is no longer associated. But for some reason wpa_supplicant didn't seem to handle the error properly; it appears it thinks the key exchange was completed when it was not. A glance at the code looks like it's ignoring errors; e.g. in contrib/wpa/src/rsn_supp/wpa.c in wpa_supplicant_process_3_of_4:

if (key_info & WPA_KEY_INFO_INSTALL) {
wpa_supplicant_install_ptk(sm, key);
}

(the error return by wpa_supplicant_install_ptk is not checked). This might be handled some other way but it's not clear why it should proceed.


Mar 23 14:29:01 impala wpa_supplicant[429]: CTRL-EVENT-SCAN-RESULTS
Mar 23 14:34:03 impala wpa_supplicant[429]: CTRL-EVENT-SCAN-RESULTS
Mar 23 14:39:05 impala wpa_supplicant[429]: CTRL-EVENT-SCAN-RESULTS
----8<--------------------------------------------------------

ifconfig still lists the connection as "associated":

----8<--------------------------------------------------------
impala# ifconfig wlan0
wlan0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
ether 00:21:91:db:15:30
media: IEEE 802.11 Wireless Ethernet OFDM/48Mbps mode 11g
status: associated
ssid IDA channel 13 (2472 Mhz 11g) bssid 00:1b:2f:ef:d3:c9
regdomain ETSI indoor ecm authmode WPA2/802.11i privacy ON
deftxkey UNDEF TKIP 2:128-bit txpower 20 bmiss 7 scanvalid 450
bgscan
bgscanintvl 300 bgscanidle 250 roam:rssi 7 roam:rate 5 protmode CTS
wme burst roaming MANUAL
----8<--------------------------------------------------------

But dhclient does not accept any new leases:

----8<--------------------------------------------------------
impala# dhclient wlan0
DHCPREQUEST on wlan0 to 255.255.255.255 port 67
DHCPNAK from 192.168.100.1
DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 4
DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 10
DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 12
DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 13
DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 8
DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 14
No DHCPOFFERS received.
Trying recorded lease 192.168.100.54
bound: renewal in 5900 seconds.
----8<--------------------------------------------------------

The site's wireless admin was so kind to provide me with the logs from
their DHCP server, which seems to offer new leases that somehow don't
make it through to my machine:

----8<--------------------------------------------------------
DHCPDISCOVER from 00:21:91:db:15:30 (impala) via 192.168.100.1
DHCPOFFER on 192.168.100.54 to 00:21:91:db:15:30 (impala) via 192.168.100.1
----8<--------------------------------------------------------

If I audaciously assign myself an IP address (192.168.100.54) and set
the default route to 192.168.100.1, the wireless connection sill won't
work. I cannot even ping the router at 192.168.100.1.


Next, I tried to rule out the wireless adapter. Both the Atheros
ExpressCard and the Ralink USB Adapter show the above mentioned
behavior. So the problem might perhaps be located in FreeBSD's wireless
stack, wpa_supplicant or dhclient? But I'm not an expert in these areas,
thus this email.

It appears this is an issue in wpa_supplicant but it's hard to say. I'd need to know if the association was broken during the time the key plumb failed. That should've been reported to wpa_supplicant which should've logged a msg so I'm guessing no. So we're back to why the key wasn't plumbed as everything that follows makes sense (i.e. you can't get data packets through). If you turn on crypto debugging in net80211 you might get some info from the console msgs; e.g.

wlandebug crypto

You should also configure wpa_supplicant debugging so we get more info from the driver; add

wpa_supplicant_flags="-sd"

to your rc.conf file (or start wpa_supplicant by hand).


Thanks, I will try that.



What works in the case of the Ralink USB adapter is simply unplugging
and replugging the device. Then I get another hour of working wireless
before it breaks again. Since hot-plugging the ExpressCard currently
does not seem to work I cannot confirm this for the Atheros adapter.

This sounds like the supplicant is out of sync w/ the ap and you can't get packets through because you've got the old/wrong key plumbed on the station.


I also tried

----8<--------------------------------------------------------
/etc/rc.d/netif restart
----8<--------------------------------------------------------

and

----8<--------------------------------------------------------
ifconfig wlan0 destroy
ifconfig wlan0 create wlandev rum0
----8<--------------------------------------------------------

followed by a restart of wpa_suppicant and dhclient, too, but without
any success. So only re-plugging the device seems to solve or at least
stall the problem.

That doesn't make sense. Destroying the vap should be equivalent to ejecting the device. There should no crypto state kept after a vap is destroyed. You can verify this for the ath device using athregs (tools/tools/ath/athregs); athregs -k will dump the contents of the h/w key cache if the ath driver is built with ATH_DIAGAPI).

This is enabled by adding "options ATH_DIAGAPI" to my kernel
configuration file, right?



The output of wpa_supplicant -ddd after the wireless connection stopped
working can be found at:
http://www-public.tu-bs.de:8080/~y0023183/FreeBSD/Wireless/wpa_supplicant-ddd.txt



On a FreeBSD 7.1-STABLE machine with wpa_supplicant v0.5.10 and the
Ralink USB adapter I did not encounter the problem.

If I understand correctly the above is for FreeBSD HEAD+0.6.8 so a more useful comparison is HEAD+0.5.11/0.5.10 which would tell us definitely if this is a supplicant issue.


Yes, the machine with the borken wireless is a HEAD+0.6.8. I have not
tried HEAD+0.5.11, yet. But I will do that on Friday.



Now, my question is has anyone else encountered this behavior (WPA-PSK
working nicely and WPA-EAP only for a limited period of time) and knows
how to fix this issue? Perhaps it is just a misconfiguration on my
part. If not, how can I help to further investigate this issue. What can
I do to provide additional debug information?


I checked the 0.6.9 release that I suggested might have a fix but was wrong. The change that caught my attention was for hostapd, not wpa_supplicant. So we're back to isolating whether this is a regression in the supplicant. The best suggestion I have is to back-rev your HEAD tree to just before I imported wpa_supplicant 0.6.8. Talk to me off-line if you need help w/ that.


I already prepared a USB flash drive with a CURRENT from March 3 20:00h.
At least i hope that this is what

*default release=cvs tag=. date=2009.03.01.20.00.00

in my supfile gave me. A first boot confirmed that I got wpa_supplicant
0.5.11, so I think it worked.

BTW. is there a way for normal users to easily check-out a specific SVN
revision? The procedure described in the FreeBSD wiki
http://wiki.freebsd.org/SubversionPrimer seems to require a valid
FreeBSD login name. And I can understand that to efficiently use
resources and bandwidth CVSup is used to serve normal users. Maybe I'm
just missing something, but it is a little cumbersome to manually look
up the SVN revisions at svn-src-head@ to get the corresponding date for
the supfile.

Anyway, on Friday I will turn on debug output on my HEAD+0.6.8 (or 0.6.9
as of yesterday) machine and also investigate the issue with the
prepared USB flash drive and a back-rev'ed HEAD+0.5.11.


Daniel

_______________________________________________
freebsd-current@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@xxxxxxxxxxx"

Relevant Pages

  • Re: OT: Windows Vista users?
    ... Netgear a wireless connection is a wireless connection, Heck, if your neighbors wireless is not secure, it should find and set it up automatically. ... While I haven't had a chance to see how Justbob's suggestions may work, I KNOW its a Vista problem. ...
    (alt.support.diabetes)
  • Re: Wireless connection (WPA-EAP) stops working after a while
    ... I have a problem with my wireless connection. ... wlan0: ... What works in the case of the Ralink USB adapter is simply unplugging ...
    (freebsd-current)
  • Re: Internet connection problems
    ... When I first turn on the above laptop a wireless connection is established with my router but when I launch my browser it says 'Looking up ' but the page cannot be found. ... This means the default gateway is set up correctly, but if you try pinging e.g. google.com by name, you can test whether DNS resolution is working from a command line ping. ...
    (uk.comp.homebuilt)
  • Wireless connection (WPA-EAP) stops working after a while
    ... I have a problem with my wireless connection. ... ExpressCard and the Ralink USB Adapter show the above mentioned ... What works in the case of the Ralink USB adapter is simply unplugging ...
    (freebsd-current)
  • Re: WireleSs domain user logon problems
    ... > Wireless NIC's software when you logon to Windows, ... >> Actually, in some cases, if the wireless connection will not be ... Small Delay in Logon to Network When You Use a Wireless Network ...
    (microsoft.public.win2000.active_directory)