Skip site navigation (1)Skip section navigation (2)
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>