ath + wep issue

Sam Leffler sam at errno.com
Fri Aug 5 16:03:11 GMT 2005


Robert C. Noland III wrote:
> On Wed, 2005-08-03 at 22:03 -0700, Sam Leffler wrote:
> 
>>Robert C. Noland III wrote:
>>
>>>Ok, on the ath card the issue seems to be related to the interaction
>>>with the AP and the roaming mode...  This problem is exacerbated by the
>>>fact that I sometimes manage to get the card into a state where I can
>>>see outbound 802.11 frames with tcpdump, but never see inbound packets,
>>>i.e. probe responses...  Those are the instances when it scans
>>>forever... Ejecting the card and re-inserting gets me back to a useful
>>>state.
>>>
>>>This is long, sorry...
>>>
>>>This is what happens when I plug the card in and wpa_supplicant tries to
>>>configure the card.
>>>
>>>Aug  3 12:02:39 bbeng-laptop kernel: ath0: <Atheros 5212> mem
>>>0xf4010000-0xf401ffff irq 11 at device 0.0 on cardbus1
>>>Aug  3 12:02:39 bbeng-laptop kernel: ath0: Ethernet address:
>>>00:12:17:6e:fc:18
>>>Aug  3 12:02:39 bbeng-laptop kernel: ath0: mac 5.9 phy 4.3 radio 3.6
>>>Aug  3 12:03:13 bbeng-laptop kernel: ath0: ieee80211_newstate: INIT ->
>>>SCAN
>>>Aug  3 12:03:13 bbeng-laptop kernel: ath0: ieee80211_newstate: SCAN ->
>>>SCAN
>>>Aug  3 12:03:18 bbeng-laptop last message repeated 28 times
>>>Aug  3 12:03:18 bbeng-laptop kernel: ath0: ieee80211_newstate: SCAN ->
>>>AUTH
>>>Aug  3 12:03:23 bbeng-laptop kernel: ath0: ieee80211_newstate: AUTH ->
>>>SCAN
>>>Aug  3 12:03:23 bbeng-laptop kernel: ath0: ieee80211_newstate: SCAN ->
>>>AUTH
>>>Aug  3 12:03:28 bbeng-laptop kernel: ath0: ieee80211_newstate: AUTH ->
>>>SCAN
>>>Aug  3 12:03:28 bbeng-laptop kernel: ath0: ieee80211_newstate: INIT ->
>>>SCAN
>>>Aug  3 12:03:28 bbeng-laptop kernel: ath0: ieee80211_newstate: SCAN ->
>>>SCAN
>>>Aug  3 12:03:33 bbeng-laptop last message repeated 28 times
>>>Aug  3 12:03:39 bbeng-laptop kernel: ath0: ieee80211_newstate: INIT ->
>>>SCAN
>>>Aug  3 12:03:39 bbeng-laptop kernel: ath0: ieee80211_newstate: SCAN ->
>>>SCAN
>>>Aug  3 12:03:44 bbeng-laptop last message repeated 28 times
>>>Aug  3 12:03:50 bbeng-laptop kernel: ath0: ieee80211_newstate: INIT ->
>>>SCAN
>>>Aug  3 12:03:50 bbeng-laptop kernel: ath0: ieee80211_newstate: SCAN ->
>>>SCAN
>>>Aug  3 12:03:55 bbeng-laptop last message repeated 28 times
>>>Aug  3 12:03:56 bbeng-laptop kernel: ath0: ieee80211_newstate: SCAN ->
>>>AUTH
>>>Aug  3 12:03:56 bbeng-laptop kernel: ath0: ieee80211_newstate: AUTH ->
>>>ASSOC
>>>Aug  3 12:03:56 bbeng-laptop kernel: ath0: [00:0d:93:e9:cf:d4] assoc
>>>success: long preamble, long slot time
>>>Aug  3 12:03:56 bbeng-laptop kernel: ath0: ieee80211_newstate: ASSOC ->
>>>RUN
>>>Aug  3 12:03:56 bbeng-laptop kernel: ath0: link state changed to UP
>>>Aug  3 12:03:56 bbeng-laptop kernel: ath0: [00:0d:93:e9:cf:d4] recv
>>>disassociated (reason 9)
>>>Aug  3 12:03:56 bbeng-laptop kernel: ath0: ieee80211_newstate: RUN ->
>>>ASSOC
>>>Aug  3 12:03:56 bbeng-laptop kernel: ath0: link state changed to DOWN
>>>Aug  3 12:03:56 bbeng-laptop kernel: ath0: [00:0d:93:e9:cf:d4] recv
>>>disassociated (reason 7)
>>>Aug  3 12:03:56 bbeng-laptop kernel: ath0: ieee80211_newstate: ASSOC ->
>>>ASSOC
>>>Aug  3 12:03:56 bbeng-laptop kernel: ath0: ieee80211_newstate: invalid
>>>transition
> 
> 
> What about this ASSOC -> ASSOC transition with wpa_supplicant?

