dhclient in 6.0

[Sam Leffler]

Craig Boston wrote:
> 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.

I recently made another stab at overhauling wi to better integrate with 
net80211.  It uses some of Craig's work and some of mine.  The results 
were fragile.  The main problem is what Craig describes: if all you care 
about are Intersil parts then you can do it but if wi is to continue 
supporting older cards then it's hard.  As I've said before I believe 
resources are better spent on improving drivers for newer parts.  OTOH 
if someone really and truly wants to do this I have a number of cards I 
can loan.

	Sam