--dUQzTuC3g77BtMOt
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Sun, Oct 02, 2005 at 12:07:59PM -0400, Greg Troxel wrote:
> Sam Leffler <sam@errno.com> writes:
>=20
> > 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.
>=20
> This matches my understanding; I just wasn't confident I had it
> right.  It also fits with my patch helping.

It fits with my observations, too, though not with the conclusions I
had been drawing from these observations.

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.

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.

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.

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.

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.

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? 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.

> > 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.
>=20
> 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.

> This may not save much more power than 'full sleep' and thus not be
> justifiable from a power point of view, but it's the way (almost?)
> every other device is.  The driver already writes a bunch of things on
> power up, and writing key bits seems easy enough.  From this I have
> two thoughts/questions:
>=20
>  Do wep keys on a cardbus ath survive suspend/resume on FreeBSD?  Does
>  the card somehow stay in full sleep during suspend, instead of being
>  unpowered?
>=20
>  It seems reasonable to allow drivers to power off cards that are not
>  UP.  I wonder if it makes sense to have a call in net80211 that a
>  driver can invoke to say "push hardware settings to me again" that
>  invokes the wep key write methods and perhaps other things.  This may
>  be the only case, but it felt like a bit of an abstraction violation
>  to be iterating over the key array.

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.

--
Dan.

--dUQzTuC3g77BtMOt
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (NetBSD)

iD8DBQFDQG+mEAVxvV4N66cRAowCAKDUiTL6XbE62OKkFM501F6OdGZNxgCghV8e
NhHe+T5tbpArD4KUfus70us=
=f1bH
-----END PGP SIGNATURE-----

--dUQzTuC3g77BtMOt--