Looks like I missed pulling in code from p4 to DTRT on the ASSOC->ASSOC 
transition; it should try to reassoc but currently does nothing.  That 
would explain the looping.

> 
> 
>>>Aug  3 12:03:56 bbeng-laptop kernel: ath0: [00:0d:93:e9:cf:d4] recv
>>>disassociated (reason 7)
>>>Aug  3 12:03:56 bbeng-laptop kernel: ath0: ieee80211_newstate: ASSOC ->
>>>ASSOC
>>>Aug  3 12:03:56 bbeng-laptop kernel: ath0: ieee80211_newstate: invalid
>>>transition
>>>Aug  3 12:03:56 bbeng-laptop kernel: ath0: [00:0d:93:e9:cf:d4] recv
>>>disassociated (reason 7)
>>>Aug  3 12:03:56 bbeng-laptop kernel: ath0: ieee80211_newstate: ASSOC ->
>>>ASSOC
>>>Aug  3 12:03:56 bbeng-laptop kernel: ath0: ieee80211_newstate: invalid
>>>transition
>>>Aug  3 12:03:56 bbeng-laptop kernel: ath0: [00:0d:93:e9:cf:d4] recv
>>>disassociated (reason 7)
>>>Aug  3 12:03:56 bbeng-laptop kernel: ath0: ieee80211_newstate: ASSOC ->
>>>ASSOC
>>>Aug  3 12:03:56 bbeng-laptop kernel: ath0: ieee80211_newstate: invalid
>>>transition
>>>Aug  3 12:03:56 bbeng-laptop kernel: ath0: [00:0d:93:e9:cf:d4] recv
>>>disassociated (reason 7)
>>>Aug  3 12:03:56 bbeng-laptop kernel: ath0: ieee80211_newstate: ASSOC ->
>>>ASSOC
>>>Aug  3 12:03:56 bbeng-laptop kernel: ath0: ieee80211_newstate: invalid
>>>transition
>>>Aug  3 12:03:56 bbeng-laptop kernel: ath0: [00:0d:93:e9:cf:d4] recv
>>>disassociated (reason 7)
>>>Aug  3 12:03:56 bbeng-laptop kernel: ath0: ieee80211_newstate: ASSOC ->
>>>ASSOC
>>>Aug  3 12:03:56 bbeng-laptop kernel: ath0: ieee80211_newstate: invalid
>>>transition
>>>Aug  3 12:03:56 bbeng-laptop kernel: ath0: [00:0d:93:e9:cf:d4] recv
>>>disassociated (reason 7)
>>>Aug  3 12:03:56 bbeng-laptop kernel: ath0: ieee80211_newstate: ASSOC ->
>>>ASSOC
>>>Aug  3 12:03:56 bbeng-laptop kernel: ath0: ieee80211_newstate: invalid
>>>transition
>>>Aug  3 12:03:56 bbeng-laptop kernel: ath0: [00:0d:93:e9:cf:d4] recv
>>>disassociated (reason 7)
>>>Aug  3 12:03:56 bbeng-laptop kernel: ath0: ieee80211_newstate: ASSOC ->
>>>ASSOC
>>>Aug  3 12:03:56 bbeng-laptop kernel: ath0: ieee80211_newstate: invalid
>>>transition
>>>Aug  3 12:03:56 bbeng-laptop kernel: ath0: [00:0d:93:e9:cf:d4] recv
>>>disassociated (reason 7)
>>>Aug  3 12:03:56 bbeng-laptop kernel: ath0: ieee80211_newstate: ASSOC ->
>>>ASSOC
>>>Aug  3 12:03:56 bbeng-laptop kernel: ath0: ieee80211_newstate: invalid
>>>transition
>>>Aug  3 12:03:56 bbeng-laptop kernel: ath0: ieee80211_newstate: INIT ->
>>>SCAN
>>>Aug  3 12:03:56 bbeng-laptop kernel: ath0: ieee80211_newstate: SCAN ->
>>>SCAN
>>>Aug  3 12:03:59 bbeng-laptop last message repeated 15 times
>>>Aug  3 12:03:59 bbeng-laptop kernel: ath0: ieee80211_newstate: SCAN ->
>>>INIT
>>>
>>>It continues scanning, but never associates again...
>>
>>The error responses from the ap seem to indicate dropped frames.  What 
>>does ifconfig ath0 list scan show for the rssi?  If possible you might 
>>try moving the ap to channel 6 or 11.
> 
> 
> bbeng-laptop# ifconfig ath0 list scan
> SSID            BSSID              CHAN RATE  S:N   INT CAPS
> test001          00:0d:93:e9:cf:d4    1   11M 30:0   100 EP  
> test001          00:0d:93:e9:bf:c1    1   11M 14:0   100 EP  
> 

