my 802.11 work

Brian F. Feldman green at
Thu Nov 6 08:29:55 PST 2003

Sam Leffler <sam at> wrote:
> On Wednesday 05 November 2003 08:22 pm, Brian Fundakowski Feldman wrote:
> > For anyone who may be interested in any of the things I've mentioned so far
> > for net80211 and the 802.11 hardware drivers, I've got a running diff with
> > everything I've found important so far.  Missing are changes to further
> > reduce gratuitous resetting in wi(4) and to reduce that problem at all in
> > ath(4).  Please check out:
> >

There's no way to do the MTAG_ABI_BPF/BPF_TAG_LINK_UNENCRYPTED trick without 
violating some sort of layering.  I decided that since it's arguably an 
interface/link layer operation, bpf(4) would be the most appropriate place 
to put it.  Without it, there's no way to get FreeBSD the functionality to 
do cleartext authentication on an encrypted link.  This means no FreeBSD 
802.1x authenticators, and not-very-good 802.1x supplicants.

Getting rid of the "WEP mode" flags is the obvious step to take when adding 
another wep mode, hence ic_wep_mode.  This simplifies a good deal of code, 
because it lets you make the decisions "WEP mode on?" "WEP mode supported?" 
"WEP mode not on?" with only a single comparison.  Another enum in the 
ieee80211com shouldn't hurt anything.

"Hybrid" WEP mode is just as important as MTAG_ABI_BPF/BPF_TAG_LINK_UNENCRYPTED
to the goal of supporting 802.1x.  Of course, it could simply be collapsed 
into "on" mode if it's desired to return unencrypted packets to the userland 
when they're not requested, but I don't feel that's very secure.  Also, 
there's a performance hit for not setting EXCLUDE_UNENCRYPTED on wi(4) 
hardware I'm sure.

ENETRESET is way too simplistic.  I tried to work around one aspect of that
with the IEEE80211_F_NORESETNODE flag, but it's not enough.  ENETRESET is 
evilly large-grained.  My ath(4) shouldn't be disassociating, scanning all 
the channels, and reassociating just because I change a WEP key.  Changing 
from a WEP unsupported to WEP supported mode, yes.  There's so many of these 
flags that shouldn't be resetting the card, but at least this is enough that 
wi(4) can act as an 802.1x authenticator.

The timeout code for hostap nodes is wrong.  There's no consideration to 
whether the the node is actually still around or not.  There's no reason to 
time out a node that's still around (accepts a zero-length DATA packet and 
ACKs it, resulting in a local TX complete interrupt if we ask for it), and 
there's no reason to keep a node around just because we tried to send a 
packet to it.  If the packet actually transmitted successfully, then that's 
good enough, though.  A received packed is also fine for marking the node 

The routine which sent MGMT packets only before I've trivially converted to 
be able to send any kind.  This means the kernel can take upon itself in the 
hostap code to probe for an inactive node, as mentioned above.

IEEE80211_IOC_BSSID should exist.  There's tons and tons of features common 
to all 802.11 cards that aren't reflected by SIOCG80211/SIOCS80211, so the 
API should be created where it doesn't exist already.  IEEE80211_IOC_APNODEFLAGS
is useful for determining if a node exists in a portable (not like wicontrol 
-l) way, for hostap.  Obviously, it's also useful for toggling the 
because the administrator or adminstration software for the hostap should be
able to delete clients at will.

The extra hostap+authorization mode I called IFM_IEEE80211_HOSTAP | IFM_FLAG0
just because it's easy.  Potentially there would be a hostap management
API; if this existed, it would be a better place to store this option.

IEEE80211_NODE_FLAG_AUTHORIZED is useful as an extra layer of security that 
the administrator is in charge of, preventing or allowing specific nodes 
from utilizing the network unrelated to WEP-based authentication as 
supported in the first layer.

The really large bits which I haven't even tried to take on (since they're 
not strictly necessary... for me... at the moment) are replacing ENETRESET 
with something correct, and changing the SIOC[GS]80211 API so that the i_len 
and i_val arguments are both pervasive and functional in every call, just 
like sysctl.  The user should either have to know the length of a given 
call's i_data argument and be able to PROVE it by passing in i_len, or be 
able to query it with a NULL i_data argument which returns a valid i_len to 
the user.  In no circumstances should i_data be passed in without i_len, and 
in no circumstances should i_data be overwritten with more data than the 
user requested with i_len.  I consider these important security 

Brian Fundakowski Feldman                           \'[ FreeBSD ]''''''''''\
  <> green at                               \  The Power to Serve! \
 Opinions expressed are my own.                       \,,,,,,,,,,,,,,,,,,,,,,\

More information about the freebsd-arch mailing list