Date: Tue, 14 Feb 2006 19:46:08 -0600 From: Craig Boston <craig@feniz.gank.org> To: Kevin Oberman <oberman@es.net> Cc: freebsd-stable@freebsd.org, Matt Dawson <matt@mattsnetwork.co.uk> Subject: Re: dhclient in 6.0 Message-ID: <20060215014608.GA9931@nowhere> In-Reply-To: <20060205060416.3C11045041@ptavv.es.net> References: <200602041808.03062.matt@mattsnetwork.co.uk> <20060205060416.3C11045041@ptavv.es.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, Feb 04, 2006 at 10:04:16PM -0800, Kevin Oberman wrote: > The problem is that the integration of the modern wlan (802.11) code has > never been done in the if_wi code and it does not report state back to > wlan adequately to make the OpenBSD client function correctly. Well, that's not quite accurate. The wi driver does support net80211 as much as it can at least. Sam went to a lot of trouble to support as much of net80211 as possible given the design of the driver. Part of the problem is that full net80211 needs support for hardware operations that we don't know how to provide for wi. It's not just a simple matter of someone going in and adding some function calls... > I know Sam L. has posted that he had a personal promise from someone to > update if_wi, but it never happened. (Sam has declined to state who that > was.) I'm partly guilty on that -- I told him a while back that I would try to net80211ify it if I had time, and have yet to come up with anything that works. However, he told me the same thing (someone had promised to fix it and backed out) before I started. I don't know who the original person is, but we should respect Sam's wish to not identify him/her. It's not nearly as simple as it sounds, and I certainly can't blame Sam for being skeptical of any claims to fix it. After hacking on wi some trying to get it working I can say that it's not likely to happen. Full net80211 layer support requires us to be able to control the roaming / association behavior of the card. The current wi driver only knows how to put the card into "automatic" mode, where the firmware handles all the details of associating and we never see any of the 802.11 management frames. This is likely due to the fact that there are no publicly available specs for the card or firmware interface -- so everything we know has been reverse engineered or gleaned from other sources. It's been a while, so I don't remember 100% how link state events work when in "device" roaming mode, but I suspect that's what dhclient doesn't like. Also, the wi driver supports two different firmware types with different interfaces (actually three but nobody's seen the third in ages)... and the Intersil firmware changes so much between revisions it's like supporting 20 different firmware types. Even minor changes have a tendency to break somebody's card, somewhere. Case in point, I was able to modify wi enough to get wpa_supplicant and dhclient to work (mostly) correctly for the card that I have, but when I sent the diffs to Sam and he tried it, his card wouldn't work at all -- even in manual mode. > I greatly prefer having dhclient run per interface and, if it understood > what the wi card was doing, it would be great. But that's not the way it > is and, with the declining popularity of Prism2 based cards, it may > never get updated unless someone gets sufficiently annoyed to do the > work themselves. It might be possible for someone who has a _LOT_ of free time, and a _LOT_ of spare hardware to test with, but so far nobody (including me) has needed it enough to dedicate the time and resources to it. Perhaps it would be best to just remove those cards from the supported list if they haven't been already. Craig
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060215014608.GA9931>