So the ap that you're using has rssi 30 which is very strong (assuming I 
read the logs correctly above).

> 
>>>When I "wpa_cli term" wpa_supplicant, it leaves the card like this...
>>>
>>>ath0: flags=8802<BROADCAST,SIMPLEX,MULTICAST> mtu 1500
>>>        inet6 fe80::212:17ff:fe6e:fc18%ath0 prefixlen 64 scopeid 0x3 
>>>        inet 0.0.0.0 netmask 0xff000000 broadcast 255.255.255.255
>>>        ether 00:12:17:6e:fc:18
>>>        media: IEEE 802.11 Wireless Ethernet autoselect (autoselect)
>>>        status: no carrier
>>>        ssid ""
>>>        authmode OPEN privacy OFF deftxkey 1 txpowmax 34 roaming DEVICE
>>>        bintval 100
>>>
>>>NOTE: roaming is set to DEVICE
>>
>>That's just wpa_supplicant; it should be fixed to restore the previous 
>>settings instead of blindly forcing a fixed value on cleanup.
>>
>>
>>>bbeng-laptop# ifconfig ath0 ssid "test001" authmode shared wepmode on
>>>weptxkey 1 wepkey "xxxxx"
>>>
>>>Aug  3 13:50:20 bbeng-laptop kernel: ath0: ieee80211_newstate: INIT ->
>>>SCAN
>>>Aug  3 13:50:20 bbeng-laptop kernel: ath0: ieee80211_newstate: SCAN ->
>>>SCAN
>>>Aug  3 13:50:51 bbeng-laptop last message repeated 151 times
>>>Aug  3 13:52:52 bbeng-laptop last message repeated 593 times
>>>
>>>card not seeing probe responses... later test same state below...
>>>
>>>Aug  3 15:29:00 bbeng-laptop kernel: ath0: ieee80211_newstate: INIT ->
>>>SCAN
>>>Aug  3 15:29:00 bbeng-laptop kernel: ath0: ieee80211_newstate: SCAN ->
>>>SCAN
>>>Aug  3 15:29:06 bbeng-laptop last message repeated 28 times
>>>Aug  3 15:29:06 bbeng-laptop kernel: ath0: ieee80211_newstate: SCAN ->
>>>AUTH
>>>Aug  3 15:29:06 bbeng-laptop kernel: ath0: ieee80211_newstate: AUTH ->
>>>ASSOC
>>>Aug  3 15:29:06 bbeng-laptop kernel: ath0: [00:0d:93:e9:cf:d4] assoc
>>>success: long preamble, long slot time
>>>Aug  3 15:29:06 bbeng-laptop kernel: ath0: ieee80211_newstate: ASSOC ->
>>>RUN
>>>Aug  3 15:29:06 bbeng-laptop kernel: ath0: link state changed to UP
>>>Aug  3 15:29:06 bbeng-laptop kernel: ath0: [00:0d:93:e9:cf:d4] recv
>>>disassociated (reason 9)
>>>Aug  3 15:29:06 bbeng-laptop kernel: ath0: ieee80211_newstate: RUN ->
>>>ASSOC
>>>Aug  3 15:29:06 bbeng-laptop kernel: ath0: link state changed to DOWN
>>>
>>>ath0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
>>>        inet6 fe80::212:17ff:fe6e:fc18%ath0 prefixlen 64 scopeid 0x3 
>>>        inet 0.0.0.0 netmask 0xff000000 broadcast 255.255.255.255
>>>        ether 00:12:17:6e:fc:18
>>>        media: IEEE 802.11 Wireless Ethernet autoselect (DS/1Mbps)
>>>        status: no carrier
>>>        ssid test001 channel 1
>>>        authmode SHARED privacy ON deftxkey 1 wepkey 1:104-bit txpowmax
>>>46
>>>        protmode CTS roaming DEVICE bintval 100
>>>
>>>lights on card blinking like it is associated and no further scanning.
>>
>>The card was left in ASSOC state so the lights reflect that.  Because 
>>roaming was set to device nothing progressed.  But the basic problem is 
>>still you don't appear to be getting frames through to the ap.
>>
>>
>>>bbeng-laptop# ifconfig ath0 roaming auto
>>>
>>>Aug  3 14:07:36 bbeng-laptop kernel: ath0: ieee80211_newstate: INIT ->
>>>SCAN
>>>Aug  3 14:07:36 bbeng-laptop kernel: ath0: ieee80211_newstate: SCAN ->
>>>SCAN
>>>Aug  3 14:07:42 bbeng-laptop last message repeated 28 times
>>>Aug  3 14:07:42 bbeng-laptop kernel: ath0: ieee80211_newstate: SCAN ->
>>>AUTH
>>>Aug  3 14:07:42 bbeng-laptop kernel: ath0: ieee80211_newstate: AUTH ->
>>>ASSOC
>>>Aug  3 14:07:42 bbeng-laptop kernel: ath0: [00:0d:93:e9:cf:d4] assoc
>>>success: long preamble, long slot time
>>>Aug  3 14:07:42 bbeng-laptop kernel: ath0: ieee80211_newstate: ASSOC ->
>>>RUN
>>>Aug  3 14:07:42 bbeng-laptop kernel: ath0: link state changed to UP
>>>Aug  3 14:07:42 bbeng-laptop kernel: ath0: [00:0d:93:e9:cf:d4] recv
>>>disassociated (reason 9)
>>>Aug  3 14:07:42 bbeng-laptop kernel: ath0: ieee80211_newstate: RUN ->
>>>ASSOC
>>>Aug  3 14:07:42 bbeng-laptop kernel: ath0: link state changed to DOWN
>>>Aug  3 14:07:42 bbeng-laptop kernel: ath0: [00:0d:93:e9:cf:d4] assoc
>>>success: long preamble, long slot time
>>>Aug  3 14:07:42 bbeng-laptop kernel: ath0: ieee80211_newstate: ASSOC ->
>>>RUN
>>>Aug  3 14:07:42 bbeng-laptop kernel: ath0: link state changed to UP
>>>Aug  3 14:07:42 bbeng-laptop kernel: ath0: [00:0d:93:e9:cf:d4] recv
>>>disassociated (reason 9)
>>>Aug  3 14:07:42 bbeng-laptop kernel: ath0: ieee80211_newstate: RUN ->
>>>ASSOC
>>>Aug  3 14:07:42 bbeng-laptop kernel: ath0: link state changed to DOWN
>>>Aug  3 14:07:42 bbeng-laptop kernel: ath0: [00:0d:93:e9:cf:d4] assoc
>>>success: long preamble, long slot time
>>>Aug  3 14:07:42 bbeng-laptop kernel: ath0: ieee80211_newstate: ASSOC ->
>>>RUN
>>>Aug  3 14:07:42 bbeng-laptop kernel: ath0: link state changed to UP
>>>
>>>It's all good now... 
>>>
>>>ath0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
>>>        inet6 fe80::212:17ff:fe6e:fc18%ath0 prefixlen 64 scopeid 0x3 
>>>        inet 0.0.0.0 netmask 0xff000000 broadcast 255.255.255.255
>>>        ether 00:12:17:6e:fc:18
>>>        media: IEEE 802.11 Wireless Ethernet autoselect (DS/1Mbps)
>>>        status: associated
>>>        ssid test001 channel 1 bssid 00:0d:93:e9:cf:d4
>>>        authmode SHARED privacy ON deftxkey 1 wepkey 1:104-bit txpowmax
>>>46
>>>        protmode CTS bintval 100
>>>
>>>I either have or can provide tcpdumps of each specific case if that
>>>helps more, but I figure this message is long enough already.
>>
>>Better would be a 3rd sta sniffing traffic and also recording rssi 
>>(collect -y IEEE802_11_RADIO).  Your problem seems unrelated to wep or 
>>roaming mode; you appear to just not get frames through reliably.  When 
>>this happens I look at stats on the sta and the ap.  athstats can be 
>>useful here; something like
>>
>>athstats 1
> 
> 
> athstats 1 while running ping -f

