Re: WEP does not work?

Pawel Worach wrote:
> Sam Leffler wrote:
> 
>> Pawel Worach wrote:
>>
>>> Sam Leffler wrote:
>>>
>>>> I'll try to look tomorrow.  I have a patch for fixing wep with ndis 
>>>> that I need to review and this is probably the same thing.
>>>
>>>
>>>
>>>
>>> I have the same problem on a ThinkPad T41.
>>
>>
>>
>> What problem?  Are you saying that wep does not work with the ath 
>> driver?  I communicated with a couple of people that have setup static 
>> key'd wep fine so I'm not sure what to think.  I've still had no time 
>> to try it myself (it was tested a while back but not immediatel before 
>> the commit).  One thing I found from talking to folks is I did not 
>> make it clear you must have the wlan_wep module configured in the 
>> kernel or available for loading by the wlan layer when you configure a 
>> wep key. But if that happens then ifconfig will complain; things won't 
>> silently fail.
> 
> I use all of the wlan and ath driver stuff as modules.
> if_ath.ko, ath_hal.ko, wlan.ko, ath_rate.ko and wlan_wep.ko
> 
> Both makefiles for sys/modules/ath_rate_amrr and sys/modules/ath_rate_onoe
> build the same module "KMOD=ath_rate" is that correct? The module installed
> by 'make installkernel' seems to be the "onoe" one (last in 
> modules/Makefile).

That is correct.  I know of no way to describe a module dependency s.t. 
module a depends on b || c so I named the different rate control 
algorithm modules the same so if_ath could depend on a fixed name.

> 
>> "breaks" how?  Please provide the exact steps you take to demonstrate 
>> the problem.
> 
> 
> I enabled 802.11 crypto debug and did the procedure again.
> 
> # ifconfig ath0 wepmode on wepkey 1:0xXXXX78e6XXXXdbe2XXXX0127XX
> # ifconfig ath0
> ath0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
>         inet 192.168.1.200 netmask 0xffffff00 broadcast 192.168.1.255
>         inet6 fe80::205:4eff:fe4b:7613%ath0 prefixlen 64 scopeid 0x2
>         ether 00:05:4e:4b:76:13
>         media: IEEE 802.11 Wireless Ethernet autoselect <adhoc> 
> (autoselect <adhoc>)
>         status: associated
>         ssid cookie channel 7 bssid fa:02:57:01:13:00
>         authmode OPEN privacy ON
>         wepkey 1:104-bit <XXXX78e6XXXXdbe2XXXX0127XX>
>         txpowmax 34 protmode CTS wme bintval 100
> 
> (just to demonstrate my last paragraph, the disappearing wepkey)
> # ifconfig ath0 wepmode on
> # ifconfig ath0
> ath0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
>         inet 192.168.1.200 netmask 0xffffff00 broadcast 192.168.1.255
>         inet6 fe80::205:4eff:fe4b:7613%ath0 prefixlen 64 scopeid 0x2
>         ether 00:05:4e:4b:76:13
>         media: IEEE 802.11 Wireless Ethernet autoselect <adhoc> 
> (autoselect <adhoc>)
>         status: no carrier
>         ssid cookie
>         authmode OPEN privacy ON txpowmax 0 wme
> 
> Now it's gone. So wepmode and wepkeys need to be configured in one shot?
> After this kernel says: "[00:40:96:42:0d:9c] key (id 0) is invalid"

Thank you; I'll check it out.

> 
> Anyway, back to the correctly configured wepkey.
> 
> On sending traffic i see "[00:40:96:42:0d:9c] no default transmit key"
> so i figured that the "deftxkey" which is "UNDEF" needs to be set to
> "1" (that parameter is only displayed with 'ifconfig -v') but it seems
> like that parameter is not settable. 'ifconfig ath0 deftxkey 1' does not 
> work
> it just sits there for some time then says "ifconfig: deftxkey: bad value
> " taking deftxkey as an inet address?

ifconfig w/o -v is supposed to display only info that is "interesting". 
  Guess the tx key should always be displayed when privacy is on.  I'll 
fix that.

I'll check the other issue too; thanks.

> 
> 'ifconfig ath0' still looks the same after this.
> # ifconfig ath0
> ath0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
>         inet 192.168.1.200 netmask 0xffffff00 broadcast 192.168.1.255
>         inet6 fe80::205:4eff:fe4b:7613%ath0 prefixlen 64 scopeid 0x2
>         ether 00:05:4e:4b:76:13
>         media: IEEE 802.11 Wireless Ethernet autoselect <adhoc> 
> (autoselect <adhoc>)
>         status: associated
>         ssid cookie channel 7 bssid fa:02:57:01:13:00
>         authmode OPEN privacy ON
>         wepkey 1:104-bit <XXXX78e6XXXXdbe2XXXX0127XX>
>         txpowmax 34 protmode CTS wme bintval 100
> 
>>> ath0: device timeout
>>> ath0: device timeout
>>> ath0: device timeout
>>>
>>
>> You should not get these.  Please go to /usr/src/tools/tools/ath and 
>> build athstats.  Run it w/o arguments and provide the output.  Please 
>> identify what your configuration was when these occurred (e.g. adhoc 
>> mode w/ wep?).
>>
>>
> 
> After running for some time without wep now I noticed that I get the
> "device timeout" messages quite often durning normal usage. So with or
> without wep seems unrelated to the timeout events, I am only able to
> test this in ad-hoc mode for now since the AP requires wep.

adhoc mode is lightly tested but I can't imagine how it should be 
related to the resets.  Hardware resets typically happen because of a 
dma error.  You're generating beacons in adhoc mode so there might be 
more dma traffic but it shouldn't be significant.

> 
> # ./athstats
> 761 watchdog timeouts
> 3 hardware error interrupts
> 780 tx management frames
> 17219 tx frames discarded prior to association
> 131 tx failed 'cuz too many retries
> 2202 long on-chip tx retries
> 246 tx frames with no ack marked
> 10 tx frames with an alternate rate
> 80209 rx failed 'cuz of bad CRC
> 194932 rx failed 'cuz of PHY err
>     26040 OFDM timing
>     168736 CCK timing
>     156 CCK restart
> 778 beacons transmitted
> 2999 periodic calibrations
> 90068 rate control checks
> 1 rate control raised xmit rate
> 35 rate control dropped xmit rate
> rssi of last ack: 56
> 1298 switched default/rx antenna
> Antenna profile:
> [1] tx    20937 rx   103154
> [2] tx    16815 rx   398531

Something is very wrong that you're getting all the watchdog timeouts. 
Also there are many frames discarded that don't make sense.  The output 
from 80211stats might be useful.  OTOH, as I said, adhoc mode for ath is 
lightly tested so may just have a problem; it's very low priority and 
likely won't get fixed real soon.

> 
> Is the result of the second command expected?
> 
> # ./80211debug +crypto
> net.wlan.0.debug: 0x0 => 0x10000000<crypto>
> # ./athdebug +crypto
> dev.ath.0.debug: 0x0
> # sysctl dev.ath.0.debug
> dev.ath.0.debug: 0
> 

Sorry, athdebug +keycache is what you want.  Supplying -? as an arg to 
either athdebug or 80211debug will display the possible debug bits.

	Sam