Subject: Re: ath driver and wep
To: Steven M. Bellovin <smb@cs.columbia.edu>
From: Sam Leffler <sam@errno.com>
List: current-users
Date: 10/01/2005 20:03:01
Steven M. Bellovin wrote:
> In message <433F1BBA.402@errno.com>, Sam Leffler writes:
>
>>Steven M. Bellovin wrote:
>>
>>>In message <433EF58D.6090609@free.fr>, Vincent writes:
>>>
>>>
>>>>Greg Troxel a écrit :
>>>>
>>>>
>>>>
>>>>>I made the following change (locally, not committed) yet to
>>>>>sys/dev/ic/ath.c to write wep keys to the hardware on power up. This
>>>>>intends to fix the problem of wep keys being set while the power is
>>>>>off (ifconfig nwkey before ifconfig up), or lost during ifconfig
>>>>>down/up. I tested on one machine and an ifconfig down/up resulted in
>>>>>a working configuration where previously it did not (and I received a
>>>>>report from someone else who had the same problem).
>>>>
>>>>I tested it, not for long, but I was led to this:
>>>>
>>>>It is *definitely* better. but I think it does not solve completely the
>>>>problem, as I found my PC disconnected after a while. And it surely does
>>>>not solve the autodeconnection bug (the card drops the link for some
>>>>unknown reason).
>>>>
>>>
>>>I've frequently had that latter problem, with both a PCMCIA wi0 card
>>>and a built-in ath0, for several years. It seems to be related to
>>>traffic levels, since I have much more trouble in busy wireless
>>>environments.
>>
>>I'm coming in late on this but regarding ath, if you're seeing frequent
>>beacon misses then I have a workaround for "phantom bmisses" that may be
>>helpful. It's still being tested; I'll try to pass it along when it's
>>in a form suitable for netbsd (it was developed for freebsd).
>
>
> I'd be delighted to try it. I have a trip coming up in about two weeks
> to a place where I've had trouble getting ath0 to work at all of late
> (the Amtrak Club Acela in Washington, DC).
Is it because of bsmiss? Use athstats or whatever it is on netbsd
(still learning my way around) to find out. Alternatively you can watch
beacon miss happen via a transition in the net80211 state machine by
enabling the state debug bit in the net80211 layer. I've got a useful
program called 80211debug (aka wlandebug) that lets you manipulate
things symbolically; e.g.
80211debug will
turns on state debugging (to the console) for ath0 (the default device).
I haven't located the tool in the netbsd code base (yet).
Understand I'm just getting up to speed with netbsd so I may act a bit
disoriented.
>
>>Regarding the wep key and powering the card down; when the interface is
>>marked down the chip should be in full sleep with the radio turned off.
>> In this state it should draw very little power. If folks are really
>>seeing power draw in this state then I need more info; especially the
>>part id(s).
>>
>
> That wasn't the issue. Per the first paragraph above, someone had
> trouble with WEP because of powerdown; someone else suggested not
> powering the card down at all. Others think that that's a bad idea.
I believe I understand the issue; I've been corresponding with David
Young. The net80211 layer assumes that when it calls the driver to set
a key value that value will be preserved. The ath driver calls to the
hal to write the key cache but on netbsd this apparently fails for
cardbus cards because the socket power is off (I verified that it works
for minipci cards). All other systems I'm familiar with do not do this.
My response was that it wasn't clear for Atheros parts that much was
to be gained by powering off the socket since the card in full sleep w/
the phy/radio turned off should draw very little power (the default
state the card is set in on calling ath_stop; e.g. when marking the
interface down). If in fact cards are drawing noticeable power then
something is wrong and we should fix that. If folks still feel it's
critical to power off the socket then you'll need a workaround in the
driver to restore the key cache contents on power up--which is what Greg
has done.
Sam