Subject: Re: ath driver and wep
To: Daniel Carosone <email@example.com>
From: Greg Troxel <firstname.lastname@example.org>
Date: 10/02/2005 20:34:21
Daniel Carosone <email@example.com> writes:
> It fits with my observations, too, though not with the conclusions I
> had been drawing from these observations.
After reading your note it seems we agree at least mostly.
> My most common use of ath is a cardbus AR5004X device on a 40-bit wep
> network, and ath is configured all on one line
> # ifconfig ath0 <addr/mask> nwid foo nwkey bar up
> This usually works fine.
Assigning an address brings the interface up, so I'd expect this to work.
> On a 128-bit network, I tried:
> # ifconfig ath0 nwid baz nwkey bonk up
> # dhclient ath0
> This had previously worked fine, before the date known to introduce
> this problem, but now dhclient doesn't get a lease. tcpdump showed
> garbage LLC packets, as usually seen in monitor mode for a wep network
> without the correct key.
So this matches what I see.
> On suggestion from greg via dyoung, I tried instead:
> # ifconfig ath0 nwid baz up
> # ifconfig ath0 nwkey bonk
> # dhclient ath0
> and it worked fine again. I had been asuuming this was a problem with
> 40- vs 128- bit keys (yes, I know common terminology counts those
> lengths differently). This discussion caused me to think again and
> look more closely at other details of the behaviour.
So this fits also my theory: setting key after power is on works.
> Now, maybe setting the address first is enough to cause the interface
> to be up when the 40-bit key is set. I'll try to test that case soon
> by leaving the address off the first line.
That would be good to check; I am quite sure setting the address
brings the interface up. Note that normal usage of ifconfig.foo0 is
to have address/mask and not 'up'.
> But there's one more detail. I have a known problem with one
> particular AP that locks up and needs to be rebooted; this is the AP
> on the 40-bit network. It used to be the case that I could reboot the
> AP, and ath would re-connect to it automatically; that isn't happening
> anymore as of my most recent -current for some (other) reason.
I wonder if there is some unrelated issue with the state machine that
requires an ath reset to associate again.
> However, after bouncing the ap, if I do
> # ifconfig ath0 down up
> it will reconnect, retaining the WEP keys from before. If our theory
> was accurate, wouldn't the card lose the key when the socket was
Yes, it would lose,
> Perhaps it doesn't power cycle the card in this case, or
> it's fast enough not to affect it? I tried testing this case:
> # ifconfig ath0 down
> (wait a few secs)
> # ifconfig ath0 up
> and lo, I couldn't communicate on the network until I reconfigured the
> key, even for 40-bit WEP. Even though ifconfig reported the key
> correctly in the upper layers, it seems the device didn't have it.
So the theory needs a slight modification to require being off long
enough to lose keys.
> > My understanding of cardbus on NetBSD is that normal behavior for
> > network devices is to power off the slot when the interface is down.
> Not just network devices, all pcmcia/cardbus cards.
So does a serial port get powered off when not open (and not WOPEN)?
What about a device with serial and ethernet? If so, that's neat.
> These power hooks are needed for all devices, as you note, to save and
> restore any significant device state for the suspend/resume case,
> especially with acpi (though not all drivers yet implement them). I'm
> not sure if the cardbus code calls these hooks when toggling power to
> the card slot, if not it seems it should, and that we've discovered
> something that needs to go into ath's powerhook.
One can either save/restore, or keep all state in kernel and write on
power on. It's the code called at power on time that I patched to
rewrite the keys.
Greg Troxel <firstname.lastname@example.org>