Virtual WiFi on Linux?
jt at hpl.hp.com
Wed Oct 19 17:05:03 EDT 2005
On Wed, Oct 19, 2005 at 10:17:36AM -1000, Jim Thompson wrote:
> On Oct 19, 2005, at 8:44 AM, Jean Tourrilhes wrote:
> >Jean Tourrilhes wrote:
> >>Obviously, if you
> >>want the performance to not suck, you need fast AP switching
> >>(currently available only with HostAP, doable with any card using the
> >>kernel ieee stack).
> the people who maintain linux seem to have chosen the 'hostap' stack,
> and this is fine.
One of my prime concern with regards to the in-kernel 802.11
stack was to make sure that enough people were involved. I'm actually
quite happy that the decision on which stack to use was postponed
until very recently, because I felt there was not enough critical
The reason I prefer many people are numerous. There is a wide
variety of hardware implementations out there, and it would be nice to
support adequatly all of them, which means lot of input at early
stage. More people mean more ideas, more potential, more
functionality. And more people means that if some developper goes
missing, the work is not stopped. And it avoid a single interest
running the show.
The 'hostap' stack won the beauty contest because various
people were using it. The stack that was merged was not the 'hostap'
stack, but the 'ipw' stack, derived from the 'hostap' stack. Maybe the
people in charge will use the code released by Devicescape and Jouni,
but you can bet that James and Jiri will have a significant impact on
this future stack.
> They're free to do so.
> I think they made a mistake, but Free Software means that I can put
> the madwifi 802.11 stack back in.
Actually, it's a shame that the PrismGT work came so late,
that would have removed all my reservations (not that I had much say
in the final decision).
> fastAP switching can work with other drivers (such as madwifi) too.
Yep, sorry I should have said : 'doable with any card using a
software stack, no doable with card having a thick firmware'.
> The Devicescape code uses the Atheros "vxworks" style HAL and a stub
> driver. There is essentially ZERO
> chance that Devicescape will be able to "open source" the rest of the
> solution for Atheros chipsets.
DeviceScape won't have the last word on that, I personally
think we have a good probability to see a fully OpenSource driver for
Atheros cards happening soon. I don't know what will be the impact of
> The Devicescape code uses proprietary firmware (from Neesus) in
> Prism2/2.5 chipsets in order to implement mBSSID.
> There is essentially ZERO chance that Devicescape will be able to
> release this code, too.
I think the Prism firmware is under NDA, so nobody would be
able to release such thing, except from Conexant.
> Does Devicescape have plans to implement support for another chipset
> and release that?
Devicescape doesn't run the show, most chipsets have a strong
independant maintainership under Linux, and those will do whatever
> Or did we get a gift of code that will be very difficult to use in a
> real-world situation?
Maybe, only time will tell.
> Perhaps Devicescape hopes that someone will make their released VAP
> code work over the madwifi HAL, but this is
> essentially duplication of effort, since madwifi has it already (tho
> its not released).
Unreleased stuff doesn't matter. There is lot's of duplication
all over the OpneSource world (how many BSDs ?), and it's usually a
good thing (Darwinism).
> But my opinion remains that Devicescape released code early to
> prevent being "one upped".
That's a pretty good reading of the situation. But complaining
about it won't make any difference.
More information about the HostAP