Er, well I meant to collect stats during the time that you looked to be 
losing packets; not after you have an association setup.  And using ping 
-f isn't going to answer any questions; I wanted to see what was going 
on with the exchange of management frames.  But thanks...

> 
> 19927 packets transmitted, 19926 packets received, 0% packet loss
> round-trip min/avg/max/stddev = 1.259/1.613/9.182/0.266 ms
> 
>    input   output altrate   short    long xretry crcerr crypt  phyerr
> rssi rate
>     7047     7020       1       0      53      0    348     0       0
> 33  11M
	<...snip...>
> 
>>will give you a rolling display of stats together with current rssi. 
>>Sometimes you can see obvious problems like high retransmit rates or big 
>>bursts of noise.  If the frame count on the ap goes up as you transmit 
>>then it's likely you're not hearing the ACK's coming back.  If the ap 
>>doesn't hear your frames (as appears to be happening) then it can either 
>>be noise, misconfig (e.g. 11g parameters like protection wrong in a 
>>mixed b/g bss), or possibly low tx power by the sta.  The latter would 
>>appear as low rssi on recv'd frames at the ap and/or a 3rd sta.
>>
>>I don't see an indication of what you're using for an ap.  Also remove 
>>everything like crypto and shared key auth for testing--get 
>>communication working before adding more variables.  Figuring out 
>>communication problems can be hard w/o a good test environment and tools.
> 
> 
> It is an apple airport extreme, unfortunately I don't have access to
> it's config...
> 
> This situation is 100 percent predictable, with wpa_supplicant produces
> the first result, every time, static w/ roaming DEVICE produces the same
> state every time as well, and static w/ roaming auto works.

	<...snip...>

The wpa_supplicant issue is just a bug that I can fix; it's excercising 
the internal state machine differently than when things happen entirely 
in the kernel.  I will also fix wpa_supplicant to restore the roaming 
state.  Thank you.

	Sam


More information about the freebsd-current mailing list