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. SamReceived on Fri Aug 05 2005 - 14:03:11 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:40 UTC