Hi,
I am a developer of the Broadcom-43xx driver project.
(The 43xx chipset is used in a lot of chipsets, including
the Apple Airport 2 card).
I am writing this mail on my PowerBook and it is sent
wireless to my AP.
That means, we can transmit real data, if you did not get it, yet. :)
That does _not_ mean, that it completely works, yet.
The team is in the progress of writing a SoftwareMAC layer,
which is needed for the bcm device. The SoftMAC is still very
incomplete. So do not expect to do any fancy stuff like WPA
or something line that with it.
Please be patient, thanks. :)
If you want to try the driver, a few steps have to be done manually,
because the SoftMAC doesn't do them automatically, yet:
insmod ieee80211softmac.ko
insmod bcm430x.ko
ifup ethX
iwconfig ethX channel YOUR_AP_CHANNEL
iwconfig ethX essid ESSID_OF_YOUR_AP
In between you should pray from time to time.
If it works without crashes, cool. :)
If it crashes, well, fix it or send us a complete OOPS message
including detailed information about the device. Most information
about the device is printed on insmod. Including this information is
_important_, because there are so many different devices around.
Do _not_ expect to get any 802.11a based device working, yet. Only b/g
devices should "work".
BCM43xx driver:
http://bcm43xx.berlios.de
Required SoftMAC Layer:
http://softmac.sipsolutions.net
Have fun.
"Jetzt Handykosten senken mit klarmobil - 15 Ct./Min.! Hier klicken"
http://www.klarmobil.de/index.html?pid=73025
On Sun, 04 Dec 2005 19:50:08 +0100 (CET)
[email protected] wrote:
> I am writing this mail on my PowerBook and it is sent
> wireless to my AP.
> That means, we can transmit real data, if you did not get it, yet. :)
Amazing progress :)
> That does _not_ mean, that it completely works, yet.
> The team is in the progress of writing a SoftwareMAC layer,
> which is needed for the bcm device. The SoftMAC is still very
> incomplete. So do not expect to do any fancy stuff like WPA
> or something line that with it.
> Please be patient, thanks. :)
Why not use the new in-kernel wifi stack?
Feyd
On Sunday 04 December 2005 20:52, you wrote:
> On Sun, 04 Dec 2005 19:50:08 +0100 (CET)
> [email protected] wrote:
>
> > I am writing this mail on my PowerBook and it is sent
> > wireless to my AP.
> > That means, we can transmit real data, if you did not get it, yet. :)
>
> Amazing progress :)
>
> > That does _not_ mean, that it completely works, yet.
> > The team is in the progress of writing a SoftwareMAC layer,
> > which is needed for the bcm device. The SoftMAC is still very
> > incomplete. So do not expect to do any fancy stuff like WPA
> > or something line that with it.
> > Please be patient, thanks. :)
>
> Why not use the new in-kernel wifi stack?
We do. The SoftMAC is an extension to it.
SoftMAC = Software Medium Access Control. It is about sending
and receiving management frames.
Some chips do this in hardware, so it is not part of the ieee80211 stack.
(the ipw2x00 do it in hardware, for example.)
PS: Sorry for the spam on the bottom of the previous mail. I had
to send it with the web-interface.
--
Greetings Michael.
On Sun, Dec 04, 2005 at 08:58:30PM +0100, Michael Buesch wrote:
> > Why not use the new in-kernel wifi stack?
>
> We do. The SoftMAC is an extension to it.
> SoftMAC = Software Medium Access Control. It is about sending
> and receiving management frames.
> Some chips do this in hardware, so it is not part of the ieee80211 stack.
> (the ipw2x00 do it in hardware, for example.)
Wouldn't it be better to try to get that functionality added into the
net/ieee80211 code instead of maintaining separate extension outside the
kernel tree? Many modern cards need the ability for the host CPU to take
care of management frame sending and receiving and from my view point,
this code should be in net/ieee80211. Many (all?) of the functions in
this "SoftMAC" look like something that would be nice to have as an
option in net/ieee80211. In other words, the low-level driver would
indicate what kind of functionality it needs and ieee80211 stack would
behave differently based on the underlying hardware profile.
ipw2x00 happens to be one of the main users of net/ieee80211 at the
moment, but it is by no means the only one and it should not be
defining what kind of functionality ends up being included in
net/ieee80211.
--
Jouni Malinen PGP id EFC895FA
> Wouldn't it be better to try to get that functionality added into the
> net/ieee80211 code instead of maintaining separate extension outside the
> kernel tree? Many modern cards need the ability for the host CPU to take
> care of management frame sending and receiving and from my view point,
> this code should be in net/ieee80211. Many (all?) of the functions in
> this "SoftMAC" look like something that would be nice to have as an
> option in net/ieee80211. In other words, the low-level driver would
> indicate what kind of functionality it needs and ieee80211 stack would
> behave differently based on the underlying hardware profile.
It would certainly be a good idea and I'm sure that's what will happen
once the code is mature enough ;)
Ben.
On Monday 05 December 2005 06:50, you wrote:
> On Sun, Dec 04, 2005 at 08:58:30PM +0100, Michael Buesch wrote:
>
> > > Why not use the new in-kernel wifi stack?
> >
> > We do. The SoftMAC is an extension to it.
> > SoftMAC = Software Medium Access Control. It is about sending
> > and receiving management frames.
> > Some chips do this in hardware, so it is not part of the ieee80211 stack.
> > (the ipw2x00 do it in hardware, for example.)
>
> Wouldn't it be better to try to get that functionality added into the
> net/ieee80211 code instead of maintaining separate extension outside the
> kernel tree? Many modern cards need the ability for the host CPU to take
> care of management frame sending and receiving and from my view point,
> this code should be in net/ieee80211. Many (all?) of the functions in
> this "SoftMAC" look like something that would be nice to have as an
> option in net/ieee80211. In other words, the low-level driver would
> indicate what kind of functionality it needs and ieee80211 stack would
> behave differently based on the underlying hardware profile.
>
> ipw2x00 happens to be one of the main users of net/ieee80211 at the
> moment, but it is by no means the only one and it should not be
> defining what kind of functionality ends up being included in
> net/ieee80211.
The SoftMAC is a separate module. That is _good_, so devices like
the ipw do not have to load the code, because they do not need it.
The SoftMAC ties (and integrates) very close to the ieee80211 subsystem.
device <--> Driver <----------> ieee80211 <-----> kernel networking layer
| ^
| |
.--------> SoftMAC ---.
This is approximately how it works.
You see that SoftMAC is not exactly a part or the ieee80211 subsystem,
but it uses its interface to TX a frame (and the struct to get
some information about the device).
This works without any modifications to the ieee80211 layer and I
doubt big changes will have to be made in future.
In fact, we started with the SoftMAC layer integrated into the
ieee80211 subsystem. You can still find the patches on the project FTP.
We decided to drop it, because of the bad design.
This all works fine. There is absolutely no need to bloat the
ieee80211 layer with functionality, which is not needed by all devices.
--
Greetings Michael.
On Mon, Dec 05, 2005 at 12:08:16PM +0100, Michael Buesch wrote:
> The SoftMAC is a separate module. That is _good_, so devices like
> the ipw do not have to load the code, because they do not need it.
> The SoftMAC ties (and integrates) very close to the ieee80211 subsystem.
I like the modular design..
> You see that SoftMAC is not exactly a part or the ieee80211 subsystem,
> but it uses its interface to TX a frame (and the struct to get
> some information about the device).
.. but I disagree with this. If there is functionality like generating
management frames, it is very much part of the ieee80211 subsystem in my
opinion.
> This all works fine. There is absolutely no need to bloat the
> ieee80211 layer with functionality, which is not needed by all devices.
I'm afraid of this leading to duplicated work since ieee80211 stack is
being used without this new SoftMAC code for devices that do need host
CPU to take care of functionality that is currently in SoftMAC module
and will be added to ieee80211 subsystem.
--
Jouni Malinen PGP id EFC895FA
On Monday 05 December 2005 15:19, you wrote:
> On Mon, Dec 05, 2005 at 12:08:16PM +0100, Michael Buesch wrote:
>
> > The SoftMAC is a separate module. That is _good_, so devices like
> > the ipw do not have to load the code, because they do not need it.
> > The SoftMAC ties (and integrates) very close to the ieee80211 subsystem.
>
> I like the modular design..
>
> > You see that SoftMAC is not exactly a part or the ieee80211 subsystem,
> > but it uses its interface to TX a frame (and the struct to get
> > some information about the device).
>
> .. but I disagree with this. If there is functionality like generating
> management frames, it is very much part of the ieee80211 subsystem in my
> opinion.
Think of SoftMAC as an extension to ieee80211.
> > This all works fine. There is absolutely no need to bloat the
> > ieee80211 layer with functionality, which is not needed by all devices.
>
> I'm afraid of this leading to duplicated work since ieee80211 stack is
> being used without this new SoftMAC code for devices that do need host
> CPU to take care of functionality that is currently in SoftMAC module
> and will be added to ieee80211 subsystem.
Well, I do not care for drivers ignoring SoftMAC and duplicating
the work. The question is: Why don't these drivers use SoftMAC?
(Yeah, because it is incomplete, is the answer. :D I am talking
about future.)
What is so hard about a driver including ieee80211.h _and_
ieee80211softmac.h, if it requires Software MAC? And what
exactly is duplicated work here? SoftMAC does _not_ duplicate;
it extends.
--
Greetings Michael.
On Mon, Dec 05, 2005 at 03:28:32PM +0100, Michael Buesch wrote:
> Well, I do not care for drivers ignoring SoftMAC and duplicating
> the work. The question is: Why don't these drivers use SoftMAC?
> (Yeah, because it is incomplete, is the answer. :D I am talking
> about future.)
For me, the answer would have been because I had no idea about that
being worked on somewhere else. Now the answer would be more likely
"because it is not in netdev-2.6 tree with rest of ieee80211
development".
> What is so hard about a driver including ieee80211.h _and_
> ieee80211softmac.h, if it requires Software MAC? And what
> exactly is duplicated work here? SoftMAC does _not_ duplicate;
> it extends.
That is not hard as long as this work is easily available.
--
Jouni Malinen PGP id EFC895FA
On Sun, 04 Dec 2005 19:50:08 +0100, [email protected] wrote:
> The team is in the progress of writing a SoftwareMAC layer,
> which is needed for the bcm device. The SoftMAC is still very
> incomplete. So do not expect to do any fancy stuff like WPA
> or something line that with it.
Why yet another attempt to write 802.11 stack? Sure, the one currently
in the kernel is unusable and everybody knows about it. But why not to
improve code opensourced by Devicescape some time ago instead of
inventing the wheel again and again? Yes, I know that code is not
perfect and needs a lot of work, but it is the best piece of code we
have available now. And it _does_ support WPA and such - in fact, it is
nearly complete.
Please take a look at http://kernel.org/pub/linux/kernel/people/jbenc/
Thanks,
--
Jiri Benc
SUSE Labs
Hi.
On Mon, 2005-12-05 at 19:00 +0100, Jiri Benc wrote:
> Why yet another attempt to write 802.11 stack? Sure, the one currently
> in the kernel is unusable and everybody knows about it. But why not to
> improve code opensourced by Devicescape some time ago instead of
> inventing the wheel again and again?
Or, in case there is some unknown objection to the mentioned code: use
the 802.11 stack that comes along with MadWifi, which provides things
like virtual interfaces (for multiple SSID support on one physical card)
and WPA support.
Although I'm a bit biased towards MadWifi, I'd second your suggestion to
make use of the Devicescape code. The benefit of having a fully-blown
802.11 stack in the kernel that drivers can make use of has been
discussed before, so I won't go into that yet again.
Bye, Mike
On Mon, 05 Dec 2005 19:14:03 +0100
Michael Renzmann <[email protected]> wrote:
> Hi.
>
> On Mon, 2005-12-05 at 19:00 +0100, Jiri Benc wrote:
> > Why yet another attempt to write 802.11 stack? Sure, the one currently
> > in the kernel is unusable and everybody knows about it. But why not to
> > improve code opensourced by Devicescape some time ago instead of
> > inventing the wheel again and again?
>
> Or, in case there is some unknown objection to the mentioned code: use
> the 802.11 stack that comes along with MadWifi, which provides things
> like virtual interfaces (for multiple SSID support on one physical card)
> and WPA support.
>
> Although I'm a bit biased towards MadWifi, I'd second your suggestion to
> make use of the Devicescape code. The benefit of having a fully-blown
> 802.11 stack in the kernel that drivers can make use of has been
> discussed before, so I won't go into that yet again.
>
Please use or extend the existing net/ieee80211 stack in 2.6.
The defacto plan is to convert all wifi drivers that need software
support to use that.
--
Stephen Hemminger <[email protected]>
OSDL http://developer.osdl.org/~shemminger
> Why yet another attempt to write 802.11 stack? Sure, the one currently
> in the kernel is unusable and everybody knows about it. But why not to
> improve code opensourced by Devicescape some time ago instead of
> inventing the wheel again and again? Yes, I know that code is not
> perfect and needs a lot of work, but it is the best piece of code we
> have available now. And it _does_ support WPA and such - in fact, it
> is nearly complete.
>
> Please take a look at http://kernel.org/pub/linux/kernel/people/jbenc/
We're not writing an entire stack. We're writing a layer that sits in
between the current ieee80211 stack that's already present in the kernel
and drivers that do not have a hardware MAC. Since ieee80211 is already
in use in the kernel today, this seemed like a natural and useful
extension to the existing code. I agree that it's somewhat wasteful to
keep rewriting 802.11 stacks and we considered other options, but it
seemed like a more logical choice to work with what was available and
recommended than to use an external stack.
-Joe
Michael Renzmann wrote:
> Hi.
>
> On Mon, 2005-12-05 at 19:00 +0100, Jiri Benc wrote:
>
>>Why yet another attempt to write 802.11 stack? Sure, the one currently
>>in the kernel is unusable and everybody knows about it. But why not to
>>improve code opensourced by Devicescape some time ago instead of
>>inventing the wheel again and again?
>
>
> Or, in case there is some unknown objection to the mentioned code: use
> the 802.11 stack that comes along with MadWifi, which provides things
> like virtual interfaces (for multiple SSID support on one physical card)
> and WPA support.
>
> Although I'm a bit biased towards MadWifi, I'd second your suggestion to
> make use of the Devicescape code. The benefit of having a fully-blown
> 802.11 stack in the kernel that drivers can make use of has been
> discussed before, so I won't go into that yet again.
Use the stack that's already in the kernel.
Encouraging otherwise hinders continued wireless progress under Linux.
Jeff
On Mon, 05 Dec 2005 13:46:43 -0500, Jeff Garzik wrote:
> Use the stack that's already in the kernel.
>
> Encouraging otherwise hinders continued wireless progress under Linux.
There is nothing like a "802.11 stack" currently in the kernel,
regardless what James Ketrenos is saying. Sorry.
--
Jiri Benc
SUSE Labs
In general, Jouni's points are good, as are Michael's.
The key question is about the size of the SoftMAC code. If its huge, an
ieee80211 sub-module makes sense. If it's not, then adding the code to
net/ieee80211 makes a lot more sense.
Certainly some chips will use more ieee80211 code than others. This is
no different than ethernet NICs: some make use of TSO and checksum
offload code included in every kernel, while for other NICs the kernel
TSO/csum code is just dead weight.
In general, adding directly to net/ieee80211 is preferred, UNLESS there
are overriding reasons not to do so (such as a huge size increase).
Jeff
Jiri Benc wrote:
> On Mon, 05 Dec 2005 13:46:43 -0500, Jeff Garzik wrote:
>
>>Use the stack that's already in the kernel.
>>
>>Encouraging otherwise hinders continued wireless progress under Linux.
> There is nothing like a "802.11 stack" currently in the kernel,
> regardless what James Ketrenos is saying. Sorry.
Complete bullshit. There is obviously 802.11 generic code in the
kernel, and that's what _I_ am saying, because it's true.
If it doesn't support your favorite wireless chipset, then submit patches.
Jeff
On Mon, 05 Dec 2005 13:38:37 -0500, Joseph Jezak wrote:
> We're not writing an entire stack. We're writing a layer that sits in
> between the current ieee80211 stack that's already present in the kernel
> and drivers that do not have a hardware MAC. Since ieee80211 is already
> in use in the kernel today, this seemed like a natural and useful
> extension to the existing code. I agree that it's somewhat wasteful to
> keep rewriting 802.11 stacks and we considered other options, but it
> seemed like a more logical choice to work with what was available and
> recommended than to use an external stack.
Unfortunately, the only long-term solution is to rewrite completely the
current in-kernel ieee80211 code (I would not call it a "stack") or
replace it with something another. The current code was written for
Intel devices and it doesn't support anything else - so every developer
of a wifi driver tries to implement his own "softmac" now. I cannot see
how this can move as forward and I think we can agree this is not the
way to go.
Rewriting (or, if you like, enhancing) the current 802.11 code seems to
be wasting of time now, when nearly complete Linux stack was opensourced
by Devicescape. We can try to merge it, but I'm not convinced it is
possible, the Devicescape's stack is far more advanced.
--
Jiri Benc
SUSE Labs
Jiri Benc wrote:
> On Mon, 05 Dec 2005 13:38:37 -0500, Joseph Jezak wrote:
>
>>We're not writing an entire stack. We're writing a layer that sits in
>>between the current ieee80211 stack that's already present in the kernel
>>and drivers that do not have a hardware MAC. Since ieee80211 is already
>>in use in the kernel today, this seemed like a natural and useful
>>extension to the existing code. I agree that it's somewhat wasteful to
>>keep rewriting 802.11 stacks and we considered other options, but it
>>seemed like a more logical choice to work with what was available and
>>recommended than to use an external stack.
>
>
> Unfortunately, the only long-term solution is to rewrite completely the
> current in-kernel ieee80211 code (I would not call it a "stack") or
> replace it with something another. The current code was written for
> Intel devices and it doesn't support anything else - so every developer
Patently false.
ieee80211 is used by Intel. Some bits used by HostAP, which also
duplicates a lot of ieee80211 code. And bcm43xx. And another couple
drivers found in -mm or out-of-tree.
> of a wifi driver tries to implement his own "softmac" now. I cannot see
> how this can move as forward and I think we can agree this is not the
> way to go.
You're agreeing with only yourself, then?
> Rewriting (or, if you like, enhancing) the current 802.11 code seems to
> be wasting of time now, when nearly complete Linux stack was opensourced
> by Devicescape. We can try to merge it, but I'm not convinced it is
> possible, the Devicescape's stack is far more advanced.
This invalid logic is why we have a ton of wireless stacks, all
duplicating each other.
Jeff
On Mon, Dec 05, 2005 at 07:55:43PM +0100, Jiri Benc wrote:
> Unfortunately, the only long-term solution is to rewrite completely the
> current in-kernel ieee80211 code (I would not call it a "stack") or
> replace it with something another. The current code was written for
> Intel devices and it doesn't support anything else - so every developer
> of a wifi driver tries to implement his own "softmac" now. I cannot see
> how this can move as forward and I think we can agree this is not the
> way to go.
Please stop beeing a freaking jackass. There are various projects using
the current code. It's not perfect but people are working on it. And Joseph &
friends are writing a module to support softmac cards in that framework,
which is one of the most urgently needed things right now, because all the
existing softmac frameworks don't work with that code.
And please stop your stupid devicespace advertisements. If you think the
code is so useful why don't you send patches to integrate it with the
currently existing wireless code (after cleaning up the horrible mess
it is currently)?
On Mon, 05 Dec 2005 13:54:00 -0500, Jeff Garzik wrote:
> Complete bullshit. There is obviously 802.11 generic code in the
> kernel, and that's what _I_ am saying, because it's true.
>
> If it doesn't support your favorite wireless chipset, then submit patches.
I have no favorite chipset. I read tons of source code of different
drivers instead. Current 802.11 code supports no management stuff at
all. And nearly every driver needs support for it - ask any developer of
wireless driver except James Ketrenos (oh, wait a moment - although ipw
devices do, unlike other devices, a lot of work in firmware, he is
implementing in the driver some management stuff too - strange, is not
his own "stack" good enough even for himself?).
And, as you might notice, I sent many patches. Only minor ones were
accepted. And then I started (and attended) a debate among wireless
developers about concepts of 802.11 stack, do you remember? And it gave
us interesting results. That results were implemented (patches were sent
and not accepted).
It may appears that I stopped afterwards, but it is not true. Nearly
after that debate had finished, Jouni announced opensourcing of the
stack he has been working on for several years. From that time I have
been trying to get familiar with that stack, it is quite complex. I have
one semi-working driver for it now and I think I know about issues of
the stack.
--
Jiri Benc
SUSE Labs
On Mon, 05 Dec 2005 14:08:28 -0500, Jeff Garzik wrote:
> Patently false.
>
> ieee80211 is used by Intel. Some bits used by HostAP, which also
> duplicates a lot of ieee80211 code. And bcm43xx. And another couple
> drivers found in -mm or out-of-tree.
Hostap uses only encryption code, which was copied from - guess who -
hostap. Everything other must be done by the hostap driver itself.
bcm43xx can use - like every other driver - only constants and defines
from ieee80211.h. This is the reason why they are trying to implement
"softmac" on top of it. But that work was already done by Jouni.
> > of a wifi driver tries to implement his own "softmac" now. I cannot see
> > how this can move as forward and I think we can agree this is not the
> > way to go.
>
> You're agreeing with only yourself, then?
I meant that every driver tries to implements its own "softmac". This is
not the way to go, right?
> > Rewriting (or, if you like, enhancing) the current 802.11 code seems to
> > be wasting of time now, when nearly complete Linux stack was opensourced
> > by Devicescape. We can try to merge it, but I'm not convinced it is
> > possible, the Devicescape's stack is far more advanced.
>
> This invalid logic is why we have a ton of wireless stacks, all
> duplicating each other.
Heh? We have one nearly finished stack (and no, it's not the one in
kernel). Why should we try to implement a new stack instead of fixing
some issues of the nearly finished one?
--
Jiri Benc
SUSE Labs
On Mon, Dec 05, 2005 at 01:52:21PM -0500, Jeff Garzik wrote:
> In general, Jouni's points are good, as are Michael's.
>
> The key question is about the size of the SoftMAC code. If its huge, an
> ieee80211 sub-module makes sense. If it's not, then adding the code to
> net/ieee80211 makes a lot more sense.
>
> Certainly some chips will use more ieee80211 code than others. This is
> no different than ethernet NICs: some make use of TSO and checksum
> offload code included in every kernel, while for other NICs the kernel
> TSO/csum code is just dead weight.
>
> In general, adding directly to net/ieee80211 is preferred, UNLESS there
> are overriding reasons not to do so (such as a huge size increase).
I tend to disagree a bit here. If it can be separate without making the
API more complicated a separate module is nicer, if the API would get nasty
integerating it is better. And nevermind whether it's a separate module or
not it should live in net/ieee80211/ ;-)
In either case ?I think this decision is better left until the code is in
an almost mergeable shape, because then the details will be clear.
On Mon, 5 Dec 2005 19:10:08 +0000, Christoph Hellwig wrote:
> Please stop beeing a freaking jackass. There are various projects using
> the current code. It's not perfect but people are working on it.
Yes, and everyone implements his own softmac (this is the third one I
know about). I tried to put all of these efforts together (google
through the netdev archives) and wrote many patches.
> And Joseph &
> friends are writing a module to support softmac cards in that framework,
> which is one of the most urgently needed things right now, because all the
> existing softmac frameworks don't work with that code.
And authors of rtl8180 did it too. And authors of adm8211 too.
> And please stop your stupid devicespace advertisements. If you think the
> code is so useful why don't you send patches to integrate it with the
> currently existing wireless code (after cleaning up the horrible mess
> it is currently)?
This is what I'm doing last two months. But it's not so easy to clean it
up and it seems that nobody else is interested. But it has all of the
features you need (except active scanning) - this is the reason I
stopped to work on improving current in-kernel 802.11 code and focused
on Devicescape's code. It is several years beyond the state that current
code is at now. And it is not an advertisement, it is a fact.
--
Jiri Benc
SUSE Labs
On Mon, Dec 05, 2005 at 08:31:21PM +0100, Jiri Benc wrote:
> > And Joseph &
> > friends are writing a module to support softmac cards in that framework,
> > which is one of the most urgently needed things right now, because all the
> > existing softmac frameworks don't work with that code.
>
> And authors of rtl8180 did it too. And authors of adm8211 too.
None of them made it into the kernel tree. As soon as we'll have an
acceptable one everyone will have to use and improve it. I personally
couldn't care less what we start with.
> > And please stop your stupid devicespace advertisements. If you think the
> > code is so useful why don't you send patches to integrate it with the
> > currently existing wireless code (after cleaning up the horrible mess
> > it is currently)?
>
> This is what I'm doing last two months. But it's not so easy to clean it
> up and it seems that nobody else is interested. But it has all of the
> features you need (except active scanning) - this is the reason I
> stopped to work on improving current in-kernel 802.11 code and focused
> on Devicescape's code. It is several years beyond the state that current
> code is at now. And it is not an advertisement, it is a fact.
That's because you still don't get how we do development. The last thing
we want is full-scale rewrites. Submit patches to fix things based on
whatever you want but do it incremental. Anything that just moves existing
functionaly out of the place and adds duplicates with more functionality/
cleaner API/<buzzword of the day> is simply not acceptable.
Hi!
> I am a developer of the Broadcom-43xx driver project.
> (The 43xx chipset is used in a lot of chipsets, including
> the Apple Airport 2 card).
>
> I am writing this mail on my PowerBook and it is sent
> wireless to my AP.
> That means, we can transmit real data, if you did not get it,
> yet. :)
Congratulations ;-). I have bcm4303 here:
0000:00:0c.0 Network controller: Broadcom Corporation BCM4306
802.11b/g Wireless LAN Controller (rev 03)
...
> If it works without crashes, cool. :)
> If it crashes, well, fix it or send us a complete OOPS message
> including detailed information about the device. Most information
> about the device is printed on insmod. Including this information is
> _important_, because there are so many different devices around.
>
> Do _not_ expect to get any 802.11a based device working, yet. Only b/g
> devices should "work".
>
> BCM43xx driver:
> http://bcm43xx.berlios.de
> Required SoftMAC Layer:
> http://softmac.sipsolutions.net
...but don't feel like playing with *two* different revision control
systems just to get the sources. Do you think you could just mail the
diffs to the list?
Pavel
--
Thanks, Sharp!
On Mon, Dec 05, 2005 at 02:08:28PM -0500, Jeff Garzik wrote:
> Jiri Benc wrote:
> >On Mon, 05 Dec 2005 13:38:37 -0500, Joseph Jezak wrote:
> >
> >>We're not writing an entire stack. We're writing a layer that sits in
> >>between the current ieee80211 stack that's already present in the kernel
> >>and drivers that do not have a hardware MAC. Since ieee80211 is already
> >>in use in the kernel today, this seemed like a natural and useful
> >>extension to the existing code. I agree that it's somewhat wasteful to
> >>keep rewriting 802.11 stacks and we considered other options, but it
> >>seemed like a more logical choice to work with what was available and
> >>recommended than to use an external stack.
> >
> >
> >Unfortunately, the only long-term solution is to rewrite completely the
> >current in-kernel ieee80211 code (I would not call it a "stack") or
> >replace it with something another. The current code was written for
> >Intel devices and it doesn't support anything else - so every developer
>
> Patently false.
>
> ieee80211 is used by Intel. Some bits used by HostAP, which also
> duplicates a lot of ieee80211 code. And bcm43xx. And another couple
> drivers found in -mm or out-of-tree.
Orinoco also uses it now no ?
Dave
Dave Jones wrote:
> On Mon, Dec 05, 2005 at 02:08:28PM -0500, Jeff Garzik wrote:
> > Jiri Benc wrote:
> > >On Mon, 05 Dec 2005 13:38:37 -0500, Joseph Jezak wrote:
> > >
> > >>We're not writing an entire stack. We're writing a layer that sits in
> > >>between the current ieee80211 stack that's already present in the kernel
> > >>and drivers that do not have a hardware MAC. Since ieee80211 is already
> > >>in use in the kernel today, this seemed like a natural and useful
> > >>extension to the existing code. I agree that it's somewhat wasteful to
> > >>keep rewriting 802.11 stacks and we considered other options, but it
> > >>seemed like a more logical choice to work with what was available and
> > >>recommended than to use an external stack.
> > >
> > >
> > >Unfortunately, the only long-term solution is to rewrite completely the
> > >current in-kernel ieee80211 code (I would not call it a "stack") or
> > >replace it with something another. The current code was written for
> > >Intel devices and it doesn't support anything else - so every developer
> >
> > Patently false.
> >
> > ieee80211 is used by Intel. Some bits used by HostAP, which also
> > duplicates a lot of ieee80211 code. And bcm43xx. And another couple
> > drivers found in -mm or out-of-tree.
>
> Orinoco also uses it now no ?
Just the headers, really.
Jeff
On Mon, 5 Dec 2005 19:41:46 +0000, Christoph Hellwig wrote:
> None of them made it into the kernel tree. As soon as we'll have an
> acceptable one everyone will have to use and improve it. I personally
> couldn't care less what we start with.
Same with me.
> That's because you still don't get how we do development. The last thing
> we want is full-scale rewrites. Submit patches to fix things based on
> whatever you want but do it incremental.
We have got almost finished and working stack. Everything we need to do
is:
1. identify issues;
2. fix the issues; some of them will need broader discussion;
3. split it into several (potentially a lot of) reviewable patches;
4. clean up the drivers.
I'm in phase 2 now (no interesting results yet). I don't think it is
possible to start by phase 3 and then skip back to 1 and 2... This is
the reason I didn't post anything yet (or did you see some bloated
everything-rewriting patch from me posted on the list?).
But I also don't think it is worth effort to reinvent wheel by writing all
of the stuff again. This is the reason I started to examine Devicescape
code, nothing more.
And if you are familiar with the current in-kernel 802.11 code (and if
you know at least two different drivers), you will probably agree that
many things have to be changed in the current code even if we decided to
build on the top of it, so the result will finally differ a lot and will
be almost incompatible with the current code. (Why? I think I wrote some
explanation already to netdev list - if you don't find it or it is not
understandable, please let me know, I will try again.)
--
Jiri Benc
SUSE Labs
On Monday 05 December 2005 20:40, you wrote:
> > BCM43xx driver:
> > http://bcm43xx.berlios.de
> > Required SoftMAC Layer:
> > http://softmac.sipsolutions.net
>
> ...but don't feel like playing with *two* different revision control
> systems just to get the sources. Do you think you could just mail the
> diffs to the list?
The diffs will be outdated within minutes ;)
Both trees are rapidly changing.
--
Greetings Michael.
On Monday 05 December 2005 19:00, you wrote:
> On Sun, 04 Dec 2005 19:50:08 +0100, [email protected] wrote:
> > The team is in the progress of writing a SoftwareMAC layer,
> > which is needed for the bcm device. The SoftMAC is still very
> > incomplete. So do not expect to do any fancy stuff like WPA
> > or something line that with it.
>
> Why yet another attempt to write 802.11 stack? Sure, the one currently
> in the kernel is unusable and everybody knows about it. But why not to
> improve code opensourced by Devicescape some time ago instead of
> inventing the wheel again and again? Yes, I know that code is not
> perfect and needs a lot of work, but it is the best piece of code we
> have available now. And it _does_ support WPA and such - in fact, it is
> nearly complete.
This is __not__ "yet another stack". It is an _extension_.
It is all about management frames, which the in-kernel code
does not manage.
We want a working device. The driver is in a state where it
is more or less usable. What is missing, is code to handle
management.
We tried the code from the RTL driver, but it is total crap.
We dropped it again. We thought about using yet another out of
kernel ieee80211 stack, but we began to write an extension
to the in-kernel code. If that was right or wrong, well, that's
the question.
If you _really_ think we should have used $EXTERNAL_STACK,
go and patch the driver to work with it. I would really like
to see it working. It is easy to change the used 80211 stack,
as it is only a task of replacing TX and RX function calls
(and a few parameter settings to the ieee struct on init).
PS: I forgot to mention in the announcement, that the driver has
problems with OFDM (that are all 802.11g) rates. So use 802.11b
rates. 11MBit works fine.
--
Greetings Michael.
Hi!
> > > BCM43xx driver:
> > > http://bcm43xx.berlios.de
> > > Required SoftMAC Layer:
> > > http://softmac.sipsolutions.net
> >
> > ...but don't feel like playing with *two* different revision control
> > systems just to get the sources. Do you think you could just mail the
> > diffs to the list?
>
> The diffs will be outdated within minutes ;)
> Both trees are rapidly changing.
Okay, at least for preview... it would be nice. It can't change _that_
fast.
Plus, you may want to release some diffs anyway. Bugreport against
known version is way more interesting than bugreport against "tuesday,
13:23 version".
Pavel
--
Thanks, Sharp!
On Mon, 2005-12-05 at 21:35 +0100, Pavel Machek wrote:
> Hi!
>
> > > > BCM43xx driver:
> > > > http://bcm43xx.berlios.de
> > > > Required SoftMAC Layer:
> > > > http://softmac.sipsolutions.net
> > >
> > > ...but don't feel like playing with *two* different revision control
> > > systems just to get the sources. Do you think you could just mail the
> > > diffs to the list?
> >
> > The diffs will be outdated within minutes ;)
> > Both trees are rapidly changing.
>
> Okay, at least for preview... it would be nice. It can't change _that_
> fast.
maybe daily snapshots would be nice for this...
On Monday 05 December 2005 21:35, you wrote:
> Hi!
>
> > > > BCM43xx driver:
> > > > http://bcm43xx.berlios.de
> > > > Required SoftMAC Layer:
> > > > http://softmac.sipsolutions.net
> > >
> > > ...but don't feel like playing with *two* different revision control
> > > systems just to get the sources. Do you think you could just mail the
> > > diffs to the list?
> >
> > The diffs will be outdated within minutes ;)
> > Both trees are rapidly changing.
>
> Okay, at least for preview... it would be nice. It can't change _that_
> fast.
>
> Plus, you may want to release some diffs anyway. Bugreport against
> known version is way more interesting than bugreport against "tuesday,
> 13:23 version".
Ok, I will do a few tarballs tomorrow. Sorry, I have to leave right now.
--
Greetings Michael.
On Mon, 5 Dec 2005 21:23:42 +0100, Michael Buesch wrote:
> This is __not__ "yet another stack". It is an _extension_.
> It is all about management frames, which the in-kernel code
> does not manage.
But this code should be part of the stack, as nearly every driver needs
it. Management handling should be really managed by the kernel. The same
applies to driver<->userspace communication - there is no need to bother
every driver with it. And so on.
The hard part is that every driver will need a slightly different amount
of this support depending on the amount of features that are provided by
firmware.
> We want a working device. The driver is in a state where it
> is more or less usable. What is missing, is code to handle
> management.
I understand.
> We tried the code from the RTL driver, but it is total crap.
> We dropped it again. We thought about using yet another out of
> kernel ieee80211 stack, but we began to write an extension
> to the in-kernel code. If that was right or wrong, well, that's
> the question.
>
> If you _really_ think we should have used $EXTERNAL_STACK,
> go and patch the driver to work with it.
No. I just think we (everybody) should concentrate at one particular
stack, finish it and merge it. And I'm convinced Jouni's stack is
currently the best solution available - far far from perfect, with many
issues, but still the best - and it will finally save as much time.
--
Jiri Benc
SUSE Labs
Hi.
On Mon, 2005-12-05 at 13:46 -0500, Jeff Garzik wrote:
> > Although I'm a bit biased towards MadWifi, I'd second your suggestion to
> > make use of the Devicescape code. The benefit of having a fully-blown
> > 802.11 stack in the kernel that drivers can make use of has been
> > discussed before, so I won't go into that yet again.
> Use the stack that's already in the kernel.
Sorry, that was my bad. I thought that the Devicescape code found its
way to the kernel (didn't follow the discussion some months ago too
closely). Although I think there probably are better alternatives to the
802.11 stack that is in the kernel right now, having a central 802.11
stack at all is a great improvement that should be used where possible.
> Encouraging otherwise hinders continued wireless progress under Linux.
That depends. If the encouraging is about an alternative, more complete
and superior 802.11 stack for Linux which could be integrated with less
effort than extending the existing code, that should be worth to talk
about.
Please note that I'm not refering here to any of the related suggestions
which have been made during the past months - it's a general statement.
Bye, Mike
On Dec 05, 2005, at 15:42, Jiri Benc wrote:
> On Mon, 5 Dec 2005 21:23:42 +0100, Michael Buesch wrote:
>> This is __not__ "yet another stack". It is an _extension_. It is
>> all about management frames, which the in-kernel code does not
>> manage.
>
> But this code should be part of the stack, as nearly every driver
> needs it.
WRONG. More than half the currently Linux-compatible wireless cards
handle the wireless management packets in hardware, such that they're
little more complicated than a basic ethernet device with a channel,
an ESSID, and a list of MACs/APs.
> Management handling should be really managed by the kernel.
Yes, but it might not need to be in the base stack if it's largely
functionally independent.
> The hard part is that every driver will need a slightly different
> amount of this support depending on the amount of features that are
> provided by firmware.
s/firmware/hardware/g. This is _exactly_ why an external module
makes a lot of sense.
>> We tried the code from the RTL driver, but it is total crap. We
>> dropped it again. We thought about using yet another out of kernel
>> ieee80211 stack, but we began to write an extension to the in-
>> kernel code. If that was right or wrong, well, that's the question.
>>
>> If you _really_ think we should have used $EXTERNAL_STACK, go and
>> patch the driver to work with it.
>
> No. I just think we (everybody) should concentrate at one
> particular stack, finish it and merge it. And I'm convinced Jouni's
> stack is currently the best solution available - far far from
> perfect, with many issues, but still the best - and it will finally
> save as much time.
What you miss is that the kernel does _not_ go with the "rewrite it
and replace it" methodology. See Luben Toikov in the SAS flamewar
for another example. If a better stack exists, provide a nice clean
set of totally functional changes that convert the current one into
that one. In the process, we even get to keep the nice parts of the
current one that aren't in his (whatever they may be), and we always
have a working wireless stack. With the rewrite/replace solution,
you end up broken or unstable half the time.
Cheers,
Kyle Moffett
--
Simple things should be simple and complex things should be possible
-- Alan Kay
On Tue, Dec 06, 2005 at 04:26:50AM -0500, Kyle Moffett wrote:
> On Dec 05, 2005, at 15:42, Jiri Benc wrote:
> >On Mon, 5 Dec 2005 21:23:42 +0100, Michael Buesch wrote:
> >>This is __not__ "yet another stack". It is an _extension_. It is
> >>all about management frames, which the in-kernel code does not
> >>manage.
> >
> >But this code should be part of the stack, as nearly every driver
> >needs it.
>
> WRONG. More than half the currently Linux-compatible wireless cards
> handle the wireless management packets in hardware, such that they're
> little more complicated than a basic ethernet device with a channel,
> an ESSID, and a list of MACs/APs.
>
I do not want to enter in this flamewar, but the current driver i'm working
on (marvell libertas chipset) need management frames in software. But to
reduce cost, i think that lower chipset try to put the most in the host and
not in the chipset. Marvell build the chipset around a ARM cpu so i think one
day i can do it in hardware but for now i need to choose a ieee802.11 stack.
I've began to used the in kernel solution with my own functions to
send and received this frame. But i hope we will find a technical solution
that please everyone. I'll try to see if the softmac layer written for
broadcom driver can be used for my project.
Luc
On Mon, Dec 05, 2005 at 02:53:29PM -0500, Dave Jones wrote:
> > ieee80211 is used by Intel. Some bits used by HostAP, which also
> > duplicates a lot of ieee80211 code. And bcm43xx. And another couple
> > drivers found in -mm or out-of-tree.
>
> Orinoco also uses it now no ?
Dave, the Orinoco is a wireless card that has a hardware MAC, plust
firmware.
I do agree with Jiri that there basically is no support for softmac
devices in the ieee80211 code.
I'm also in favor of merging the devicescape code, but I don't see it
happening without somebody taking care to provide all the required
levels of interfaces (I see at least three levels of API's that a wireless
driver would need, depending on how much stuff is done in
hardware/firmware and how much in software.
I also think that there is a lack of knowledge on the architecture of
802.11 low-level protocols and drivers among many people (including
myself) in the network community. Only this way I can explain why there
are always people who claim that the kernel already has a 802.11
'stack'.
--
- Harald Welte <[email protected]> http://gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
Hi!
> > Please stop beeing a freaking jackass. There are various projects using
> > the current code. It's not perfect but people are working on it.
>
> Yes, and everyone implements his own softmac (this is the third one I
> know about). I tried to put all of these efforts together (google
> through the netdev archives) and wrote many patches.
Well, unfortunately people seem to disagree about "what the right
softmac is". And James's code is in kernel, thats _huge_ advantage.
> > And please stop your stupid devicespace advertisements. If you think the
> > code is so useful why don't you send patches to integrate it with the
> > currently existing wireless code (after cleaning up the horrible mess
> > it is currently)?
>
> This is what I'm doing last two months. But it's not so easy to clean it
> up and it seems that nobody else is interested. But it has all of the
> features you need (except active scanning) - this is the reason I
> stopped to work on improving current in-kernel 802.11 code and focused
> on Devicescape's code. It is several years beyond the state that current
> code is at now. And it is not an advertisement, it is a fact.
Another fact is that it is not in kernel, and by the time you get it
cleaned up, in-kernel code will probably get advanced enough that your
code will not be merged.
If devicescape is really so much better, submit it _now_. It may be
slightly buggy, but so is probably current code.
--
Thanks, Sharp!
Hi!
> > That's because you still don't get how we do development. The last thing
> > we want is full-scale rewrites. Submit patches to fix things based on
> > whatever you want but do it incremental.
>
> We have got almost finished and working stack. Everything we need to do
> is:
> 1. identify issues;
> 2. fix the issues; some of them will need broader discussion;
> 3. split it into several (potentially a lot of) reviewable patches;
> 4. clean up the drivers.
>
> I'm in phase 2 now (no interesting results yet). I don't think it is
No, it does not work like that. You don't get nice, reviewable,
mergeable patches by developing code independently for 3 years or so
then attempting merge.
If devicescape code is better than mainline, merge it _now_. If it is
not, drop it and start from mainline code.
> And if you are familiar with the current in-kernel 802.11 code (and if
> you know at least two different drivers), you will probably agree that
> many things have to be changed in the current code even if we decided to
> build on the top of it, so the result will finally differ a lot and will
> be almost incompatible with the current code.
That's okay; as long as incremental way exist, first version not being
compatible with last version is not a problem.
Pavel
--
Thanks, Sharp!
Pavel Machek wrote:
> Hi!
>
>
>>>That's because you still don't get how we do development. The last thing
>>>we want is full-scale rewrites. Submit patches to fix things based on
>>>whatever you want but do it incremental.
>>
>>We have got almost finished and working stack. Everything we need to do
>>is:
>>1. identify issues;
>>2. fix the issues; some of them will need broader discussion;
>>3. split it into several (potentially a lot of) reviewable patches;
>>4. clean up the drivers.
>>
>>I'm in phase 2 now (no interesting results yet). I don't think it is
>
>
> No, it does not work like that. You don't get nice, reviewable,
> mergeable patches by developing code independently for 3 years or so
> then attempting merge.
>
> If devicescape code is better than mainline, merge it _now_. If it is
> not, drop it and start from mainline code.
Merge now even if it breaks the current tree? I for one would certainly
rather he finish his work on it and get it more polished. Reviewing and
testing something that actually works would be a lot more fun...
--
Ben Greear <[email protected]>
Candela Technologies Inc http://www.candelatech.com
Harald Welte wrote:
> I also think that there is a lack of knowledge on the architecture of
> 802.11 low-level protocols and drivers among many people (including
> myself) in the network community. Only this way I can explain why there
> are always people who claim that the kernel already has a 802.11
> 'stack'.
This last sentence, regardless of the source, is simply playing with words.
We have 802.11 common code in the kernel, that several drivers are
using. Future drivers should modify that common code to suit their
needs, rather than dropping it and starting from scratch.
Jeff
Pavel Machek wrote:
> No, it does not work like that. You don't get nice, reviewable,
> mergeable patches by developing code independently for 3 years or so
> then attempting merge.
>
> If devicescape code is better than mainline, merge it _now_. If it is
> not, drop it and start from mainline code.
Agreed.
Jeff
On Tue, 06 Dec 2005 14:05:07 -0500
Jeff Garzik <[email protected]> wrote:
> Harald Welte wrote:
> > I also think that there is a lack of knowledge on the architecture of
> > 802.11 low-level protocols and drivers among many people (including
> > myself) in the network community. Only this way I can explain why there
> > are always people who claim that the kernel already has a 802.11
> > 'stack'.
>
> This last sentence, regardless of the source, is simply playing with words.
>
> We have 802.11 common code in the kernel, that several drivers are
> using. Future drivers should modify that common code to suit their
> needs, rather than dropping it and starting from scratch.
Also, the correct way to built network code is often not aligned with
the artificial layering imposed by standards.
--
Stephen Hemminger <[email protected]>
OSDL http://developer.osdl.org/~shemminger
Jiri Benc wrote :
> On Mon, 05 Dec 2005 13:46:43 -0500, Jeff Garzik wrote:
> > Use the stack that's already in the kernel.
> >
> > Encouraging otherwise hinders continued wireless progress under Linux.
>
> There is nothing like a "802.11 stack" currently in the kernel,
> regardless what James Ketrenos is saying. Sorry.
Hi,
Sorry to intrude in your happy flamefest ;-)
I take offense to what your are saying. There has been many
"802.11 stacks" floating over the years (check my web page). However,
only James went through the pain of getting one in the kernel. That's
not something that should be underestimated.
Now, with respect to the "best" stacks. Some will argue that
the linux-wlan-ng has the most maturity. Some will argue that the
MadWifi stack is used by *BSD. Some will argue that the devicescape
has most features. All this arguing leads to nowhere...
Personally, I'm a pragmatic a heart. The most important thing
to me is end-user support. 99% of our users don't care about advanced
features, they just want their hardware to work out of the box (and
the people who want the advanced features are usually willing to patch
their kernels). They don't care how we do the plumbing internally.
Therefore, for me, a stack is only as good as the number of
drivers that support it. And this is where the devicescape stack is
lacking.
IPW stack :
drivers using it : ipw2100, ipw2200
drivers in progress : rt2x000, bcm430x
potential drivers : r8180, adm8211, hostap
MadWifi stack :
drivers using it : MadWifi (non GPL)
drivers in progress : FreeHAL Atheros, Prism54 softMAC, ural-ralink
DeviceScape stack :
drivers using it : ?
potential drivers : hostap, ipw2100, ipw2200, r8180, adm8211
If you want to use the DeviceScape stack instead of the IPW
stack, my first question is how do you plan to migrate the drivers
using it to the new stack. Currently, people are hard at work
targetting the IPW stack (see above), I don't want them to have to
throw away all their work.
In particular, iwp2*00 are working today in the kernel, and I
expect that they would be migrated to the new stack at the stack
switchover. As both the IPW and the DeviceScape stacks are derived
from the HostAP stack, that should not be too hard.
Also, what puzzle me is that Jouni doesn't seem to have
anounced any plan to port his HostAP driver to his DeviceScape
stack. If there is one driver that should use it, that's HostAP.
Have fun...
Jean
From: Harald Welte <[email protected]>
Date: Tue, 6 Dec 2005 20:40:47 +0530
> I'm also in favor of merging the devicescape code, but I don't see it
> happening without somebody taking care to provide all the required
> levels of interfaces (I see at least three levels of API's that a wireless
> driver would need, depending on how much stuff is done in
> hardware/firmware and how much in software.
I hate to say this, but part of the problem is exactly the fact
that all the implementors have implemented different levels of
hardware-MAC'ness in their wireless products.
Stated even further, things might have been more consistent if M$ had
specified a set of driver interfaces into their own softmac stack,
which I am to understand they are working on now.
So every M$ wireless driver essentially links in their own softmac
stack, if needed.
This has resulted in a complicated situation for an already
complicated technology. Therefore, the fact that it's taking this
long to accomodate all of the cases in the vanilla tree is quite
understandable.
I'm at the point where I frankly don't care which softmac
implementation we go with, but rather I'm more concerned that we pick
_ONE_ and just stick with it, and then adding the necessary interfaces
and infrastructure as different wireless devices require.
Yes, you hear me right, it's more important to agree to one
implementation as the basis, even if it's the worst one currently.
Division of labor is something we simply cannot afford on the wireless
stack at this time.
From: Ben Greear <[email protected]>
Date: Tue, 06 Dec 2005 08:43:39 -0800
> Merge now even if it breaks the current tree?
DCCP is a good counter example, zero --> some functionality is
always preferred. Our DCCP stack is far from being finished, but
it is in there and getting polished and maintained like everything
else in the upstream tree.
And once it's in there, we can review small patches that add new
functionality not this behemouth "here's the whole thing" jumbo
patch that nobody will want to review.
David S. Miller wrote:
> I'm at the point where I frankly don't care which softmac
> implementation we go with, but rather I'm more concerned that we pick
> _ONE_ and just stick with it, and then adding the necessary interfaces
> and infrastructure as different wireless devices require.
>
> Yes, you hear me right, it's more important to agree to one
> implementation as the basis, even if it's the worst one currently.
> Division of labor is something we simply cannot afford on the wireless
> stack at this time.
Agreed.
Jeff
On Tue, Dec 06, 2005 at 02:05:07PM -0500, Jeff Garzik wrote:
> Harald Welte wrote:
> >I also think that there is a lack of knowledge on the architecture of
> >802.11 low-level protocols and drivers among many people (including
> >myself) in the network community. Only this way I can explain why there
> >are always people who claim that the kernel already has a 802.11
> >'stack'.
>
> This last sentence, regardless of the source, is simply playing with words.
I don't think that having clear definitions of certain terms is playing
with words. I don't neccessarily care which words are used, but it's
always useful to have common, well-defined terminology.
I also wouldn't call the TCP code a stack, if it hadn't all the state
engine in it.
> We have 802.11 common code in the kernel, that several drivers are
> using.
Yes.
> Future drivers should modify that common code to suit their
> needs, rather than dropping it and starting from scratch.
I did not state that it has to be replaced. I'm much in favour of
gradual changes myself.
--
- Harald Welte <[email protected]> http://gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
On Tue, Dec 06, 2005 at 02:47:28PM -0800, Jean Tourrilhes wrote:
> DeviceScape stack :
> drivers using it : ?
> potential drivers : hostap, ipw2100, ipw2200, r8180, adm8211
It's mainly used with Atheros chipsets nowadays, but it has been used
with couple of other chipsets, too, including Prism2/2.5/3 and parts of
Host AP driver.
> If you want to use the DeviceScape stack instead of the IPW
> stack, my first question is how do you plan to migrate the drivers
> using it to the new stack. Currently, people are hard at work
> targetting the IPW stack (see above), I don't want them to have to
> throw away all their work.
No matter how this is done, I think it is quite likely that lot of work
has to be thrown away in the sense that it does not end up being in the
kernel. Having n+1 implementations for generic 802.11 functionality is a
good proof of this already being the case. I wouldn't say all work is
thrown away, though, even if lots of code will get thrown away. It is
good to get understanding on what kind of specific requirements each
chipset has in order to be able to accommodate them in the 802.11 design
for Linux.
> In particular, iwp2*00 are working today in the kernel, and I
> expect that they would be migrated to the new stack at the stack
> switchover. As both the IPW and the DeviceScape stacks are derived
> from the HostAP stack, that should not be too hard.
Devicescape code is not actually derived from Host AP code. The user
space component is same (hostapd), but the kernel side is completely new
implementation. As far as IPW is concerned, some parts of it is indeed
derived from Host AP (I can never remember which one, but either TX or
RX; while the other side was new design for some reason).
> Also, what puzzle me is that Jouni doesn't seem to have
> anounced any plan to port his HostAP driver to his DeviceScape
> stack. If there is one driver that should use it, that's HostAP.
Prism2/2.5/3 is getting somewhat old nowadays and I certainly prefer
other chipset designs that do not have a large firmware component
preventing driver/802.11 stack from doing things. Anyway, I have
actually used Devicescape code with Prism2/2.5/3 cards by taking the
low-level parts of the Host AP driver. This just happened to be
two-three years ago and that code has found no use after that, so it has
not been maintained.
I would certainly like to get rid of maintaining many parts of Host AP
driver by getting it to use shared IEEE 802.11 code. I have been quite
occupied with other projects lately which has made it more difficult to
get much progress done here. Anyway, the current goal is to free up my
time by end of this year so that I could start concentrating on the open
source IEEE 802.11 stack for Linux 2.6.
One of the things I would like to do is to make sure that there is
somewhat more complete setup available for testing the Devicescape code
as part of open source development. I'm most familiar with Atheros
chipset nowadays, so I would probably prefer to work with that and maybe
Prism2 (i.e., support from Host AP driver) would be a good example of a
firmware-based design, so those could be the easiest low-level drivers
to get available using Devicescape 802.11 code. Getting ipw2x00 working
with some kind of mix of the 802.11 stacks would be good think to do in
order to make it easier to maintain existing functionality if larger
changes for net/ieee80211 code is desired.
My goal is to get something into kernel tree that allows all types of
chipset designs to benefit from the same implementation of 802.11
functionality. I'm not sure what would be the best way to achieve this
quickly, but I have to admit that I would prefer the design used in
Devicescape implementation over the code that is currently in Linux 2.6
tree.
I need to take a closer look at what could be done to merge the 802.11
code in a way that would not break existing in-tree drivers that are
using net/ieee80211 (i.e., mainly ipw2x00). I'm afraid quite large
changes will be needed to make the current in-tree code more usable for
devices that use very minimal firmware or no firmware at all. In
addition, the issue of dropping AP code from Host AP when merging in the
version that ipw2x00 was using needs more attention when deciding what
kind of design would allow all drivers to work with shared IEEE 802.11
stack.
--
Jouni Malinen PGP id EFC895FA
On Wednesday 07 December 2005 00:19, you wrote:
> From: Harald Welte <[email protected]>
> Date: Tue, 6 Dec 2005 20:40:47 +0530
>
> > I'm also in favor of merging the devicescape code, but I don't see it
> > happening without somebody taking care to provide all the required
> > levels of interfaces (I see at least three levels of API's that a wireless
> > driver would need, depending on how much stuff is done in
> > hardware/firmware and how much in software.
>
> I hate to say this, but part of the problem is exactly the fact
> that all the implementors have implemented different levels of
> hardware-MAC'ness in their wireless products.
>
> Stated even further, things might have been more consistent if M$ had
> specified a set of driver interfaces into their own softmac stack,
> which I am to understand they are working on now.
>
> So every M$ wireless driver essentially links in their own softmac
> stack, if needed.
>
> This has resulted in a complicated situation for an already
> complicated technology. Therefore, the fact that it's taking this
> long to accomodate all of the cases in the vanilla tree is quite
> understandable.
>
> I'm at the point where I frankly don't care which softmac
> implementation we go with, but rather I'm more concerned that we pick
> _ONE_ and just stick with it, and then adding the necessary interfaces
> and infrastructure as different wireless devices require.
>
> Yes, you hear me right, it's more important to agree to one
> implementation as the basis, even if it's the worst one currently.
> Division of labor is something we simply cannot afford on the wireless
> stack at this time.
I agree with you, and that is exactly what we are doing:
We take the existing code and add functionality to it. If the
added functionality is an external module, well, consinder this
as an extra cookie for devices which do not need MAC handling.
--
Greetings Michael.
On Tue, Dec 06, 2005 at 02:47:28PM -0800, jt wrote:
>
> MadWifi stack :
> drivers using it : MadWifi (non GPL)
> drivers in progress : FreeHAL Atheros, Prism54 softMAC, ural-ralink
Sam kindly pointed out that my statement above may be
confusing. It should read :
MadWifi stack :
drivers using it : Atheros (binary blob)
drivers in progress : FreeHAL Atheros, Prism54 softMAC, ural-ralink
Accept my apologies for the error.
Jean
On Tue, Dec 06, 2005 at 11:11:02PM -0800, Jouni Malinen wrote:
> On Tue, Dec 06, 2005 at 02:47:28PM -0800, Jean Tourrilhes wrote:
>
> > DeviceScape stack :
> > drivers using it : ?
> > potential drivers : hostap, ipw2100, ipw2200, r8180, adm8211
>
> It's mainly used with Atheros chipsets nowadays, but it has been used
> with couple of other chipsets, too, including Prism2/2.5/3 and parts of
> Host AP driver.
Well, the burning question is : Is it possible to include your
Atheros driver in the Linux kernel ? Meaning, will it be released, and
will it contain a binary blob ?
If we can't put it in the kernel, it does not bring any thing
new comapre to MadWifi.
> > If you want to use the DeviceScape stack instead of the IPW
> > stack, my first question is how do you plan to migrate the drivers
> > using it to the new stack. Currently, people are hard at work
> > targetting the IPW stack (see above), I don't want them to have to
> > throw away all their work.
>
> No matter how this is done, I think it is quite likely that lot of work
> has to be thrown away in the sense that it does not end up being in the
> kernel. Having n+1 implementations for generic 802.11 functionality is a
> good proof of this already being the case. I wouldn't say all work is
> thrown away, though, even if lots of code will get thrown away. It is
> good to get understanding on what kind of specific requirements each
> chipset has in order to be able to accommodate them in the 802.11 design
> for Linux.
Precisely, which is why I've been pushing as many driver as I
can in the kernel, so that the need is clear and obvious.
> Devicescape code is not actually derived from Host AP code. The user
> space component is same (hostapd), but the kernel side is completely new
> implementation. As far as IPW is concerned, some parts of it is indeed
> derived from Host AP (I can never remember which one, but either TX or
> RX; while the other side was new design for some reason).
Not cool. I usually don't like wrapper, but would it be
possible to wrap the IPW API around DeviceScape ?
> > Also, what puzzle me is that Jouni doesn't seem to have
> > anounced any plan to port his HostAP driver to his DeviceScape
> > stack. If there is one driver that should use it, that's HostAP.
>
> Prism2/2.5/3 is getting somewhat old nowadays and I certainly prefer
> other chipset designs that do not have a large firmware component
> preventing driver/802.11 stack from doing things. Anyway, I have
> actually used Devicescape code with Prism2/2.5/3 cards by taking the
> low-level parts of the Host AP driver. This just happened to be
> two-three years ago and that code has found no use after that, so it has
> not been maintained.
It's old, but because it's the only current card properly
supported under Linux, most people are still using it. And you have
many original Prism2 designs that you can't find with other chipset,
such as the high power version and the CF cards.
> I need to take a closer look at what could be done to merge the 802.11
> code in a way that would not break existing in-tree drivers that are
> using net/ieee80211 (i.e., mainly ipw2x00). I'm afraid quite large
> changes will be needed to make the current in-tree code more usable for
> devices that use very minimal firmware or no firmware at all. In
> addition, the issue of dropping AP code from Host AP when merging in the
> version that ipw2x00 was using needs more attention when deciding what
> kind of design would allow all drivers to work with shared IEEE 802.11
> stack.
Well, the problem is that the more we wait, the more people
are going in other directions. Driver authors are voting with their
feets. I personally welcome your contribution, and I must admit I
don't really know what is the best course of action.
> Jouni Malinen
Jean
On Wed, Dec 07, 2005 at 11:16:22AM -0800, Jean Tourrilhes wrote:
> Well, the burning question is : Is it possible to include your
> Atheros driver in the Linux kernel ? Meaning, will it be released, and
> will it contain a binary blob ?
If that were possible, it would have been released with the IEEE 802.11
code. It has the same issue as madwifi in the sense of depending on
Atheros hal code.
> Not cool. I usually don't like wrapper, but would it be
> possible to wrap the IPW API around DeviceScape ?
I would not even like to think about that.. ;-) I think we are in a
position where we are way more willing to change things than try to
maintain current interfaces in backwards compatible ways.
> > Prism2/2.5/3 is getting somewhat old nowadays and I certainly prefer
> It's old, but because it's the only current card properly
> supported under Linux, most people are still using it. And you have
> many original Prism2 designs that you can't find with other chipset,
> such as the high power version and the CF cards.
Agreed and as such, it is still on my list of things to maintain.
However, this certainly means that it is likely to be of lower priority
than some of the newer chipsets.
--
Jouni Malinen PGP id EFC895FA
On Monday 05 December 2005 14:31, Jiri Benc wrote:
> > And Joseph &
> > friends are writing a module to support softmac cards in that framework,
> > which is one of the most urgently needed things right now, because all
> > the existing softmac frameworks don't work with that code.
>
> And authors of rtl8180 did it too. And authors of adm8211 too.
>
The softmac code that is still in adm8211 is actually based on an early
version of the softmac code that Jouni made for Devicescape. The Devicescape
code does much more useful stuff than the code currently in the kernel. Sure,
I can and have been porting adm8211 to the new kernel stuff.. but it already
works with a much more mature piece of softmac code. I see the use of Intel's
802.11 code as a step backwards.
-Michael Wu
Michael Wu wrote:
> The softmac code that is still in adm8211 is actually based on an early
> version of the softmac code that Jouni made for Devicescape. The Devicescape
> code does much more useful stuff than the code currently in the kernel. Sure,
> I can and have been porting adm8211 to the new kernel stuff.. but it already
> works with a much more mature piece of softmac code. I see the use of Intel's
> 802.11 code as a step backwards.
Then please update the code in the kernel.
Jeff
On Wed, 7 Dec 2005 14:34:22 +0100, Michael Buesch wrote:
> I agree with you, and that is exactly what we are doing:
> We take the existing code and add functionality to it. If the
> added functionality is an external module, well, consinder this
> as an extra cookie for devices which do not need MAC handling.
I understand why you are trying to implement "softmac" as a separate
module. But please take a look at following:
1. Fragmentation. Almost every driver (the exception are devices which
do fragmentation in their firmware) needs to pass fragments to the
device one by one. To handle it effectively, you need fragments to be
passed to your hard_start_xmit sequentially (and not all at once). This
is of course solvable by a separate softmac module, if you implement it
as a layer between ieee80211 and a driver.
2. Devices capable to associate with multiple networks. Such a device
needs to be presented to userspace as several network devices. Again, it
is solvable by a separate softmac module, but you need softmac to be
something like a "proxy" for drivers (because you don't want to deal
with multiple net_devices in the driver).
3. WDS. This is nearly the same as above, but in addition you need a
different code for building 802.11 headers. So this will be built on top
of ieee80211 (because you want to use statistics gathering and so) but
at the same time you will have to reimplement the code responsible for
frame encapsulation in a softmac module. Or, you can add the support for
WDS directly to ieee80211, but then you will add the code for handling
of multiple devices there as well.
4. Access point mode. There is a lot of code needed for AP mode support.
It can be easily implemented in softmac module. But that code will be
used even by drivers for devices with complicated firmware (think about
communication with an userspace AP daemon which won't be easy and should
be consistent among drivers). So in the end (we want AP mode working for
all devices supporting it, don't we?) only a few drivers won't use
softmac module.
Those above are some reasons why I prefer complete 802.11 stack to be in
ieee80211 module. Maybe I'm wrong (and I will be more than happy to
advocate the separate softmac module if it turns out that I'm wrong),
but I'm thinking this way:
- If AP, WDS and so on is implemented in a softmac module, only a very
small amount of drivers won't use that module.
- Such softmac module needs to be implemented as a layer between
ieee80211 and a driver. This will lead to code duplication and will be
less effective.
- If AP, WDS and so on is implemented in ieee80211 module, softmac
module will be very tiny (especially compared to ieee80211 module) and
it is not worth effort to implement it as a separate module.
- (Not a strong argument) Most of drivers will use "softmac" anyway
(it's more than a half of drivers as somebody mentioned earlier).
Please, could you send your opinions to this issues and how to solve
them the best way? It seems that many people agree that separate softmac
module is the way to go, so I'm probably wrong with my conclusions.
Thanks,
--
Jiri Benc
SUSE Labs
On Mon, 05 Dec 2005 14:08:28 -0500, Jeff Garzik wrote:
> > Unfortunately, the only long-term solution is to rewrite completely the
> > current in-kernel ieee80211 code (I would not call it a "stack") or
> > replace it with something another. The current code was written for
> > Intel devices and it doesn't support anything else - so every developer
>
> Patently false.
Maybe some explanation why current in-kernel ieee80211 code needs to be
rewritten will be useful.
1. To support WDS and devices capable to associate with multiple
networks, ieee80211_device needs to be separated to two (or even more,
see below) structures - one hardware dependent (channel and so) and one
link dependent (BSSID etc.).
2. To support AP mode, you need to keep a list of associated stations.
No such list exists now. Furthermore, that list (or that structure) can
be reused also by a client to store information about AP it is
associated to. And - possibly - for a list of APs it can associate to,
i. e. list of found networks. Currently, informations about AP are
hardwired into ieee80211_device structure.
3. Most of WE calls can be handled by ieee80211 itself. The rest should
be propagated to a driver in some easier way than requiring driver to
deal with the whole WE stuff itself. Also, exporting callbacks from
ieee80211 that driver has to set as particular WE handlers seems to be
unnecessary complicated.
4. Callbacks like handle_auth() that were added some time ago are not
needed (for explanation, see corresponding thread on netdev).
5. Some less important things, e. g. current very inefficient code which
deals with found networks.
--
Jiri Benc
SUSE Labs
> 3. Most of WE calls can be handled by ieee80211 itself. The rest should
> be propagated to a driver in some easier way than requiring driver to
> deal with the whole WE stuff itself. Also, exporting callbacks from
> ieee80211 that driver has to set as particular WE handlers seems to be
> unnecessary complicated.
this argument is analogue to the adaptec SAS driver one about the scsi
host structure. ieee80211 should be a LIBRARY of functions that can do
things, the driver should be able to use the library or not at its own
choice. forcibly making the ieee80211 layer deal with the WE's is the
wrong way for this kind of thing, especially since several layers of the
stack will be optional, so it has to be possible for drivers to go
"until this layer I use the ieee80211 library functions, below that my
own".
On Thu, 08 Dec 2005 13:12:44 +0100, Arjan van de Ven wrote:
> this argument is analogue to the adaptec SAS driver one about the scsi
> host structure. ieee80211 should be a LIBRARY of functions that can do
> things,
Unfortunately, it is not possible to implement ieee80211 as a library,
because you need fragmentation, WDS and such funny stuff, which require
ieee80211 (or possibly "softmac") to be a layer between networking core
and a driver.
> the driver should be able to use the library or not at its own
> choice. forcibly making the ieee80211 layer deal with the WE's is the
> wrong way for this kind of thing, especially since several layers of the
> stack will be optional, so it has to be possible for drivers to go
> "until this layer I use the ieee80211 library functions, below that my
> own".
Making ieee80211 (not any possible layer on top of it, but ieee80211) to
handle part of WE for drivers and reexport (or whatever) the rest to
drivers will not take off the possibility to use WE by others. Where is
the problem?
The goal is to make life simpler for drivers. Dealing with WE is not
easy and even if everything which ieee80211 will do is allowing drivers
to register their handlers during allocation of ieee80211_device by
simply setting pointers to their functions (in ieee80211_device or
somewhere), it will be easier (see the thread at
http://oss.sgi.com/projects/netdev/archive/2004-06/msg00463.html to
understand what I mean).
But I agree this is something we can argue about. This is not the main
reason I gave in my mail, so if you still don't agree with me in this
point, please imagine I didn't mention it - it's not something I want to
argue about now and the explanation I gave is I think valid even without
this point.
Thanks,
--
Jiri Benc
SUSE Labs
On Mon, 2005-12-05 at 20:11 +0100, Jiri Benc wrote:
> That results were implemented (patches were sent
> and not accepted).
May be should you submit your patches to the right persons:
see /usr/src/linux/MAINTENERS.
I dont know where did you submit yours, but that's just a suggestion.
--
A powerfull GroupWare, CMS, CRM, ECM: CPS (Open Source & GPL).
Opengroupware, SPIP, Plone, PhpBB, JetSpeed... are good: CPS is better.
http://www.cps-project.org for downloads & documentation.
Free hosting of CPS groupware: http://www.objectis.org.