Re: ath + wep issue

From: Robert C. Noland III <rnoland_at_2hip.net>
Date: Thu, 04 Aug 2005 18:26:03 -0400
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