* Re: [Bcm43xx-dev] wireless: the contenders
2006-01-18 20:06 wireless: the contenders John W. Linville
@ 2006-01-18 20:19 ` Michael Buesch
2006-01-18 20:25 ` John W. Linville
2006-01-18 20:36 ` Jeff Garzik
` (4 subsequent siblings)
5 siblings, 1 reply; 18+ messages in thread
From: Michael Buesch @ 2006-01-18 20:19 UTC (permalink / raw)
To: John W. Linville; +Cc: netdev, linux-kernel, jbenc, softmac-dev, bcm43xx-dev
[-- Attachment #1: Type: text/plain, Size: 618 bytes --]
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.
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [Bcm43xx-dev] wireless: the contenders
2006-01-18 20:19 ` [Bcm43xx-dev] " Michael Buesch
@ 2006-01-18 20:25 ` John W. Linville
0 siblings, 0 replies; 18+ messages in thread
From: John W. Linville @ 2006-01-18 20:25 UTC (permalink / raw)
To: Michael Buesch; +Cc: netdev, linux-kernel, jbenc, softmac-dev, bcm43xx-dev
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
linville@tuxdriver.com
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: wireless: the contenders
2006-01-18 20:06 wireless: the contenders John W. Linville
2006-01-18 20:19 ` [Bcm43xx-dev] " Michael Buesch
@ 2006-01-18 20:36 ` Jeff Garzik
2006-01-18 20:48 ` John W. Linville
2006-01-19 0:19 ` [Bcm43xx-dev] " Johannes Berg
` (3 subsequent siblings)
5 siblings, 1 reply; 18+ messages in thread
From: Jeff Garzik @ 2006-01-18 20:36 UTC (permalink / raw)
To: John W. Linville; +Cc: netdev, linux-kernel, jbenc, softmac-dev, bcm43xx-dev
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
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: wireless: the contenders
2006-01-18 20:36 ` Jeff Garzik
@ 2006-01-18 20:48 ` John W. Linville
2006-01-18 20:52 ` Jeff Garzik
0 siblings, 1 reply; 18+ messages in thread
From: John W. Linville @ 2006-01-18 20:48 UTC (permalink / raw)
To: Jeff Garzik; +Cc: netdev, linux-kernel, jbenc, softmac-dev, bcm43xx-dev
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
linville@tuxdriver.com
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: wireless: the contenders
2006-01-18 20:48 ` John W. Linville
@ 2006-01-18 20:52 ` Jeff Garzik
0 siblings, 0 replies; 18+ messages in thread
From: Jeff Garzik @ 2006-01-18 20:52 UTC (permalink / raw)
To: netdev, linux-kernel, jbenc, softmac-dev, bcm43xx-dev
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
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [Bcm43xx-dev] wireless: the contenders
2006-01-18 20:06 wireless: the contenders John W. Linville
2006-01-18 20:19 ` [Bcm43xx-dev] " Michael Buesch
2006-01-18 20:36 ` Jeff Garzik
@ 2006-01-19 0:19 ` Johannes Berg
2006-01-19 15:27 ` John W. Linville
2006-01-22 11:57 ` [PATCH] trivial fix Denis Vlasenko
` (2 subsequent siblings)
5 siblings, 1 reply; 18+ messages in thread
From: Johannes Berg @ 2006-01-19 0:19 UTC (permalink / raw)
To: John W. Linville; +Cc: netdev, linux-kernel, jbenc, softmac-dev, bcm43xx-dev
[-- Attachment #1: Type: text/plain, Size: 488 bytes --]
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
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 832 bytes --]
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [Bcm43xx-dev] wireless: the contenders
2006-01-19 0:19 ` [Bcm43xx-dev] " Johannes Berg
@ 2006-01-19 15:27 ` John W. Linville
0 siblings, 0 replies; 18+ messages in thread
From: John W. Linville @ 2006-01-19 15:27 UTC (permalink / raw)
To: Johannes Berg; +Cc: netdev, linux-kernel, jbenc, softmac-dev, bcm43xx-dev
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
linville@tuxdriver.com
^ permalink raw reply [flat|nested] 18+ messages in thread
* [PATCH] trivial fix
2006-01-18 20:06 wireless: the contenders John W. Linville
` (2 preceding siblings ...)
2006-01-19 0:19 ` [Bcm43xx-dev] " Johannes Berg
@ 2006-01-22 11:57 ` Denis Vlasenko
2006-01-22 11:59 ` [PATCH] ieee80211_rx_any: filter out packets, call ieee80211_rx or ieee80211_rx_mgt Denis Vlasenko
2006-01-22 12:04 ` Denis Vlasenko
5 siblings, 0 replies; 18+ messages in thread
From: Denis Vlasenko @ 2006-01-22 11:57 UTC (permalink / raw)
To: John W. Linville; +Cc: netdev, linux-kernel, jbenc, softmac-dev
[-- Attachment #1: Type: text/plain, Size: 116 bytes --]
Patch fixes misplaced (). Diffed against wireless-2.6.git
Signed-off-by: Denis Vlasenko <vda@ilport.com.ua>
--
vda
[-- Attachment #2: trivial.patch --]
[-- Type: text/x-diff, Size: 761 bytes --]
diff -urpN softmac-snapshot/net/ieee80211/ieee80211_rx.c softmac-snapshot.1/net/ieee80211/ieee80211_rx.c
--- softmac-snapshot/net/ieee80211/ieee80211_rx.c Wed Jan 18 07:27:03 2006
+++ softmac-snapshot.1/net/ieee80211/ieee80211_rx.c Sun Jan 22 13:12:30 2006
@@ -562,7 +562,7 @@ int ieee80211_rx(struct ieee80211_device
/* skb: hdr + (possibly fragmented) plaintext payload */
// PR: FIXME: hostap has additional conditions in the "if" below:
// ieee->host_decrypt && (fc & IEEE80211_FCTL_PROTECTED) &&
- if ((frag != 0 || (fc & IEEE80211_FCTL_MOREFRAGS))) {
+ if ((frag != 0) || (fc & IEEE80211_FCTL_MOREFRAGS)) {
int flen;
struct sk_buff *frag_skb = ieee80211_frag_cache_get(ieee, hdr);
IEEE80211_DEBUG_FRAG("Rx Fragment received (%u)\n", frag);
^ permalink raw reply [flat|nested] 18+ messages in thread
* [PATCH] ieee80211_rx_any: filter out packets, call ieee80211_rx or ieee80211_rx_mgt
2006-01-18 20:06 wireless: the contenders John W. Linville
` (3 preceding siblings ...)
2006-01-22 11:57 ` [PATCH] trivial fix Denis Vlasenko
@ 2006-01-22 11:59 ` Denis Vlasenko
[not found] ` <200601221408.45486.vda@ilport.com.ua>
2006-01-22 12:04 ` Denis Vlasenko
5 siblings, 1 reply; 18+ messages in thread
From: Denis Vlasenko @ 2006-01-22 11:59 UTC (permalink / raw)
To: John W. Linville; +Cc: netdev, linux-kernel, jbenc, softmac-dev, bcm43xx-dev
[-- Attachment #1: Type: text/plain, Size: 325 bytes --]
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 <vda@ilport.com.ua>
--
vda
[-- Attachment #2: rx.patch --]
[-- Type: text/x-diff, Size: 2655 bytes --]
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.
diff -urpN softmac-snapshot/net/ieee80211/ieee80211_rx.c softmac-snapshot.1/net/ieee80211/ieee80211_rx.c
--- softmac-snapshot/net/ieee80211/ieee80211_rx.c Wed Jan 18 07:27:03 2006
+++ softmac-snapshot.1/net/ieee80211/ieee80211_rx.c Sun Jan 22 13:12:30 2006
@@ -758,6 +758,79 @@ int ieee80211_rx(struct ieee80211_device
/* Returning 0 indicates to caller that we have not handled the SKB--
* so it is still allocated and can be used again by underlying
* hardware as a DMA target */
+ return 0;
+}
+
+/* Kernel doesn't have it, why? */
+static inline int is_mcast_or_bcast_ether_addr(const u8 *addr)
+{
+ return (0x01 & addr[0]);
+}
+
+/* Filter out unrelated packets, call ieee80211_rx[_mgt] */
+int ieee80211_rx_any(struct ieee80211_device *ieee,
+ struct sk_buff *skb, struct ieee80211_rx_stats *stats)
+{
+ struct ieee80211_hdr_4addr *hdr;
+ int is_packet_for_us;
+ u16 fc;
+
+ if (ieee->iw_mode == IW_MODE_MONITOR)
+ return ieee80211_rx(ieee, skb, stats) ? 0 : -EINVAL;
+
+ hdr = (struct ieee80211_hdr_4addr *)skb->data;
+ fc = le16_to_cpu(hdr->frame_ctl);
+
+ switch (fc & IEEE80211_FCTL_FTYPE) {
+ case IEEE80211_FTYPE_MGMT:
+ return ieee80211_rx_mgt(ieee, hdr, stats);
+ case IEEE80211_FTYPE_DATA:
+ break;
+ case IEEE80211_FTYPE_CTL:
+ return 0;
+ default:
+ return -EINVAL;
+ }
+
+ 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;
+ /* our BSS */
+ else if (memcmp(hdr->addr3, ieee->bssid, ETH_ALEN) == 0) {
+ /* to us */
+ if (memcmp(hdr->addr1, ieee->dev->dev_addr, ETH_ALEN) == 0)
+ is_packet_for_us = 1;
+ /* mcast */
+ else if (is_mcast_or_bcast_ether_addr(hdr->addr1))
+ is_packet_for_us = 1;
+ }
+ break;
+ case IW_MODE_INFRA:
+ /* promisc: get all */
+ if (ieee->dev->flags & IFF_PROMISC)
+ is_packet_for_us = 1;
+ /* our BSS (== from our AP) */
+ else if (memcmp(hdr->addr2, ieee->bssid, ETH_ALEN) == 0) {
+ /* to us */
+ if (memcmp(hdr->addr1, ieee->dev->dev_addr, ETH_ALEN) == 0)
+ is_packet_for_us = 1;
+ /* mcast */
+ else if (is_mcast_or_bcast_ether_addr(hdr->addr1))
+ /* not our own packet bcasted from AP */
+ if (memcmp(hdr->addr3, ieee->dev->dev_addr, ETH_ALEN))
+ is_packet_for_us = 1;
+ }
+ break;
+ default:
+ /* ? */
+ break;
+ }
+
+ if (is_packet_for_us)
+ return (ieee80211_rx(ieee, skb, stats) ? 0 : -EINVAL);
return 0;
}
^ permalink raw reply [flat|nested] 18+ messages in thread
* [PATCH] ieee80211_rx_any: filter out packets, call ieee80211_rx or ieee80211_rx_mgt
2006-01-18 20:06 wireless: the contenders John W. Linville
` (4 preceding siblings ...)
2006-01-22 11:59 ` [PATCH] ieee80211_rx_any: filter out packets, call ieee80211_rx or ieee80211_rx_mgt Denis Vlasenko
@ 2006-01-22 12:04 ` Denis Vlasenko
2006-01-22 13:32 ` Patrick McHardy
2006-01-23 14:32 ` [softmac-dev] " Johannes Berg
5 siblings, 2 replies; 18+ messages in thread
From: Denis Vlasenko @ 2006-01-22 12:04 UTC (permalink / raw)
To: John W. Linville; +Cc: netdev, linux-kernel, jbenc, softmac-dev, bcm43xx-dev
[-- Attachment #1: Type: text/plain, Size: 323 bytes --]
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 <vda@ilport.com.ua>
--
vda
[-- Attachment #2: rx.patch --]
[-- Type: text/x-diff, Size: 2456 bytes --]
diff -urp softmac-snapshot/net/ieee80211/ieee80211_rx.c softmac-snapshot.1/net/ieee80211/ieee80211_rx.c
--- softmac-snapshot/net/ieee80211/ieee80211_rx.c Wed Jan 18 07:27:03 2006
+++ softmac-snapshot.1/net/ieee80211/ieee80211_rx.c Sun Jan 22 14:01:43 2006
@@ -758,6 +758,80 @@ int ieee80211_rx(struct ieee80211_device
/* Returning 0 indicates to caller that we have not handled the SKB--
* so it is still allocated and can be used again by underlying
* hardware as a DMA target */
+ return 0;
+}
+
+/* Kernel doesn't have it, why? */
+static inline int is_mcast_or_bcast_ether_addr(const u8 *addr)
+{
+ return (0x01 & addr[0]);
+}
+
+/* Filter out unrelated packets, call ieee80211_rx[_mgt] */
+int ieee80211_rx_any(struct ieee80211_device *ieee,
+ struct sk_buff *skb, struct ieee80211_rx_stats *stats)
+{
+ struct ieee80211_hdr_4addr *hdr;
+ int is_packet_for_us;
+ u16 fc;
+
+ if (ieee->iw_mode == IW_MODE_MONITOR)
+ return ieee80211_rx(ieee, skb, stats) ? 0 : -EINVAL;
+
+ 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;
+ case IEEE80211_FTYPE_DATA:
+ break;
+ case IEEE80211_FTYPE_CTL:
+ return 0;
+ default:
+ return -EINVAL;
+ }
+
+ 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;
+ /* our BSS */
+ else if (memcmp(hdr->addr3, ieee->bssid, ETH_ALEN) == 0) {
+ /* to us */
+ if (memcmp(hdr->addr1, ieee->dev->dev_addr, ETH_ALEN) == 0)
+ is_packet_for_us = 1;
+ /* mcast */
+ else if (is_mcast_or_bcast_ether_addr(hdr->addr1))
+ is_packet_for_us = 1;
+ }
+ break;
+ case IW_MODE_INFRA:
+ /* promisc: get all */
+ if (ieee->dev->flags & IFF_PROMISC)
+ is_packet_for_us = 1;
+ /* our BSS (== from our AP) */
+ else if (memcmp(hdr->addr2, ieee->bssid, ETH_ALEN) == 0) {
+ /* to us */
+ if (memcmp(hdr->addr1, ieee->dev->dev_addr, ETH_ALEN) == 0)
+ is_packet_for_us = 1;
+ /* mcast */
+ else if (is_mcast_or_bcast_ether_addr(hdr->addr1))
+ /* not our own packet bcasted from AP */
+ if (memcmp(hdr->addr3, ieee->dev->dev_addr, ETH_ALEN))
+ is_packet_for_us = 1;
+ }
+ break;
+ default:
+ /* ? */
+ break;
+ }
+
+ if (is_packet_for_us)
+ return (ieee80211_rx(ieee, skb, stats) ? 0 : -EINVAL);
return 0;
}
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH] ieee80211_rx_any: filter out packets, call ieee80211_rx or ieee80211_rx_mgt
2006-01-22 12:04 ` Denis Vlasenko
@ 2006-01-22 13:32 ` Patrick McHardy
2006-01-23 14:32 ` [softmac-dev] " Johannes Berg
1 sibling, 0 replies; 18+ messages in thread
From: Patrick McHardy @ 2006-01-22 13:32 UTC (permalink / raw)
To: Denis Vlasenko
Cc: John W. Linville, netdev, linux-kernel, jbenc, softmac-dev, bcm43xx-dev
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]);
}
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [softmac-dev] [PATCH] ieee80211_rx_any: filter out packets, call ieee80211_rx or ieee80211_rx_mgt
2006-01-22 12:04 ` Denis Vlasenko
2006-01-22 13:32 ` Patrick McHardy
@ 2006-01-23 14:32 ` Johannes Berg
2006-01-23 19:00 ` Stefan Rompf
` (2 more replies)
1 sibling, 3 replies; 18+ messages in thread
From: Johannes Berg @ 2006-01-23 14:32 UTC (permalink / raw)
To: Denis Vlasenko
Cc: John W. Linville, jbenc, netdev, softmac-dev, linux-kernel, bcm43xx-dev
[-- Attachment #1: Type: text/plain, Size: 915 bytes --]
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
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 832 bytes --]
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [softmac-dev] [PATCH] ieee80211_rx_any: filter out packets, call ieee80211_rx or ieee80211_rx_mgt
2006-01-23 14:32 ` [softmac-dev] " Johannes Berg
@ 2006-01-23 19:00 ` Stefan Rompf
2006-01-24 8:06 ` [Bcm43xx-dev] " Denis Vlasenko
2006-01-25 15:44 ` Stuffed Crust
2 siblings, 0 replies; 18+ messages in thread
From: Stefan Rompf @ 2006-01-23 19:00 UTC (permalink / raw)
To: Johannes Berg
Cc: Denis Vlasenko, John W. Linville, jbenc, netdev, softmac-dev,
linux-kernel, bcm43xx-dev
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
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [Bcm43xx-dev] Re: [softmac-dev] [PATCH] ieee80211_rx_any: filter out packets, call ieee80211_rx or ieee80211_rx_mgt
2006-01-23 14:32 ` [softmac-dev] " Johannes Berg
2006-01-23 19:00 ` Stefan Rompf
@ 2006-01-24 8:06 ` Denis Vlasenko
2006-01-25 15:44 ` Stuffed Crust
2 siblings, 0 replies; 18+ messages in thread
From: Denis Vlasenko @ 2006-01-24 8:06 UTC (permalink / raw)
To: bcm43xx-dev
Cc: Johannes Berg, John W. Linville, jbenc, netdev, softmac-dev,
linux-kernel
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
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [softmac-dev] [PATCH] ieee80211_rx_any: filter out packets, call ieee80211_rx or ieee80211_rx_mgt
2006-01-23 14:32 ` [softmac-dev] " Johannes Berg
2006-01-23 19:00 ` Stefan Rompf
2006-01-24 8:06 ` [Bcm43xx-dev] " Denis Vlasenko
@ 2006-01-25 15:44 ` Stuffed Crust
2006-01-26 10:25 ` Denis Vlasenko
2 siblings, 1 reply; 18+ messages in thread
From: Stuffed Crust @ 2006-01-25 15:44 UTC (permalink / raw)
To: Johannes Berg
Cc: Denis Vlasenko, John W. Linville, jbenc, netdev, softmac-dev,
linux-kernel, bcm43xx-dev
[-- Attachment #1: Type: text/plain, Size: 764 bytes --]
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.
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [softmac-dev] [PATCH] ieee80211_rx_any: filter out packets, call ieee80211_rx or ieee80211_rx_mgt
2006-01-25 15:44 ` Stuffed Crust
@ 2006-01-26 10:25 ` Denis Vlasenko
0 siblings, 0 replies; 18+ messages in thread
From: Denis Vlasenko @ 2006-01-26 10:25 UTC (permalink / raw)
To: Stuffed Crust
Cc: Johannes Berg, John W. Linville, jbenc, netdev, softmac-dev,
linux-kernel, bcm43xx-dev
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
^ permalink raw reply [flat|nested] 18+ messages in thread