Date: Thu, 06 Nov 2003 11:29:53 -0500 From: "Brian F. Feldman" <green@FreeBSD.org> To: Sam Leffler <sam@errno.com> Cc: Warner Losh <imp@bsdimp.com> Subject: Re: my 802.11 work Message-ID: <200311061629.hA6GTrob021977@green.bikeshed.org> In-Reply-To: Message from Sam Leffler <sam@errno.com> of "Wed, 05 Nov 2003 21:25:07 PST." <200311052125.07773.sam@errno.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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. \,,,,,,,,,,,,,,,,,,,,,,\
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200311061629.hA6GTrob021977>