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? > > 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 > > > > 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 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 592 592 0 0 5 0 0 0 0 33 11M 601 601 0 0 0 0 0 0 0 33 11M 598 598 0 0 0 0 0 0 0 32 11M 601 601 0 0 0 0 0 0 0 33 11M 598 598 0 0 1 0 0 0 0 32 11M 600 600 0 0 2 0 0 0 0 33 11M 593 593 0 0 1 0 0 0 0 33 11M 597 597 0 0 1 0 0 0 0 33 11M 596 595 0 0 2 0 0 0 0 33 11M 598 599 0 0 3 0 0 0 0 33 11M 596 595 2 0 11 0 0 0 0 33 11M 601 601 0 0 0 0 0 0 0 32 11M 597 598 0 0 3 0 0 0 0 32 11M 596 595 0 0 5 0 0 0 0 33 11M 596 596 1 0 5 0 0 0 0 33 11M 600 600 0 0 4 0 1 0 0 33 11M 595 595 0 0 0 0 0 0 0 33 11M 593 593 0 0 0 0 1 0 0 32 11M 599 599 0 0 1 0 0 0 0 33 11M 593 593 0 0 7 0 0 0 0 31 11M > 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. robert. > > > > Now, off to debug the other issues with the wi card, sigh... > > > > robert. > > > > On Tue, 2005-08-02 at 19:54 -0700, Sam Leffler wrote: > > > >>Robert C. Noland III wrote: > >> > >>>I am having an issue with static wep on my ath card, -current sources as > >>>of this morning EST. It is a Linksys WPC55ag card. I also have an old > >>>Netgear wi card that works shown at the bottom. > >>> > >>>ath_hal: 0.9.14.9 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413) > >>>... > >>>ath0: <Atheros 5212> mem 0xf4010000-0xf401ffff irq 11 at device 0.0 on > >>>cardbus0 > >>>ath0: Ethernet address: 00:12:17:6e:fc:18 > >>>ath0: mac 5.9 phy 4.3 radio 3.6 > >>> > >>>laptop# ifconfig ath0 ssid "test001" wepmode on weptxkey 1 wepkey "xxxx" > >>>laptop# ifconfig ath0 up > >>> > >>>Tue Aug 2 17:27:19 RTM_IFINFO: if# 3, link: down, > >>>flags:<UP,BROADCAST,SIMPLEX,MULTICAST> > >>>Tue Aug 2 17:27:25 RTM_IEEE80211: scan complete > >>>Tue Aug 2 17:27:25 RTM_IEEE80211: associate with 00:0d:93:e9:cf:d4 > >>>Tue Aug 2 17:27:25 RTM_IFINFO: if# 3, link: up, > >>>flags:<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> > >>>Tue Aug 2 17:27:25 RTM_IEEE80211: disassociate > >>>Tue Aug 2 17:27:25 RTM_IFINFO: if# 3, link: down, > >>>flags:<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> > >> > >>You associated with the ap then fell off either because the ap dropped > >>you or your station initiated it. The easiest way to see which is to > >>enabling debugging; I prefer to use 80211debug from tools/tools/ath; e.g. > >> > >>80211debug state+assoc > >> > >>or probably > >> > >>ifconfig ath0 debug > >> > >>will give you enough info. The output of 80211stats should also tell > >>you what happened. > >> > >> > >>>The disassociate message concerns me, but it should work... > >>> > >>>ath0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500 > >>> inet6 fe80::212:17ff:fe6e:fc18%ath0 prefixlen 64 scopeid 0x3 > >>> ether 00:12:17:6e:fc:18 > >>> media: IEEE 802.11 Wireless Ethernet autoselect (DS/1Mbps) > >>> status: no carrier > >>> ssid test001 channel 1 > >>> authmode OPEN privacy ON deftxkey 1 wepkey 1:104-bit txpowmax 46 > >>> protmode CTS roaming DEVICE bintval 100 > >>> > >>>At this point, the card is no longer scanning and the lights on the card > >>>continue blinking as if it is associated (slowly in sync, as opposed to > >>>alternately blinking like mad when it is scanning) yet status shows no > >>>carrier. dhclient will not work when the interface is in this state. > >>>It seems to just broadcast and eventually die. > >>> > >>>wi0: <NETGEAR MA401 Wireless PC Card> at port 0xe000-0xe03f irq 11 > >>>function 0 config 1 on pccard0 > >>>wi0: using RF:PRISM2 MAC:HFA3841 CARD:HWB3163-SST-flash > >>>wi0: Intersil Firmware: Primary (0.3.0), Station (1.3.4) > >>>wi0: Ethernet address: 00:30:ab:07:e4:7b > >>> > >>>laptop# ifconfig wi0 ssid "test001" wepmode on weptxkey 1 wepkey "xxxx" > >>>laptop# ifconfig wi0 up > >>> > >>>Tue Aug 2 17:35:57 RTM_IFANNOUNCE: if# 3, what: arrival > >>>Tue Aug 2 17:39:06 RTM_IFINFO: if# 3, link: unknown, > >>>flags:<UP,BROADCAST,SIMPLEX,MULTICAST> > >>>Tue Aug 2 17:39:06 RTM_IEEE80211: disassociate > >>>Tue Aug 2 17:39:06 RTM_IFINFO: if# 3, link: down, > >>>flags:<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> > >>> > >>>again with the disassociate message. This seems to force wpa_supplicant > >>>to start scanning again, so I can't currently use wpa_supplicant on this > >>>network. Actually, wpa_supplicant doesn't ever seem to be able to > >>>associate on the wi card, but static configuration works. > >>>wpa_supplicant on the ath card seems to associate, then catches the > >>>disassociate and starts scanning again. lather, rinse, repeat... > >>> > >>>wi0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500 > >>> inet6 fe80::230:abff:fe07:e47b%wi0 prefixlen 64 scopeid 0x3 > >>> ether 00:30:ab:07:e4:7b > >>> media: IEEE 802.11 Wireless Ethernet autoselect (DS/11Mbps) > >>> status: associated > >>> ssid test001 channel 1 bssid 00:0d:93:e9:cf:d4 > >>> stationname "FreeBSD WaveLAN/IEEE node" > >>> authmode OPEN privacy MIXED deftxkey 1 wepkey 1:104-bit txpowmax > >>>100 > >>> bintval 100 > >>> > >>>dhclient does work here, and then I can start the vpn and roam about the > >>>office... > >> > >>I've been testing ath w/ static key wep today and seen no problems. > >>Please get some more info. > >> > >> Sam > >>_______________________________________________ > >>freebsd-current_at_freebsd.org mailing list > >>http://lists.freebsd.org/mailman/listinfo/freebsd-current > >>To unsubscribe, send any mail to "freebsd-current-unsubscribe_at_freebsd.org" > > > > > > _______________________________________________ > > freebsd-current_at_freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-current > > To unsubscribe, send any mail to "freebsd-current-unsubscribe_at_freebsd.org" > > > > _______________________________________________ > freebsd-current_at_freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe_at_freebsd.org"Received on Thu Aug 04 2005 - 20:28:38 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:40 UTC