identify sockaddr_dl abuse that remains in the kernel, especially
the potential for overwriting memory past the end of a sockaddr_dl
with, e.g., memcpy(LLADDR(), ...).
matching (and handling) a whole device and those which match an
interface only. This will allow to enforce some rules, eg that
the former don't use interface information for matching or that the
latter don't modify global device state.
The previous way left too much freedom do the drivers which led to
inconsistencies and abuse.
For now, I've not changed locators and submatch rules, this will
happen later.
There should not be any change in behaviour, except in the case of
some drivers which did behave inconsistently:
if_atu, if_axe, uep: matched the configured device in the interface
stage, but did configuration again. I've converted them to match
in the device stage.
ustir, utoppy: matched in the interface stage, but only against
vendor/device information, and used any configuration/interface
without checking. Changed to match in device stage, and added
some simple code to configure and use the first interface.
If you have one of those devices, please test!
one for tasks of the host controllers. This is needed for drivers like
ural(4) that want to do synchronous USB transfers from the task handler.
Before the split timeouts could not be handled correctly as the task
thread was still blocked. From FreeBSD.
-fill in the 802.11 "duration" before
-use the intended channel (still not perfect because this is not
necessarily the hardware setting, but better than before)
while this doesn't make the driver work for me, it kills some
red herrings which I've just wasted time for
- remove driver-private key allocators; use the default one instead
so wpa keys are handled properly (if_ral.c, if_ural.c rev 1.9)
- remove local mods that snuck into rev 1.6 (if_ral.c rev 1.10)
back out my change to ieee80211_crypto_encap that made it free its
mbuf argument on error. I had thought it was a bug. It was not.
It's the drivers that are broken. Make an(4), atw(4), ipw(4),
iwi(4), ral(4), rtw(4), ural(4), and wi(4) free the mbuf when
ieee80211_crypto_encap returns NULL. Also, return ath(4) to the
way it was---i.e., free the mbuf.
Thanks to Sam Leffler to pointing out my mistake.
Damien Bergamini, ported and submitted by FUKAUMI Naoki per PR kern/30449
I've modified the USB "ural" driver for recent changes to the NetBSD
ieee80211 framework, possibly not completely, but with an ASUS wireless
adapter I'm getting some signs of life.
Didn't care about pci/cardbus for now, hopefully someone with hardware
will do it.
