[RFC 0/10] Port of bcm43xx from softmac to mac80211

[RFC 0/10] Port of bcm43xx from softmac to mac80211

[Larry Finger]

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

Re: [RFC 0/10] Port of bcm43xx from softmac to mac80211

[Michael Buesch]

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. ;)

Re: [RFC 0/10] Port of bcm43xx from softmac to mac80211

[Larry Finger]

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

Re: [RFC 0/10] Port of bcm43xx from softmac to mac80211

[David Woodhouse]

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

Re: [RFC 0/10] Port of bcm43xx from softmac to mac80211

[Michael Buesch]

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.

Re: [RFC 0/10] Port of bcm43xx from softmac to mac80211

[Larry Finger]

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

mac80211 IPv6 problems

[Daniel Drake]

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

Re: mac80211 IPv6 problems

[Michael Buesch]

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.

Re: mac80211 IPv6 problems

[David Miller]

From: Michael Buesch <mb@bu3sch.de>
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.

Re: mac80211 IPv6 problems

[David Woodhouse]

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

-
To unsubscribe from this list: send the line "unsubscribe linux-wireles=
s" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: mac80211 IPv6 problems

[John W. Linville]

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 <linville@tuxdriver.com>

[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 <linville@tuxdriver.com>
---

 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
linville@tuxdriver.com
-
To unsubscribe from this list: send the line "unsubscribe linux-wireles=
s" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: mac80211 IPv6 problems

[Michael Wu]

[-- Attachment #1: Type: text/plain, Size: 1056 bytes --]

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

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: mac80211 IPv6 problems

[John W. Linville]

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 <linville@tuxdriver.com>

[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 <linville@tuxdriver.com>
---

 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
linville@tuxdriver.com

Re: mac80211 IPv6 problems

[Michael Wu]

[-- Attachment #1: Type: text/plain, Size: 335 bytes --]

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

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: mac80211 IPv6 problems

[Paul TBBle Hampson]

[-- Attachment #1: Type: text/plain, Size: 1739 bytes --]

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 <linville@tuxdriver.com>

> [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 <linville@tuxdriver.com>

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)
Paul.Hampson@Pobox.com

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/
-----------------------------------------------------------

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: mac80211 IPv6 problems

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 679 bytes --]

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

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 190 bytes --]

Re: mac80211 IPv6 problems

[John W. Linville]

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
linville@tuxdriver.com

Re: mac80211 IPv6 problems

[Paul TBBle Hampson]

[-- Attachment #1: Type: text/plain, Size: 2013 bytes --]

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)
Paul.Hampson@Pobox.com

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/
-----------------------------------------------------------

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: mac80211 IPv6 problems

[David Woodhouse]

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

Re: [RFC 0/10] Port of bcm43xx from softmac to mac80211

[Erik Mouw]

[-- Attachment #1: Type: text/plain, Size: 936 bytes --]

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

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [RFC 0/10] Port of bcm43xx from softmac to mac80211

[Larry Finger]

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