Driver bcm43xx is being ported from using SoftMAC to mac80211. For rewiew,
this series of patches is being prepared; however, the final patch will be
a single entity so that compilation during bisection will not break.
The contents of the various pieces are as follows:
1. Kconfig, Makefile and the main header file.
2. bcm43xx_debugfs.c and bcm43xx_debugfs.h
3. bcm43xx_dma.c and bcm43xx_dma.h
4. bcm43xx_ilt.c, bcm43xx_ilt.h, bcm43xx_leds.c and bcm43xx_leds.h
5. bcm43xx_main.c and bcm43xx_main.h
6. bcm43xx_phy.c and bcm43xx_phy.h
7. bcm43xx_pio.c and bcm43xx_pio.h
8. bcm43xx_radio.c and bcm43xx_radio.h
9. bcm43xx_sysfs.c and bcm43xx_sysfs.h
10: bcm43xx_xmit.c and bcm43xx_xmit.h
In general, this port consists of taking the files bcm43xx_phy and
bcm43xx_radio from the softmac driver and converting them to work with
the files from the mac80211 version, which has been back-converted to
use V3 firmware.
Larry
On Monday 06 August 2007 10:05, John W. Linville wrote:
> - if (sdata->type != IEEE80211_IF_TYPE_STA) {
> + if (sdata->type != IEEE80211_IF_TYPE_STA ||
> + (is_multicast_ether_addr(dst) &&
> + !compare_ether_addr(src, dev->dev_addr)))
> return TXRX_DROP;
> - }
Looks fine to me, though I haven't tested.
-Michael Wu
On Friday 03 August 2007, Daniel Drake wrote:
> David Woodhouse wrote:
> > My experience is that mac80211 is broken w.r.t IPv6 -- it receives its
> > own packets. It would be suboptimal for me if the softmac version of
> > bcm43xx were to go away before that got fixed.
>
> This may be a stack-level issue. This is one of the issues holding back
> zd1211rw-mac80211 going into mainline: we have a report that
> zd1211rw-softmac works fine with IPv6 but mac80211 only works
> occasionally with the same device on the same system.
>
> Does anyone have any ideas?
This is certainly an issue in the packet filtering of mac80211.
On Mon, 2007-08-06 at 13:05 -0400, John W. Linville wrote:
> --- a/net/mac80211/ieee80211.c
> +++ b/net/mac80211/ieee80211.c
> @@ -3030,9 +3030,10 @@ ieee80211_rx_h_data(struct ieee80211_txrx_data *rx)
> memcpy(dst, hdr->addr1, ETH_ALEN);
> memcpy(src, hdr->addr3, ETH_ALEN);
>
> - if (sdata->type != IEEE80211_IF_TYPE_STA) {
> + if (sdata->type != IEEE80211_IF_TYPE_STA ||
> + (is_multicast_ether_addr(dst) &&
> + !compare_ether_addr(src, dev->dev_addr)))
> return TXRX_DROP;
I can confirm that this works (applies if you s/ieee80211.c/rx.c/) for
IPv6 link local addresses, and it's definitely the right thing to do
here.
johannes
On Thu, 2007-08-02 at 18:30 -0400, Daniel Drake wrote:
> This may be a stack-level issue. This is one of the issues holding ba=
ck=20
> zd1211rw-mac80211 going into mainline: we have a report that=20
> zd1211rw-softmac works fine with IPv6 but mac80211 only works=20
> occasionally with the same device on the same system.
>=20
> Does anyone have any ideas?
It receives its own neighbour solicitation (multicast) packets when the
AP sends them back out again. These packets...
23:41:56.046939 00:0a:95:f3:99:92 > 33:33:ff:f3:99:92, ethertype IPv6
(0x86dd), length 78: :: > ff02::1:fff3:9992: ICMP6, neighbor
solicitation, who has fe80::20a:95ff:fef3:9992, length 24
You should be able to see this without _any_ IPv6 infrastructure -- and
you'll see the link-local IPv6 address remains 'tentative'.
Once you've fixed that, setting up a local route advertisement d=C3=A6m=
on
(radvd) to give you site-local addresses is fairly trivial too -- and
then you can also check that Ethernet multicast is working properly.
--=20
dwmw2
On Thursday 02 August 2007, David Woodhouse wrote:
> On Thu, 2007-08-02 at 11:30 -0500, Larry Finger wrote:
> > I was hoping this would be your response, but I had to make the
> > effort. I'll wait for a couple of days to see if anyone else has any
> > comments and send it on to Linville and hope it ends up in -mm fairly
> > soon. It _DOES_ work on the hardware.
>
> My experience is that mac80211 is broken w.r.t IPv6 -- it receives its
> own packets. It would be suboptimal for me if the softmac version of
> bcm43xx were to go away before that got fixed.
>
We don't go _away_ from anything until there's no regression anymore.
This is a patchset which adds a driver. It does not remove something.
On Thu, Aug 02, 2007 at 11:46:18PM +0100, David Woodhouse wrote:
> On Thu, 2007-08-02 at 18:30 -0400, Daniel Drake wrote:
> > This may be a stack-level issue. This is one of the issues holding =
back=20
> > zd1211rw-mac80211 going into mainline: we have a report that=20
> > zd1211rw-softmac works fine with IPv6 but mac80211 only works=20
> > occasionally with the same device on the same system.
> >=20
> > Does anyone have any ideas?
>=20
> It receives its own neighbour solicitation (multicast) packets when t=
he
> AP sends them back out again. These packets...
>=20
> 23:41:56.046939 00:0a:95:f3:99:92 > 33:33:ff:f3:99:92, ethertype IPv6
> (0x86dd), length 78: :: > ff02::1:fff3:9992: ICMP6, neighbor
> solicitation, who has fe80::20a:95ff:fef3:9992, length 24
>=20
> You should be able to see this without _any_ IPv6 infrastructure -- a=
nd
> you'll see the link-local IPv6 address remains 'tentative'.
>=20
> Once you've fixed that, setting up a local route advertisement d=E6mo=
n
> (radvd) to give you site-local addresses is fairly trivial too -- and
> then you can also check that Ethernet multicast is working properly.
I hacked-up the (untested) patch below -- thoughts?
---
=46rom: John W. Linville <[email protected]>
[PATCH] mac80211: filter locally-originated multicast frames
In STA mode, the AP will echo our traffic. This includes multicast
traffice.
Receiving these frames confuses some protocols and applications,
notably IPv6 Duplicate Address Detection.
Signed-off-by: John W. Linville <[email protected]>
---
net/mac80211/ieee80211.c | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/net/mac80211/ieee80211.c b/net/mac80211/ieee80211.c
index a42e70e..6dc6451 100644
--- a/net/mac80211/ieee80211.c
+++ b/net/mac80211/ieee80211.c
@@ -4263,11 +4263,14 @@ void __ieee80211_rx(struct ieee80211_hw *hw, st=
ruct sk_buff *skb,
rx.u.rx.ra_match =3D 0;
} else if (!multicast &&
compare_ether_addr(sdata->dev->dev_addr,
- hdr->addr1) !=3D 0) {
+ hdr->addr1)) {
if (!sdata->promisc)
continue;
rx.u.rx.ra_match =3D 0;
- }
+ } else if (multicast &&
+ !compare_ether_addr(sdata->dev->dev_addr,
+ hdr->addr3))
+ rx.u.rx.ra_match =3D 0;
break;
case IEEE80211_IF_TYPE_IBSS:
if (!bssid)
--=20
John W. Linville
[email protected]
On Fri, Aug 17, 2007 at 02:52:56AM +0200, Johannes Berg wrote:
> On Mon, 2007-08-06 at 13:05 -0400, John W. Linville wrote:
>
> > --- a/net/mac80211/ieee80211.c
> > +++ b/net/mac80211/ieee80211.c
> > @@ -3030,9 +3030,10 @@ ieee80211_rx_h_data(struct ieee80211_txrx_data *rx)
> > memcpy(dst, hdr->addr1, ETH_ALEN);
> > memcpy(src, hdr->addr3, ETH_ALEN);
> >
> > - if (sdata->type != IEEE80211_IF_TYPE_STA) {
> > + if (sdata->type != IEEE80211_IF_TYPE_STA ||
> > + (is_multicast_ether_addr(dst) &&
> > + !compare_ether_addr(src, dev->dev_addr)))
> > return TXRX_DROP;
>
> I can confirm that this works (applies if you s/ieee80211.c/rx.c/) for
> IPv6 link local addresses, and it's definitely the right thing to do
> here.
Yes, seems so. FWIW, this patch is in later Fedora kernels.
Unfortunately (due to the ieee80211.c -> rx.c issue you mentioned)
applying this to 2.6.23 conflicts with patches already queued for
2.6.24. Since my experiments show that git doesn't help much in this
instance, I'll need to work something out with Dave M. if we are to
get this into 2.6.23.
If nothing else, I suppose we can just wait for 2.6.23 and send this
patch to -stable. Would that burn anyone's biscuits?
John
--
John W. Linville
[email protected]
On Fri, Aug 17, 2007 at 09:49:41AM -0400, John W. Linville wrote:
> On Fri, Aug 17, 2007 at 02:52:56AM +0200, Johannes Berg wrote:
>> On Mon, 2007-08-06 at 13:05 -0400, John W. Linville wrote:
>>
> >> --- a/net/mac80211/ieee80211.c
> >> +++ b/net/mac80211/ieee80211.c
> >> @@ -3030,9 +3030,10 @@ ieee80211_rx_h_data(struct ieee80211_txrx_data *rx)
> >> memcpy(dst, hdr->addr1, ETH_ALEN);
> >> memcpy(src, hdr->addr3, ETH_ALEN);
> >>
> >> - if (sdata->type != IEEE80211_IF_TYPE_STA) {
> >> + if (sdata->type != IEEE80211_IF_TYPE_STA ||
> >> + (is_multicast_ether_addr(dst) &&
> >> + !compare_ether_addr(src, dev->dev_addr)))
> >> return TXRX_DROP;
>> I can confirm that this works (applies if you s/ieee80211.c/rx.c/) for
>> IPv6 link local addresses, and it's definitely the right thing to do
>> here.
> Yes, seems so. FWIW, this patch is in later Fedora kernels.
> Unfortunately (due to the ieee80211.c -> rx.c issue you mentioned)
> applying this to 2.6.23 conflicts with patches already queued for
> 2.6.24. Since my experiments show that git doesn't help much in this
> instance, I'll need to work something out with Dave M. if we are to
> get this into 2.6.23.
> If nothing else, I suppose we can just wait for 2.6.23 and send this
> patch to -stable. Would that burn anyone's biscuits?
Suits me. The only machine this is currently relevant to is tracking
wireless-dev#evertything for the moment.
--
-----------------------------------------------------------
Paul "TBBle" Hampson, B.Sc, LPI, MCSE
Very-later-year Asian Studies student, ANU
The Boss, Bubblesworth Pty Ltd (ABN: 51 095 284 361)
[email protected]
Of course Pacman didn't influence us as kids. If it did,
we'd be running around in darkened rooms, popping pills and
listening to repetitive music.
-- Kristian Wilson, Nintendo, Inc, 1989
License: http://creativecommons.org/licenses/by/2.1/au/
-----------------------------------------------------------
On Thursday 02 August 2007, Larry Finger wrote:
> Driver bcm43xx is being ported from using SoftMAC to mac80211. For rewiew,
> this series of patches is being prepared; however, the final patch will be
> a single entity so that compilation during bisection will not break.
>
> The contents of the various pieces are as follows:
>
> 1. Kconfig, Makefile and the main header file.
> 2. bcm43xx_debugfs.c and bcm43xx_debugfs.h
> 3. bcm43xx_dma.c and bcm43xx_dma.h
> 4. bcm43xx_ilt.c, bcm43xx_ilt.h, bcm43xx_leds.c and bcm43xx_leds.h
> 5. bcm43xx_main.c and bcm43xx_main.h
> 6. bcm43xx_phy.c and bcm43xx_phy.h
> 7. bcm43xx_pio.c and bcm43xx_pio.h
> 8. bcm43xx_radio.c and bcm43xx_radio.h
> 9. bcm43xx_sysfs.c and bcm43xx_sysfs.h
> 10: bcm43xx_xmit.c and bcm43xx_xmit.h
>
> In general, this port consists of taking the files bcm43xx_phy and
> bcm43xx_radio from the softmac driver and converting them to work with
> the files from the mac80211 version, which has been back-converted to
> use V3 firmware.
I don't really want to review 10 huge patches that replace
X by Y. If the code works, fine. Go for it. You get my ACK, if it works
on the hardware where it matters. ;)
On Mon, Aug 06, 2007 at 01:05:00PM -0400, John W. Linville wrote:
> On Fri, Aug 03, 2007 at 01:02:12AM -0700, Michael Wu wrote:
>> This doesn't seem quite right. I think ieee80211_rx_h_data is a safer place
>> for this check (inside the IEEE80211_FCTL_FROMDS case), and allows various
>> statistics to be updated. ieee80211_rx_h_sta_process is another function that
>> might work though that would probably involve more code to add all the right
>> checks.
> The patch below seems to work for me w/ an otherwise stock F-7 kernel
> w/ iwl3945. Thoughts?
> From: John W. Linville <[email protected]>
> [PATCH] mac80211: filter locally-originated multicast frames
> In STA mode, the AP will echo our traffic. This includes multicast
> traffice.
> Receiving these frames confuses some protocols and applications,
> notably IPv6 Duplicate Address Detection.
> Signed-off-by: John W. Linville <[email protected]>
Worked for me, on bcm43xx-mac80211. Got an IP address from radvd, and
was able to ping6 a couple of places out on the big bad Internet.
Whole kernel is built from wireless-dev,
f2b262a6a8771fe9595f2c08e9d598b97634b266.
Thanks. ^_^
--
-----------------------------------------------------------
Paul "TBBle" Hampson, B.Sc, LPI, MCSE
Very-later-year Asian Studies student, ANU
The Boss, Bubblesworth Pty Ltd (ABN: 51 095 284 361)
[email protected]
Of course Pacman didn't influence us as kids. If it did,
we'd be running around in darkened rooms, popping pills and
listening to repetitive music.
-- Kristian Wilson, Nintendo, Inc, 1989
License: http://creativecommons.org/licenses/by/2.1/au/
-----------------------------------------------------------
On Fri, Aug 03, 2007 at 01:02:12AM -0700, Michael Wu wrote:
> This doesn't seem quite right. I think ieee80211_rx_h_data is a safer place
> for this check (inside the IEEE80211_FCTL_FROMDS case), and allows various
> statistics to be updated. ieee80211_rx_h_sta_process is another function that
> might work though that would probably involve more code to add all the right
> checks.
The patch below seems to work for me w/ an otherwise stock F-7 kernel
w/ iwl3945. Thoughts?
From: John W. Linville <[email protected]>
[PATCH] mac80211: filter locally-originated multicast frames
In STA mode, the AP will echo our traffic. This includes multicast
traffice.
Receiving these frames confuses some protocols and applications,
notably IPv6 Duplicate Address Detection.
Signed-off-by: John W. Linville <[email protected]>
---
net/mac80211/ieee80211.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/net/mac80211/ieee80211.c b/net/mac80211/ieee80211.c
index a42e70e..0097b0a 100644
--- a/net/mac80211/ieee80211.c
+++ b/net/mac80211/ieee80211.c
@@ -3030,9 +3030,10 @@ ieee80211_rx_h_data(struct ieee80211_txrx_data *rx)
memcpy(dst, hdr->addr1, ETH_ALEN);
memcpy(src, hdr->addr3, ETH_ALEN);
- if (sdata->type != IEEE80211_IF_TYPE_STA) {
+ if (sdata->type != IEEE80211_IF_TYPE_STA ||
+ (is_multicast_ether_addr(dst) &&
+ !compare_ether_addr(src, dev->dev_addr)))
return TXRX_DROP;
- }
break;
case 0:
/* DA SA BSSID */
--
John W. Linville
[email protected]
On Thu, 2007-08-02 at 20:55 -0400, John W. Linville wrote:
> I hacked-up the (untested) patch below -- thoughts?
I tried to test it. Today, I get no connectivity with bcm43xx-mac80211
(from Fedora 7 + your patch).
It does manage to associate, but tcpdump shows it doesn't seem to
receive any packets correctly -- http://david.woodhou.se/bcm43xx-bad.txt
I tried taking the device down and back up, and setting the WEP key
again (I think I've seen it screw up before and have to be told the WEP
key again before it starts working), but that didn't help. Removing the
module left rmmod and ksoftirqd both eating CPU, so I had to reboot.
I don't have time to do any more right now; I might look at it again in
a couple of weeks when I get home. But all this ought to be
reproduceable elsewhere -- and if it isn't, I have a Cardbus card which
seems to be exactly the same rev 4306 as my shinybook's internal device.
Give me an address to ship it to :)
--
dwmw2
On Thursday 02 August 2007 17:55, John W. Linville wrote:
> } else if (!multicast &&
> compare_ether_addr(sdata->dev->dev_addr,
> - hdr->addr1) != 0) {
> + hdr->addr1)) {
Good idea. Should do this for all the other cases in the function to keep
things consistent.
> if (!sdata->promisc)
> continue;
> rx.u.rx.ra_match = 0;
> - }
> + } else if (multicast &&
> + !compare_ether_addr(sdata->dev->dev_addr,
> + hdr->addr3))
> + rx.u.rx.ra_match = 0;
This doesn't seem quite right. I think ieee80211_rx_h_data is a safer place
for this check (inside the IEEE80211_FCTL_FROMDS case), and allows various
statistics to be updated. ieee80211_rx_h_sta_process is another function that
might work though that would probably involve more code to add all the right
checks.
Another alternate is to continue - doing rx.u.rx.ra_match = 0; still passes
the frame through the rx chain, though I think I'd prefer to update the
statistics.
-Michael Wu
Erik Mouw wrote:
> On Thu, Aug 02, 2007 at 06:07:20PM +0200, Michael Buesch wrote:
>> On Thursday 02 August 2007, Larry Finger wrote:
>>> Driver bcm43xx is being ported from using SoftMAC to mac80211. For rewiew,
>>> this series of patches is being prepared; however, the final patch will be
>>> a single entity so that compilation during bisection will not break.
>
> [...]
>
>> I don't really want to review 10 huge patches that replace
>> X by Y. If the code works, fine. Go for it. You get my ACK, if it works
>> on the hardware where it matters. ;)
>
> It might be a good idea to have two drivers for the same hardware so
> it's easier to figure out if something broke or not. My linksys bcm4318
> cardbus card works nice with 2.6.22 and I wouldn't like to lose that
> functionality.
>
>
> Just my 0.02 EUR,
It turns out that the new port works as well as the current driver, has the ability to adjust the
transmit rate depending on conditions, and is free of the locking bugs of SoftMAC. There are, of
course, bugs in mac80211, but at least they will be fixed. There is very little maintenance on SoftMAC.
There will still be 2 drivers as Michael's version with V4 firmware will still be in the development
tree, and it will be merged to mainstream when ready. As his version will not support 802.11b-only
devices (no support in that firmware), this port will then be gutted of 802.11g devices. I can
assure you that this will not happen until the V4 driver functions at least as well as bcm43xx does now.
Larry
On Thu, 2007-08-02 at 11:30 -0500, Larry Finger wrote:
> I was hoping this would be your response, but I had to make the
> effort. I'll wait for a couple of days to see if anyone else has any
> comments and send it on to Linville and hope it ends up in -mm fairly
> soon. It _DOES_ work on the hardware.
My experience is that mac80211 is broken w.r.t IPv6 -- it receives its
own packets. It would be suboptimal for me if the softmac version of
bcm43xx were to go away before that got fixed.
--
dwmw2
David Woodhouse wrote:
> On Thu, 2007-08-02 at 11:30 -0500, Larry Finger wrote:
>> I was hoping this would be your response, but I had to make the
>> effort. I'll wait for a couple of days to see if anyone else has any
>> comments and send it on to Linville and hope it ends up in -mm fairly
>> soon. It _DOES_ work on the hardware.
>
> My experience is that mac80211 is broken w.r.t IPv6 -- it receives its
> own packets. It would be suboptimal for me if the softmac version of
> bcm43xx were to go away before that got fixed.
>
This will go into -mm. I hope that it gets plenty of testing, in fact, I hope you grab the patch set
and make a trial of your own. If this driver is broken with IPv6, I want to know.
Larry
On Thu, Aug 02, 2007 at 06:07:20PM +0200, Michael Buesch wrote:
> On Thursday 02 August 2007, Larry Finger wrote:
> > Driver bcm43xx is being ported from using SoftMAC to mac80211. For rewiew,
> > this series of patches is being prepared; however, the final patch will be
> > a single entity so that compilation during bisection will not break.
[...]
> I don't really want to review 10 huge patches that replace
> X by Y. If the code works, fine. Go for it. You get my ACK, if it works
> on the hardware where it matters. ;)
It might be a good idea to have two drivers for the same hardware so
it's easier to figure out if something broke or not. My linksys bcm4318
cardbus card works nice with 2.6.22 and I wouldn't like to lose that
functionality.
Just my 0.02 EUR,
Erik
--
They're all fools. Don't worry. Darwin may be slow, but he'll
eventually get them. -- Matthew Lammers in alt.sysadmin.recovery
Michael Buesch wrote:
> On Thursday 02 August 2007, Larry Finger wrote:
>> Driver bcm43xx is being ported from using SoftMAC to mac80211. For rewiew,
>> this series of patches is being prepared; however, the final patch will be
>> a single entity so that compilation during bisection will not break.
>>
>> The contents of the various pieces are as follows:
>>
>> 1. Kconfig, Makefile and the main header file.
>> 2. bcm43xx_debugfs.c and bcm43xx_debugfs.h
>> 3. bcm43xx_dma.c and bcm43xx_dma.h
>> 4. bcm43xx_ilt.c, bcm43xx_ilt.h, bcm43xx_leds.c and bcm43xx_leds.h
>> 5. bcm43xx_main.c and bcm43xx_main.h
>> 6. bcm43xx_phy.c and bcm43xx_phy.h
>> 7. bcm43xx_pio.c and bcm43xx_pio.h
>> 8. bcm43xx_radio.c and bcm43xx_radio.h
>> 9. bcm43xx_sysfs.c and bcm43xx_sysfs.h
>> 10: bcm43xx_xmit.c and bcm43xx_xmit.h
>>
>> In general, this port consists of taking the files bcm43xx_phy and
>> bcm43xx_radio from the softmac driver and converting them to work with
>> the files from the mac80211 version, which has been back-converted to
>> use V3 firmware.
>
> I don't really want to review 10 huge patches that replace
> X by Y. If the code works, fine. Go for it. You get my ACK, if it works
> on the hardware where it matters. ;)
I was hoping this would be your response, but I had to make the effort. I'll wait for a couple of
days to see if anyone else has any comments and send it on to Linville and hope it ends up in -mm
fairly soon. It _DOES_ work on the hardware.
Larry
From: Michael Buesch <[email protected]>
Date: Fri, 3 Aug 2007 00:36:12 +0200
> On Friday 03 August 2007, Daniel Drake wrote:
> > David Woodhouse wrote:
> > > My experience is that mac80211 is broken w.r.t IPv6 -- it receives its
> > > own packets. It would be suboptimal for me if the softmac version of
> > > bcm43xx were to go away before that got fixed.
> >
> > This may be a stack-level issue. This is one of the issues holding back
> > zd1211rw-mac80211 going into mainline: we have a report that
> > zd1211rw-softmac works fine with IPv6 but mac80211 only works
> > occasionally with the same device on the same system.
> >
> > Does anyone have any ideas?
>
> This is certainly an issue in the packet filtering of mac80211.
Another thing to always be mindful of with ipv6 is that it
uses multicast as part of it's normal operation.
David Woodhouse wrote:
> My experience is that mac80211 is broken w.r.t IPv6 -- it receives its
> own packets. It would be suboptimal for me if the softmac version of
> bcm43xx were to go away before that got fixed.
This may be a stack-level issue. This is one of the issues holding back
zd1211rw-mac80211 going into mainline: we have a report that
zd1211rw-softmac works fine with IPv6 but mac80211 only works
occasionally with the same device on the same system.
Does anyone have any ideas?
Thanks,
Daniel