First, the news everyone will like. Thanks to the kernel.org team
I now have a place to publish a wireless tree:
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6.git
The tree there has a number of branches, so many that you need
a scorecard...
Branches
--------
The "master" branch of that tree is (mostly) up-to-date w/ Linus, plus
changes I recently sent to Jeff. Those changes are also available on
the "upstream-jgarzik" branch, but it is frozen to when I requested
Jeff's pull.
The tree also has "softmac" and "dscape" branches. The "softmac"
branch includes the Johannes Berg softmac code as well as the the
BCM43xx driver based upon that code. The "dscape" branch includes
the DeviceScape patches from Jiri Benc as well as the BCM43xx driver
ported to the DeviceScape stack.
The fact that the BCM43xx team has ported their driver to both stacks
provides us an excellent opportunity for some objective, "apples to
apples" comparisons between the major stacks. I would like to take
this opportunity to thank them for taking the trouble to do that work
and to make both versions available for comparison.
BTW, those trying to actually use the dscape code will want to poke
around Jiri's kernel.org directories:
http://www.kernel.org/pub/linux/kernel/people/jbenc/
Jiri has some information there that will likely be useful to you.
The other branches are for administrative purposes, and can mostly
be ignored.
Patches
-------
Along with bugfixes and enhancements to the current code (which will
be targeting the "master" branch), I would like to see driver and
stack patches for both the "softmac" and "dscape" branches. I would
like to see what is really out there before making a final call on
which stack to adopt permanently.
If you have an out-of-tree driver which targets either (or both)
stacks, please send patches. If you are working on porting an
in-kernel driver to one of these stacks (either from the other stack
or from its private stack), please send patches. If you have fixes
or enhancements pending for either of these stacks, then please
send patches.
Don't waste any time with your patches. There is good reason to make
a decision quickly, and plenty of pressure to do so. Your code could
be a significant factor in making that decision.
I know that many of you believe that this approach is a bad idea,
for a variety of reasons. I find those arguments valid, and
even persuasive. The point of this exercise is NOT to push two
stacks forward into Linus' kernel. The point is to catalog the
true state of affairs and to collect as large a wireless driver
codebase as possible. You might think of this as a Domesday Book
(http://en.wikipedia.org/wiki/Domesday_Book) for Linux wireless.
Summary
-------
Hopefully the act of collecting these patches will also allow the less
motivated among us to have a chance to evaluate the stacks involved.
There are bound to be some wise and skilled kernel hackers out there
that are just a little too busy to track-down all these patches
themselves... :-)
I appreciate all the commentary and ideas expressed over the past
couple of weeks. I also think the driver writers are doing a good
job with what they've been given so far. I hope this helps to bring
the driver guys in out of the cold, and to put some weight behind
the discussions of where we need to go.
Thanks,
John
--
John W. Linville
[email protected]
On Wednesday 18 January 2006 21:06, John W. Linville wrote:
> The tree also has "softmac" and "dscape" branches. The "softmac"
> branch includes the Johannes Berg softmac code as well as the the
> BCM43xx driver based upon that code. The "dscape" branch includes
> the DeviceScape patches from Jiri Benc as well as the BCM43xx driver
> ported to the DeviceScape stack.
Are you going to keep it synced with our repository?
I think it should be possible to automatically send patches for
every change in our tree to you. I am not 100% sure (but 99%).
I will look at it tomorrow.
--
Greetings Michael.
On Wed, Jan 18, 2006 at 09:19:20PM +0100, Michael Buesch wrote:
> On Wednesday 18 January 2006 21:06, John W. Linville wrote:
> > The tree also has "softmac" and "dscape" branches. The "softmac"
> > branch includes the Johannes Berg softmac code as well as the the
> > BCM43xx driver based upon that code. The "dscape" branch includes
> > the DeviceScape patches from Jiri Benc as well as the BCM43xx driver
> > ported to the DeviceScape stack.
>
> Are you going to keep it synced with our repository?
> I think it should be possible to automatically send patches for
> every change in our tree to you. I am not 100% sure (but 99%).
> I will look at it tomorrow.
If you'll send me patches, I'll apply them...
John
P.S. Please do what you can to make them comply w/ kernel patch
posting conventions:
http://linux.yyz.us/patch-format.html
--
John W. Linville
[email protected]
John W. Linville wrote:
> First, the news everyone will like. Thanks to the kernel.org team
> I now have a place to publish a wireless tree:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6.git
>
> The tree there has a number of branches, so many that you need
> a scorecard...
>
> Branches
> --------
>
> The "master" branch of that tree is (mostly) up-to-date w/ Linus, plus
> changes I recently sent to Jeff. Those changes are also available on
> the "upstream-jgarzik" branch, but it is frozen to when I requested
> Jeff's pull.
Minor git administrative note... In my trees, the 'master' branch is
always vanilla Linus, and I never ever apply my own changes to it. This
enables commands such as
git diff master..upstream > patch
git log master..upstream > log.txt
git log master..upstream | git shortlog > shortlog.txt
to work as expected.
Typically I do not update 'master' unless I am also updating 'upstream'
with vanilla Linus changes, in order to avoid screwing up the tree heads
and the diff. When I do update 'master' from 'upstream', it is a
trivial matter to then pull those changes into 'upstream':
git checkout -f upstream
git pull . master
Regards,
Jeff
On Wed, Jan 18, 2006 at 03:36:59PM -0500, Jeff Garzik wrote:
> John W. Linville wrote:
> >The "master" branch of that tree is (mostly) up-to-date w/ Linus, plus
> >changes I recently sent to Jeff. Those changes are also available on
> >the "upstream-jgarzik" branch, but it is frozen to when I requested
> >Jeff's pull.
> Typically I do not update 'master' unless I am also updating 'upstream'
> with vanilla Linus changes, in order to avoid screwing up the tree heads
> and the diff. When I do update 'master' from 'upstream', it is a
> trivial matter to then pull those changes into 'upstream':
Good info...thanks!
FWIW, I have an "origin" branch that corresponds to Linus' tree.
I think that probably enables the same kind of usage as you noted...?
Thanks,
John
--
John W. Linville
[email protected]
On Wed, Jan 18, 2006 at 03:48:49PM -0500, John W. Linville wrote:
> On Wed, Jan 18, 2006 at 03:36:59PM -0500, Jeff Garzik wrote:
> > John W. Linville wrote:
>
> > >The "master" branch of that tree is (mostly) up-to-date w/ Linus, plus
> > >changes I recently sent to Jeff. Those changes are also available on
> > >the "upstream-jgarzik" branch, but it is frozen to when I requested
> > >Jeff's pull.
>
> > Typically I do not update 'master' unless I am also updating 'upstream'
> > with vanilla Linus changes, in order to avoid screwing up the tree heads
> > and the diff. When I do update 'master' from 'upstream', it is a
> > trivial matter to then pull those changes into 'upstream':
>
> Good info...thanks!
>
> FWIW, I have an "origin" branch that corresponds to Linus' tree.
> I think that probably enables the same kind of usage as you noted...?
Yep, it doesn't matter what you call it.
I avoid 'origin' since a 'git pull' without arguments will automatically
update that (and possibly master too).
But it's just a name. Any branch with vanilla Linus tree in it will
achieve the behavior I described.
Jeff
On Wed, 2006-01-18 at 15:06 -0500, John W. Linville wrote:
> The tree also has "softmac" and "dscape" branches. The "softmac"
> branch includes the Johannes Berg softmac code as well as the the
> BCM43xx driver based upon that code.
I guess that branch also contains my enhancements to ieee80211, do you
have any intentions of pulling those over to your upstream tree? I
suppose I should rather post them as a series of patches to netdev for
wider consideration.
johannes
On Thu, Jan 19, 2006 at 01:19:40AM +0100, Johannes Berg wrote:
> On Wed, 2006-01-18 at 15:06 -0500, John W. Linville wrote:
>
> > The tree also has "softmac" and "dscape" branches. The "softmac"
> > branch includes the Johannes Berg softmac code as well as the the
> > BCM43xx driver based upon that code.
>
> I guess that branch also contains my enhancements to ieee80211, do you
> have any intentions of pulling those over to your upstream tree? I
> suppose I should rather post them as a series of patches to netdev for
> wider consideration.
I pulled from the softmac-2.6.git tree. I think there was ieee80211
stuff in there as well, but you probably know better than I do. :-)
The history in your tree isn't formatted properly for the kernel,
so something would have to be done before that went upstream anyway.
I think it would be best for you to post the patches to netdev,
including patches covering softmac if you are so inclined. Please be
sure to follow kernel patch posting conventions:
http://linux.yyz.us/patch-format.html
Thanks,
John
--
John W. Linville
[email protected]
Patch fixes misplaced (). Diffed against wireless-2.6.git
Signed-off-by: Denis Vlasenko <[email protected]>
--
vda
bcm43xx_rx() contains code to filter out packets from
foreign BSSes and decide whether to call ieee80211_rx
or ieee80211_rx_mgt. This is not bcm specific.
Patch adapts that code and adds it to softmac
as ieee80211_rx_any() function.
Diffed against wireless-2.6.git
Signed-off-by: Denis Vlasenko <[email protected]>
--
vda
bcm43xx_rx() contains code to filter out packets from
foreign BSSes and decide whether to call ieee80211_rx
or ieee80211_rx_mgt. This is not bcm specific.
Patch adapts that code and adds it to 80211
as ieee80211_rx_any() function.
Diffed against wireless-2.6.git
Signed-off-by: Denis Vlasenko <[email protected]>
--
vda
Denis Vlasenko wrote:
> bcm43xx_rx() contains code to filter out packets from
> foreign BSSes and decide whether to call ieee80211_rx
> or ieee80211_rx_mgt. This is not bcm specific.
>
> +/* Kernel doesn't have it, why? */
> +static inline int is_mcast_or_bcast_ether_addr(const u8 *addr)
> +{
> + return (0x01 & addr[0]);
> +}
The same function exists in include/linux/etherdevice.h:
static inline int is_multicast_ether_addr(const u8 *addr)
{
return (0x01 & addr[0]);
}
On Sun, 2006-01-22 at 14:04 +0200, Denis Vlasenko wrote:
> + hdr = (struct ieee80211_hdr_4addr *)skb->data;:
> + fc = le16_to_cpu(hdr->frame_ctl);:
> +:
> + switch (fc & IEEE80211_FCTL_FTYPE) {:
> + case IEEE80211_FTYPE_MGMT:
> + ieee80211_rx_mgt(ieee, hdr, stats);:
> + return 0;:
Shouldn't you BSS-filter management packets too?
> + is_packet_for_us = 0;:
> + switch (ieee->iw_mode) {:
> + case IW_MODE_ADHOC:
> + /* promisc: get all */
> + if (ieee->dev->flags & IFF_PROMISC):
> + is_packet_for_us = 1;
And I still think BSS-filtering is correct even in the promisc case. Any
other opinions why either way is right or not? [I think we should filter
because upper layers won't know the packet wasn't for us if it was
broadcast in another BSSID]
johannes
Am Montag 23 Januar 2006 15:32 schrieb Johannes Berg:
> Shouldn't you BSS-filter management packets too?
no, management packets are used to populate f.e. scanning results.
Stefan
On Monday 23 January 2006 16:32, Johannes Berg wrote:
> On Sun, 2006-01-22 at 14:04 +0200, Denis Vlasenko wrote:
> > + hdr = (struct ieee80211_hdr_4addr *)skb->data;:
> > + fc = le16_to_cpu(hdr->frame_ctl);:
> > +:
> > + switch (fc & IEEE80211_FCTL_FTYPE) {:
> > + case IEEE80211_FTYPE_MGMT:
> > + ieee80211_rx_mgt(ieee, hdr, stats);:
> > + return 0;:
>
> Shouldn't you BSS-filter management packets too?
>
> > + is_packet_for_us = 0;:
> > + switch (ieee->iw_mode) {:
> > + case IW_MODE_ADHOC:
> > + /* promisc: get all */
> > + if (ieee->dev->flags & IFF_PROMISC):
> > + is_packet_for_us = 1;
>
> And I still think BSS-filtering is correct even in the promisc case. Any
> other opinions why either way is right or not? [I think we should filter
> because upper layers won't know the packet wasn't for us if it was
> broadcast in another BSSID]
In wired networks promisc literally means "receive all packets", right?
But for wireless, maybe we should filter them out, or else running tcpdump
on the iface will force us to listen to ARP packets from unrelated networks.
That would be rather surprising and disrupting.
--
vda
On Mon, Jan 23, 2006 at 03:32:32PM +0100, Johannes Berg wrote:
> Shouldn't you BSS-filter management packets too?
Filtering on BSSID is necessary for management frames, especially when
multicast management frames are thrown into the mix.
For example, STAs are supposed to respect broadcast disassoc/deauth
messages, but of course should ignore them if they're not destined for
the local BSSID.
The only extra-BSS management frames that should not be dropped are are
beacons and probe responses. That said, probe responses are directed so
our A1 (RA) filter will probably drop the frame if it is not destined
for us.
- Solomon
--
Solomon Peachy ICQ: 1318344
Melbourne, FL
Quidquid latine dictum sit, altum viditur.
On Wednesday 25 January 2006 17:44, Stuffed Crust wrote:
> On Mon, Jan 23, 2006 at 03:32:32PM +0100, Johannes Berg wrote:
> > Shouldn't you BSS-filter management packets too?
>
> Filtering on BSSID is necessary for management frames, especially when
> multicast management frames are thrown into the mix.
ieee80211_rx_mgt can do any filtering necessary.
Foreign mgmt packets, if properly used, can provide us with constantly
updated info about local wireless neighborhood: available Ad-hoc
networks and BSSes, signal quality of APs etc. Something resembling
constantly running scan. For example, acx driver does exactly this.
Note that typically mgmt traffic is rather low and processing it
(instead of dropping) won't add much overhead.
> For example, STAs are supposed to respect broadcast disassoc/deauth
> messages, but of course should ignore them if they're not destined for
> the local BSSID.
This filtering can (should) be done in ieee80211_rx_mgt.
> The only extra-BSS management frames that should not be dropped are are
> beacons and probe responses. That said, probe responses are directed so
> our A1 (RA) filter will probably drop the frame if it is not destined
> for us.
--
vda