Re: my 802.11 work

From: Brian F. Feldman (green_at_FreeBSD.org)
Date: 11/06/03

  • Next message: Wes Peters: "Re: newfs and mount vs. half-baked disks" 
    To: Sam Leffler <sam@errno.com>
Date: Thu, 06 Nov 2003 11:29:53 -0500

    Sam Leffler <sam@errno.com> 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:
    > > http://green.homeunix.org/~green/wi-fi.diffs

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

    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
    IEEE80211_APNODEFLAGS_AUTHORIZED flag. IEEE80211_IOC_APNODEDELETE is useful
    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
    considerations. 

    -- 
Brian Fundakowski Feldman                           \'[ FreeBSD ]''''''''''\
  <> green@FreeBSD.org                               \  The Power to Serve! \
 Opinions expressed are my own.                       \,,,,,,,,,,,,,,,,,,,,,,\
_______________________________________________
freebsd-arch@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org"
  • Next message: Wes Peters: "Re: newfs and mount vs. half-baked disks"