Daniel Carosone <dan@geek.com.au> 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
> power-cycled?

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 <gdt@ir.bbn.com>