Date: Tue, 28 Feb 2006 19:32:06 -0800 From: Sam Leffler <sam@errno.com> To: Peter de Rooij <peter@derooij.org> Cc: freebsd-mobile@freebsd.org Subject: Re: ral/wpa_supplicant drops after successful WPA negotiation? Message-ID: <440515B6.1080202@errno.com> In-Reply-To: <141fde50602280533m7460ada3i@mail.gmail.com> References: <43F9E6B4.3040309@derooij.org> <43F9F4AD.3070107@errno.com> <43FA61A4.8030406@derooij.org> <141fde50602280533m7460ada3i@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Peter de Rooij wrote: > This is follow-up to > http://docs.FreeBSD.org/cgi/mid.cgi?43FA61A4.8030406 (lengthy!) > > In short, I am trying to use WPA with the ral driver (ral0: MAC/BBP > RT2560 (rev 0x04), RF RT2525) on 6.0 RELEASE. wpa_supplicant seems to > negotiate successfully but then times out (authentication time-out). > The debug message is "ral0: [XX:XX:XX:XX:XX:XX] send station > disassociate (reason 8)" > I also get an error "ioctl[SIOCS80211, op 20, len 7]: Can't assign > requested address". I don't see a log from wpa_supplicant. "reason 8" is (from net80211/ieee80211.h): IEEE80211_REASON_ASSOC_LEAVE = 8, Typically this is what wpa_supplicant sends when it fails to complete the key exchange fast enough--which in the case of enabling all the debug msgs could easily occur. The ioctl complaint is (op 20): #define IEEE80211_IOC_DELKEY 20 so likely uninteresting. > > Sam gave a suggestion as to the cause: >> This sort of looks like the race I fixed in HEAD recently that caused >> the timer used to identify unanswered mgt frame transmits to trigger >> unexpectedly. > but further digging showed it wasn't (symptoms didn't match). > > Well, I now can add more info: using Kismet from a separate PC I find > one instance where the authentication times out *after* sending an > encrypted data package. It's acknowledged (and then further ignored, > since it's IPv6) by the AP. See frame 252 below. I can provide full > details if useful. > Disabling IPv6 does make no difference (auth time-out) so I would > guess that it's not related to that. > > Excerpt from text export of kismet dump (belkin is the FreeBSD host, > D-Link is the AP; I deleted all beacons and packets from other APs and > hosts): > ============================================================ > No. Time Source Destination Protocol Info > 207 84.392377 Belkin_14:e8:0a Broadcast Probe > Request Probe Request,SN=1,FN=0, SSID: Broadcast > 208 84.392790 D-Link_1a:0b:65 (RA) > Acknowledgement Acknowledgement > 209 84.393472 D-Link_05:1e:32 Belkin_14:e8:0a Probe > Response Probe Response,SN=186,FN=0,BI=1000, SSID: "Epsilon3" > 210 84.393591 D-Link_05:1e:32 (RA) > Acknowledgement Acknowledgement > 219 86.993477 Belkin_14:e8:0a D-Link_05:1e:32 > Authentication Authentication,SN=0,FN=0 > 220 86.993651 Belkin_14:e8:0a (RA) > Acknowledgement Acknowledgement > 221 86.994076 D-Link_05:1e:32 Belkin_14:e8:0a > Authentication Authentication,SN=195,FN=0 > 222 86.994624 Belkin_14:e8:0a D-Link_05:1e:32 > Association Request Association Request,SN=1,FN=0, SSID: "Epsilon3" > 223 86.994791 Belkin_14:e8:0a (RA) > Acknowledgement Acknowledgement > 224 86.995288 D-Link_05:1e:32 Belkin_14:e8:0a > Authentication Authentication,SN=195,FN=0 > 225 86.995409 D-Link_05:1e:32 (RA) > Acknowledgement Acknowledgement > 226 86.996484 D-Link_05:1e:32 Belkin_14:e8:0a > Association Response Association Response,SN=196,FN=0 > 227 86.996964 D-Link_05:1e:32 Belkin_14:e8:0a > Association Response Association Response,SN=196,FN=0 > 228 86.997088 D-Link_05:1e:32 (RA) > Acknowledgement Acknowledgement > 232 88.270387 fe80::211:50ff:fe14:e80a ff02::2:4c46:3d12 > ICMPv6 Multicast listener report > 233 88.270620 Belkin_14:e8:0a (RA) > Acknowledgement Acknowledgement > 236 90.473873 D-Link_05:1e:32 Belkin_14:e8:0a EAPOL Key > 237 90.474098 D-Link_05:1e:32 (RA) > Acknowledgement Acknowledgement > 238 90.474716 Belkin_14:e8:0a D-Link_05:1e:32 EAPOL Key > 239 90.474951 Belkin_14:e8:0a (RA) > Acknowledgement Acknowledgement > 240 90.477506 D-Link_05:1e:32 Belkin_14:e8:0a EAPOL Key > 241 90.477735 D-Link_05:1e:32 (RA) > Acknowledgement Acknowledgement > 242 90.478066 Belkin_14:e8:0a D-Link_05:1e:32 EAPOL Key > 243 90.478301 Belkin_14:e8:0a (RA) > Acknowledgement Acknowledgement > 244 90.480196 D-Link_05:1e:32 Belkin_14:e8:0a Data > Data,SN=204,FN=0 > 245 90.480814 D-Link_05:1e:32 Belkin_14:e8:0a Data > Data,SN=204,FN=0 > 246 90.481250 D-Link_05:1e:32 Belkin_14:e8:0a Data > Data,SN=204,FN=0 > 247 90.482007 D-Link_05:1e:32 Belkin_14:e8:0a Data > Data,SN=204,FN=0 > 248 90.482705 D-Link_05:1e:32 Belkin_14:e8:0a Data > Data,SN=204,FN=0 > 252 93.470464 Belkin_14:e8:0a > IPv6-Neighbor-Discovery_ff:14:e8:0a Data Data,SN=5,FN=0 > 253 93.470688 Belkin_14:e8:0a (RA) > Acknowledgement Acknowledgement > 254 93.471615 Belkin_14:e8:0a > IPv6-Neighbor-Discovery_ff:14:e8:0a Data Data,SN=208,FN=0 > 281 118.677849 Belkin_14:e8:0a Broadcast Probe > Request Probe Request,SN=41,FN=0, SSID: Broadcast > ============================================================ > Frames 244-248 are resends of the same encrypted data by the AP. kismet packet traces are not very informative; I prefer ethereal. It appears the station associated and setup the PTK. Past that I see "Data" frames that are presumably encrypted. There should be an exchange to setup the GTK that is encrypted using the PTK so presumably that's it. The frames don't appear to be ACK'd by the station (SN is the sequence number and it looks to be 204 for each frame from the AP->STA) so presumably the station dropped it. This is possibly related to the issues I've seen where ral cards appear to be setup with incorrect IFS parameters (e.g. slot time) and/or generate frames with wrong duration settings (so other stations in the bss don't set their NAV long enough and transmit prematurely clobbering ral frames). > > Any suggestion what to do next? > - buy a new wlan card? > - buy a new AP? > - install driver or kernel upgrade? > - install Sam's bug fix even though it doesn't match the symptoms? > - do something else that might help pinpoint the issue? > > (& don't hesitate to tell me I should post this elsewhere!) ral is hit&miss for me when operating as a station. Unfortunately I don't have chip specs and I haven't figured out what's wrong with the driver based on looking at the linux code. If you want to keep the card you can see if ndis will work. Otherwise you can buy a different card. Sam
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?440515B6.1080202>