Broadcom bcm43xx Wireless driver regression in gutsy

uname -a

Linux zd7000 2.6.22-7-386 #1 Mon Jun 25 16:30:18 GMT 2007 i686 GNU/Linux

More info: To test this further, I tried booting under the old feisty kernel which I fortunately hadn't removed yet.

uname -a
Linux zd7000 2.6.20-16-386 #2 Thu Jun 7 20:16:13 UTC 2007 i686 GNU/Linux

Under this kernel, the wireless card still works great: I'm back to 400kB/s and better transmission rates. Night and Day.

dmesg attached.

Still investigating, adding more info as I find it...

Since there were also big problems in the feisty betas with bcm43xx, I fiddled around quite a bit back then.

The eventual solution I used was to extract the wl_apsta.o firmware into /lib/firmware/

This way it gets picked by default with all kernels. Looks like when I enabled bcm43xx for the gutsy kernel, it installed new firmware in /lib/firmware/ 2.6.22-7-386/ which seems to override the firmware in /lib/firmware with an inferior version. Testing this hypothesis.

Didn't get the result I expected:

issued 'sudo rm bcm43xx*' in /lib/firmware/2.6.22-7-386 to remove the kernel-specific bcm43xx firmware then rebooted with the 2.6.22-7 kernel

Now bcm43xx driver is unselected in Restricted Drivers again, but my maximum speed on the gutsy kernel is still about 30 kB/s.

Thus I conclude the problem is not in the firmware but rather somewhere in the kernel itself. Looks like I'll be booting the feisty kernel until someone gets this regression figured out.

reboot with feisty kernel, sure enough speed = 457.21 kB/s vs 36.7 kB/s with gutsy kernel.

Tested in latest kernel: 2.6.22.8 -- Still broken, wireless unusable. This is starting to get me worried.

I have what looks to be the same problem; only half the normal throughput on wireless (100Kb/s versus 200Kb/s) even when only 30 cm from the wireless router dropping to 16Kb/s when a few meters away. Using a wired connection restores performance as does rebooting with an earlier Kernel. I have tried booting the same laptop with a replacement harddrive containing Windows XP and performance is fine even 10m away.

Hello, For my *not* work module bcm43xx in Ubuntu Feisty and chipset Broadcom 4318, I use ndiswrapper for work.

Now I testing live cd of Ubuntu Gutsy Tribe 3, install module bcm43xx and work with my chipset : -). Attach info of hardware and test with iptraf of speed.

Laptop: Compaq Presario v2000
Router: Linksys WRT54GL 1.1
Firmware: DD-WRT v23 SP3 (07/21/07) std (Beta)

Wifi: 02:02.0 Network controller: Broadcom Corporation BCM4318 [AirForce One 54g] 802.11g Wireless LAN Controller (rev 02)

Distance: 1 meter

Test A:
S.O.: Ubuntu Feisty + updates
Driver: Ndiswrapper.
Speed: ~ 400kbyte

Test B:
S.O: Ubuntu Gutsy Tribe 3
Driver: bcm43xx
Speed: ~400kbyte

I am Happy! XD

Tested again in latest kernel 2.6.22.9. Wireless still unusable, still booting the Feisty kernel. Sure hope this regression gets fixed soon.

Please note that Christian is using the 4318 chipset, whereas I have the the 4306 chipset. Thus his post is unrelated to my original bug report for this regression.

The 2007-08-09 free Ubuntu Gutsy Tribe 4. I test new kernel of live cd, for my many unstable for install. Tribe -> *Unstable*, for work fine use Feisty ; -)

Restored the original bug title, since 'experiences' isn't a good name for something that needs to be fixed.

I'm using 2.6.22.9 and the performance is pretty good even several meters away. Much better than previous 2.6.22 kernels. Will keep testing but I'm happy now.

Chris, what chipset do you have?

Hi Thom,

I'm using the 4306 chipset.

Chris

Thom Pischke wrote:
> Chris, what chipset do you have?
>
>

Which revision?

Hi Thom,

It's Rev 02. I've been checking the performance by running "apt-get
updates" against one of the Irish repository servers. With earlier
kernels (e.g. 2.6.20-16) I get close to 200Kb/s downloads. When I
upgraded to 2.6.22-x the performance dropped down to around 16Kb/s when
just a few metres from the wireless hub. I've been using 2.6.20-16 for a
few weeks now and only accidentally booted the latest 2.6.22-9. With
this I'm getting 160Kb/s which is close enough to be usable.

Does that help?

Chris

Thom Pischke wrote:
> Which revision?
>
>

Okay, so we both have 4306 rev 02. I'll have to give the latest kernel another go. I didn't test it thoroughly, just still seemed unacceptably slow. Of course, I'm used to getting 700+ KB/s, so even 160 KB/s would be a pretty disappointing regression. Certainly enough to avoid using Gutsy and reinstall Feisty if this isn't going to be fixed. But I suppose I better test.

Please attach:

* uname -a > uname-a.log
* cat /proc/version_signature > version.log
* dmesg > dmesg.log
* sudo lspci -vvnn > lspci-vvnn.log

Thanks!

Oops. I attached the logs from the wrong laptop! Will attach the correct logs later today, stupid me.

Booted on Gutsy 2.6.22.9 kernel. No improvement. Loading this webpage to post this comment took about 45 seconds, for example.

Currently updating via Update-Manager - it looks to be averaging somewhere between 10-20 kB/s, at which rate it will need almost an hour to download today's updates. This normally downloads at at least 200+ kB/s -- whatever the update server can dish out.

This is worse than using a dial-up modem, and I'm about 3 meters from the router, with nothing in between.

Once my system finishes updating will install the driver fresh via the restricted-driver manager, reboot on the gutsy kernel and attach the requested logs.

Truly bizarre behavior with this kernel. Moving the computer 12" closer to the router caused the download rate to spike to 260+ kB/s. Returning the laptop to its original position brought the rate back to 30. Moving the laptop closer to router again a second time had minimal effect. Sometimes when people walk by in front of my laptop, it will also spike to 300+, then go back again once the person is gone.

It's like having turning the rabbit ears antennae on a TV to try to get the best reception. Really bizarre stuff that simply doesn't happen with the Feisty kernel.

Well, the Restricted Driver Manager crashes everytime I try to upgrade the firmware in gutsy right now, so can't do that. According to my earlier testing, installing the firmware for the kernel has no effect anyway, since I already have the firmware installed generically for all kernels. Sent in the crash report for the Driver Manager via apport.

So here are all the requested logs booting with the bad gusty kernel.

Hmm, looks like that dmesg.log was for the feisty kernel, so attaching another with the gutsy kernel. Probably not a bad thing to have both for comparison purposes anyway.

I'm experiencing the same behavior, except mine never quite worked properly under Feisty either. Not sure if it's something with different firmware or what. Same 4306, rev 02 (Marked as Dell TrueMobile 1300 WLAN Mini-PCI).

Tested again on latest kernel:

Linux zd7000 2.6.22-10-386 #1 Wed Aug 22 07:43:24 GMT 2007 i686 GNU/Linux

Still unusable 3 meters from router: 96.1 kilobits per second

More bad news. Seems the latest nvidia drivers in gutsy don't work with the feisty kernel that I've been relying on, making my options even less palatable:

I can either choose no wireless or the old kernel and no nvidia driver.

-Still- hope this gets fixed soon.

Hi,

Ignore my earlier optimism the performance is very erratic and when more
than a few metres away it is very poor. Sometimes I get acceptable
performance but mostly it is about 10%-20% of the expected throughput.

With the new nvidia drivers I also cannot use the older kernel.

Chris

Thom Pischke wrote:
> More bad news. Seems the latest nvidia drivers in gutsy don't work with
> the feisty kernel that I've been relying on, making my options even less
> palatable:
>
> I can either choose no wireless or the old kernel and no nvidia driver.
>
> -Still- hope this gets fixed soon.
>
>

What does Triaged mean?
Please see this bug as well...
https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.22/+bug/130511

I can confirm the regression:
my card is
02:00.0 Network controller: Broadcom Corporation BCM4306 802.11b/g Wireless LAN Controller (rev 02)
and I'm running the kernel 2.6.22-11-386 on Gutsy

I can confirm poor performance, I can reach only ~40KB traffic from a cople meters away from the AP.
I cannot confirm the crash in restricted-manager, Infact i can download succesfully the firmware from the internet with restricted-manager (source http://xeve.de/down/wl_apsta.o) and the lights of my pcmcia card do light on, but restricted manager still ask for a firmware after a reboot, and I have to start over the process of enable firmware --> download the firmware from internet.
I have filled a bug (Bug #139086) about this.
Also I confirm a bug in restricted manager that prevents me from load a firmware using a local file either typing the path-to-file manually in the input box and trying to push the browse button.

when launching restricted manager from a terminal and downloading the file from internet I receive this output from the terminal:

  filename : wl_apsta.o
  version : 3.130.20.0
  MD5 : e08665c5c5b66beb9c3b2dd54aa80cb3
  microcodes : 2 4 5 11
  pcms : 4 5

  microcode : 2
  revision : 0x0127
  patchlevel : 0x000e
  date : 2005-04-18
  time : 02:36:27

  microcode : 4
  revision : 0x0127
  patchlevel : 0x000e
  date : 2005-04-18
  time : 02:36:27

  microcode : 5
  revision : 0x0127
  patchlevel : 0x000e
  date : 2005-04-18
  time : 02:36:27

  microcode : 11
  revision : 0x0127
  patchlevel : 0x000e
  date : 2005-04-18
  time : 02:36:27

Cannot open input file http://xeve.de/down/wl_apsta.o

=====

this is DMESG output:

[ 780.096000] ieee80211_crypt: registered algorithm 'NULL'
[ 780.104000] ieee80211: 802.11 data/management/control stack, git-1.1.13
[ 780.104000] ieee80211: Copyright (C) 2004-2005 Intel Corporation <email address hidden>
[ 780.148000] bcm43xx driver
[ 780.148000] PCI: Enabling device 0000:02:00.0 (0000 -> 0002)
[ 780.148000] ACPI: PCI Interrupt 0000:02:00.0[A] -> Link [LNKA] -> GSI 11 (level, low) -> IRQ 11
[ 780.148000] PCI: Setting latency timer of device 0000:02:00.0 to 64
[ 780.184000] ACPI: PCI interrupt for device 0000:02:00.0 disabled
[ 780.184000] ACPI: PCI Interrupt 0000:02:00.0[A] -> Link [LNKA] -> GSI 11 (level, low) -> IRQ 11
[ 780.836000] bcm43xx: TODO: Incomplete code in keymac_write() at /build/buildd/linux-source-2.6.22-2.6.22/drivers/net/wireless/bcm43xx/bcm43xx_main.c:1112
[ 780.836000] bcm43xx: TODO: Incomplete code in keymac_write() at /build/buildd/linux-source-2.6.22-2.6.22/drivers/net/wireless/bcm43xx/bcm43xx_main.c:1112
[ 780.836000] bcm43xx: TODO: Incomplete code in keymac_write() at /build/buildd/linux-source-2.6.22-2.6.22/drivers/net/wireless/bcm43xx/bcm43xx_main.c:1112
[ 780.836000] bcm43xx: TODO: Incomplete code in keymac_write() at /build/buildd/linux-source-2.6.22-2.6.22/drivers/net/wireless/bcm43xx/bcm43xx_main.c:1112
[ 780.836000] bcm43xx: TODO: Incomplete code in keymac_write() at /build/buildd/linux-source-2.6.22-2.6.22/drivers/net/wireless/bcm43xx/bcm43xx_mai...

Sorry I forgot to mention that :
Even if the card is connected to an AP and is working the restricted-manager still reports the firmware as not enabled / not in use.

Thanks
NDV

Hey, so how about scheduling this bug to get fixed? It hasn't even made it into the list to be fixed for beta, which makes me think it will never be fixed before release. The Ubuntu team can save itself a lot of howling broadcom users by getting this fixed before releasing. There are enough confirmations even at this alpha stage to make it pretty clear that this will become a major issue should this bug survive into the release.

I gave up and reinstalled Feisty by the way. My laptop was worthless with gutsy.

I'm experiencing this problem on my machine equipped with a Linksys PCI Wireless Adapter (Broadcom 4306 Rev. 02 Chipset), too.
However, manually setting the bitrate on the adapter to a low value seems to help a lot:

After executing:
$ sudo iwconfig eth2 rate 5.5M fixed

my max. download rate now is at 360 kb/s again (that's line limit, actually), while it was around 40 kb/s before, and the automatic adapter bitrate setting was constantly at 24MBit/s.

WOW. That worked. Keep heart Thom!

Chris

Christoph wrote:
> I'm experiencing this problem on my machine equipped with a Linksys PCI Wireless Adapter (Broadcom 4306 Rev. 02 Chipset), too.
> However, manually setting the bitrate on the adapter to a low value seems to help a lot:
>
> After executing:
> $ sudo iwconfig eth2 rate 5.5M fixed
>
> my max. download rate now is at 360 kb/s again (that's line limit,
> actually), while it was around 40 kb/s before, and the automatic adapter
> bitrate setting was constantly at 24MBit/s.
>
>

That sounds like great news! Unfortunately I'm not in a position to test it anymore, being back on Feisty, but if it works for both of you, chances are good it will work for me. Hopefully a fix like this will make it into the release, looks like it wouldn't be too difficult. Having just bought a new Dell 1420, I'll be selling my old HP with the broadcom chip with Feisty installed. So hopefully the Wireless won't break when the new owner upgrades to Gutsy.

Hi,
this is gutsy with latest updates.
I have the very same issue, as it seems.
Using this: 02:02.0 Network controller: Broadcom Corporation BCM4318 [AirForce One 54g] 802.11g Wireless LAN Controller (rev 02)

I was very happy that Gutsy found my wireless-hardware and installed the drivers without ndiswrapper (although there still is a little issue with the lights being always on as reported here:
https://bugs.launchpad.net/ubuntu/+source/linux-meta/+bug/55308 )
I couldn't connect with that card. It went fairly well with another PCMCIA-Card I connected from which I am writing this. I had no problems with the very same card under Feisty using ndiswrapper (not fwcutter).
With Feisty and ndiswrapper I didn't need to adjust the cards speed manually.

Actually the card was able to connect some minutes ago but the connection was VERY unstable and broke away soon enough.

This needs to get fixed. :)

regards

Hi there,

Try setting the rate to 5.5M as suggested in an earlier post. For me
this brings the throughput back up to normal. Assuming that your
wireless interface is eth1 then the following should work for you:

iwconfig eth1 rate 5.5M

Chris

dennda wrote:
> Hi,
> this is gutsy with latest updates.
> I have the very same issue, as it seems.
> Using this: 02:02.0 Network controller: Broadcom Corporation BCM4318 [AirForce One 54g] 802.11g Wireless LAN Controller (rev 02)
>
> I was very happy that Gutsy found my wireless-hardware and installed the drivers without ndiswrapper (although there still is a little issue with the lights being always on as reported here:
> https://bugs.launchpad.net/ubuntu/+source/linux-meta/+bug/55308 )
> I couldn't connect with that card. It went fairly well with another PCMCIA-Card I connected from which I am writing this. I had no problems with the very same card under Feisty using ndiswrapper (not fwcutter).
> With Feisty and ndiswrapper I didn't need to adjust the cards speed manually.
>
> Actually the card was able to connect some minutes ago but the
> connection was VERY unstable and broke away soon enough.
>
> This needs to get fixed. :)
>
> regards
>
>

Hi,
I will test this as soon as I am back to my WiFi-Access-Point.

I guess that this is - even if it works - rather a workaround than a fix, since I didn't need to do that on Feisty with ndiswrapper.

I furthermore experience this bug: https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.15/+bug/37765
I doubt this helps to fix this issue, too, but we will see.

Thanks for your help.
regards

Perfect.
Thanks Chris.
It works now as it should with using that command.
(Am I mistaken or does this only work until session logout? How to permanently set it to that value?)

Nevertheless I think this should be possible by default. The new Broadcom driver installation is so easy, but without entering that command rather useless. Thus I think it should be done by default.

regards

Hi,

Glad to hear that it's working for you. The problem is probably within
the kernel not the driver itself (earlier kernels had no such problem).
Dropping the transmission rate seems to be a workaround for this but
isn't the solution per se. Hopefully someone will debug the problem
correctly and come up with a solution.

As for setting the rate permanently, I had thought that "iwconfig eth1
commit" would set the value across sessions but I just get an error when
I try this. I think you can just set the wireless rate in the
/etc/networks/interfaces but I haven't tried it yet as most of the time
I'm on a wired connection.

Chris

dennda wrote:
> Perfect.
> Thanks Chris.
> It works now as it should with using that command.
> (Am I mistaken or does this only work until session logout? How to permanently set it to that value?)
>
> Nevertheless I think this should be possible by default. The new
> Broadcom driver installation is so easy, but without entering that
> command rather useless. Thus I think it should be done by default.
>
> regards
>
>

I'm having this troubles, too, using bcm43xx on a 4318 chip. NM tries to connect with 24M, which causes poor performance. In feisty the default value was 11M, AFAIK due to restrictions in the kernel-driver, which prevented higher rates. Now these seem to be no longer present, though higher connection rates are still unstable, at least with the BCM4318 chip.

After setting to 11M manually (home network) or 6M (University), everything is ok again. To use the workaround together with NM, you can add a script to /etc/NetworkManager/dispatcher.d, containing the iwconfig stuff.

I have the problem with the fixed rate of 24MBits/s too.

Why can`t we get rates higher than that?
If I get from the same machine from windows it reaches the full speed of 54MBits/s.

The linux driver?

This is due to restrictions of the linux driver. Upstream is working on it, but it seems to be not an easy task. Especially the bcm4318 (or latest b43) seems to be only usable with rates <=11MBit/s.

Hi.
This is odd.
I did not experience any problems with my own accesspoint, using the above mentioned workaround.
At my girlfriends place, however, it still doesn't work.
At least not with network-manager.
The new in-built GNOME functionality to connect to WPA encryptet wireless networks works.
But I'd really like to use network-manager.

Any chance of fixing this?

regards

I've had no problems using bcm43xx (granted, with 11Mbps rate) in Fiesty. The driver loads just fine after upgrade to Gutsy, but is unable to find any ESSIDs. Wrote a post in http://ubuntuforums.org/showthread.php?p=3493272.

Linux longisland 2.6.22-13-generic #1 SMP Thu Oct 4 17:52:26 GMT 2007 x86_64 GNU/Linux

~$ sudo iwlist eth0 scan
eth0 No scan results

0b:00.0 Network controller [0280]: Broadcom Corporation BCM94311MCG wlan mini-PCI [14e4:4311] (rev 01)
        Subsystem: Dell Unknown device [1028:0007]
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B-
        Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-
        Latency: 0, Cache Line Size: 64 bytes
        Interrupt: pin A routed to IRQ 16
        Region 0: Memory at efcfc000 (32-bit, non-prefetchable) [size=16K]
        Capabilities: [40] Power Management version 2
                Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=375mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
                Status: D0 PME-Enable- DSel=0 DScale=2 PME-
        Capabilities: [58] Message Signalled Interrupts: Mask- 64bit- Queue=0/0 Enable-
                Address: 00000000 Data: 0000
        Capabilities: [d0] Express Legacy Endpoint IRQ 0
                Device: Supported: MaxPayload 128 bytes, PhantFunc 0, ExtTag+
                Device: Latency L0s <4us, L1 unlimited
                Device: AtnBtn- AtnInd- PwrInd-
                Device: Errors: Correctable- Non-Fatal- Fatal- Unsupported-
                Device: RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop-
                Device: MaxPayload 128 bytes, MaxReadReq 128 bytes
                Link: Supported Speed 2.5Gb/s, Width x1, ASPM L0s, Port 0
                Link: Latency L0s <4us, L1 <64us
                Link: ASPM L0s Enabled RCB 64 bytes CommClk+ ExtSynch-
                Link: Speed 2.5Gb/s, Width x1

Argh. My problem is seemingly different.

I rebooted in Feisty kernel and discovered that ESSID scanning didn't work either. It used to work before Gutsy upgrade (and I used fwcutter with Feisty). I suspect this has something to do with updated bcm43xx-fwcutter and with enabling it via the Restricted Driver Manager. Should I open a new bug on that?

Hi,

Your problem could also be with the 2.6.22-13 kernel. There are problems with the wireless support for the broadcom driver. I've moved back to 2.6.22-12 where everything seems fine.

Chris

I too moved back.... Waiting for updates.

On 10/9/07, Chris McCauley <email address hidden> wrote:
>
> Hi,
>
> Your problem could also be with the 2.6.22-13 kernel. There are problems
> with the wireless support for the broadcom driver. I've moved back to
> 2.6.22-12 where everything seems fine.
>
> Chris
>
> --
> Broadcom bcm43xx Wireless driver regression in gutsy
> https://bugs.launchpad.net/bugs/124159
> You received this bug notification because you are a direct subscriber
> of the bug.
>

Looks like we just got some updates to restricted-modules, nvidia-glx
(important for me) and a new 2.6.22-14 kernel. Fingers crossed!

zeddock wrote:
> I too moved back.... Waiting for updates.
>
>
> On 10/9/07, Chris McCauley <email address hidden> wrote:
>
>> Hi,
>>
>> Your problem could also be with the 2.6.22-13 kernel. There are problems
>> with the wireless support for the broadcom driver. I've moved back to
>> 2.6.22-12 where everything seems fine.
>>
>> Chris
>>
>> --
>> Broadcom bcm43xx Wireless driver regression in gutsy
>> https://bugs.launchpad.net/bugs/124159
>> You received this bug notification because you are a direct subscriber
>> of the bug.
>>
>>
>
>

I have updated to 2.6.22-14 kernel and it did not resolve the issue.

~$ uname -a
Linux longisland 2.6.22-14-generic #1 SMP Wed Oct 10 05:28:36 GMT 2007 x86_64 GNU/Linux
~$ sudo iwlist eth0 scan
eth0 No scan results

Hi,

Did you use the restricted drivers manager to reload the firmware? If
you look at the dmesg output you'll probably see that the firmware has
changed from the 2.6.22-12 kernel.

Chris

michael37 wrote:
> I have updated to 2.6.22-14 kernel and it did not resolve the issue.
>
> ~$ uname -a
> Linux longisland 2.6.22-14-generic #1 SMP Wed Oct 10 05:28:36 GMT 2007 x86_64 GNU/Linux
> ~$ sudo iwlist eth0 scan
> eth0 No scan results
>
>

2.6.22-12 kernel is no longer in repositories, I can no longer install it. I have 2.6.22-13 and 2.6.22-14 installed and neither of them work.

>Hi,
>
>Did you use the restricted drivers manager to reload the firmware? If
>you look at the dmesg output you'll probably see that the firmware has
>changed from the 2.6.22-12 kernel.
>
>Chris

I never had 2.6.22-12 kernel installed -- my initial upgrade to Gusty came with 2.6.22-13 kernel.

I looked through dmesg and it doesn't say anything about firmware version unless firmware loading fails.

I confirmed that firmware is enabled in the restricted drivers manager and that I am using the "blessed" version 3 of the firmware from http://linuxwireless.org/en/users/Drivers/b43#devicefirmware

Hi Michael,

If you've got the firmware enabled then that should be all you need. Is
it just that the scan doesn't work? Can you manually connect to the
nearest access point?

Chris

michael37 wrote:
>> Hi,
>>
>> Did you use the restricted drivers manager to reload the firmware? If
>> you look at the dmesg output you'll probably see that the firmware has
>> changed from the 2.6.22-12 kernel.
>>
>> Chris
>>
>
> I never had 2.6.22-12 kernel installed -- my initial upgrade to Gusty
> came with 2.6.22-13 kernel.
>
> I looked through dmesg and it doesn't say anything about firmware
> version unless firmware loading fails.
>
> I confirmed that firmware is enabled in the restricted drivers manager
> and that I am using the "blessed" version 3 of the firmware from
> http://linuxwireless.org/en/users/Drivers/b43#devicefirmware
>
>

... also, could you post your dmesg log?

michael37 wrote:
>> Hi,
>>
>> Did you use the restricted drivers manager to reload the firmware? If
>> you look at the dmesg output you'll probably see that the firmware has
>> changed from the 2.6.22-12 kernel.
>>
>> Chris
>>
>
> I never had 2.6.22-12 kernel installed -- my initial upgrade to Gusty
> came with 2.6.22-13 kernel.
>
> I looked through dmesg and it doesn't say anything about firmware
> version unless firmware loading fails.
>
> I confirmed that firmware is enabled in the restricted drivers manager
> and that I am using the "blessed" version 3 of the firmware from
> http://linuxwireless.org/en/users/Drivers/b43#devicefirmware
>
>

Here we go.

Started driver. Went into NetworkManager and selected connect to other wireless network. Put in my SSID and WEP key. NetworkManager said Attempting to join the wireless netowork 'HOME'...
NetworkManager asked me for my WEP key two more times, and I got bored of that.

dmesg:

[ 362.757538] bcm43xx driver
[ 362.757794] ACPI: PCI Interrupt 0000:0b:00.0[A] -> GSI 16 (level, low) -> IRQ 16
[ 362.757830] PCI: Setting latency timer of device 0000:0b:00.0 to 64
[ 361.069755] ADDRCONF(NETDEV_UP): eth0: link is not ready
[ 408.087470] ieee80211_crypt: registered algorithm 'WEP'
[ 481.588696] ADDRCONF(NETDEV_UP): eth0: link is not ready
[ 553.542256] ADDRCONF(NETDEV_UP): eth0: link is not ready

More fun stuff: I went back to NetworkManager and told it to connect to Wired network.
The NetworkManager is still spinning and saying Preparing device eth1 for the wired network
as I type this bug report -- the wired network got a DHCP address and is working perfectly.

I went back to Feisty using included bcm43xx driver and added firmware to /lib/firmware, worked first time at full 54G speeds. That was until a kernel update yesterday and now the erratic and slow speeds are back, tried both bcm43xx and ndiswrapper methods, but its now just as bad as it was in gutsy..sigh.

Hi
To restrict inrterface rate, you can add to configuration of the corresponding interface in /etc/networks/interfaces

wireless-rate 5.5M

And yes, I confirm the problem (HP Pavilion zv3240 w/Broadcom adapter).

I thought the interfaces file was ... forget the word, but there is a rules
file which has now become the proper approach. Please confirm?

Thanx,

zeddock

On 10/15/07, Yakov Markovitch <email address hidden> wrote:
>
> Hi
> To restrict inrterface rate, you can add to configuration of the
> corresponding interface in /etc/networks/interfaces
>
> wireless-rate 5.5M
>
> And yes, I confirm the problem (HP Pavilion zv3240 w/Broadcom adapter).
>
> --
> Broadcom bcm43xx Wireless driver regression in gutsy
> https://bugs.launchpad.net/bugs/124159
> You received this bug notification because you are a direct subscriber
> of the bug.
>

Dell X300 + Dell Wireless a/b/g 1400 mini-pci
Broadcom 4324 I believe
Gutsi RC, all updates, 2 days before launch :)

The speed is still ABYSMAL - and indeed it can be made somehow better by forcing the speed rate to 5.5M,

Bit Rate=5.5 Mb/s Tx-Power=14 dBm
RTS thr:off Fragment thr:off

but IT WORKS VERY WELL WITH NDISWRAPPER (after blacklisting bcm43xx), the difference seems to be:

Bit Rate=54 Mb/s Tx-Power:25 dBm
RTS thr:2347 B Fragment thr:2346 B

ALSO PLEASE NOTE THAT BCM43XX MIGHT GENERATE PROBLEMS ON SUSPEND/RESTORE!!! (basically I could never restore after suspend-to-RAM with bcm43xx, but with ndiswrapper it seems to work every time).

That also kind of reminds me of a very similar problem that the Windows BROADCOM original driver can have - there are 2 advanced settings for that driver that are power-related - "Power Save Mode" - which is best set to "Fast", and "Minimum Power Consumption" - which on this specific Dell 1400 = BCM4324 should be set to "Disabled" - when enabled the same incredibly small speed can be seen in Windows !!! That kind of suggests that a possible explanation might be that the Linux bcm43xx driver is somehow setting the corresponding internal status of the device to something similar to "Minimum Power Consumption" - which for this specific model (4324) does not seem to always work as expected !!!

I note in the activity log that this bug has not been worked for over a month. Please leave a short comment on why it would be changed to Triaged if that is the correct status. I am not trying to make more work on this, just trying to make sure the issue is still on the radar.

zeddock

Just reporting this still shows really poor performance, I can "attach" to the AP, but I can't ping any other host aside from the localhost DHCP assigned IP. My specific bug is Bug #92088 and it seems related.

This is in the now released 7.10

I've upgraded to 7.10, and the bcm4306 driver no longer works properly. It can scan network for the ssid, and with the speed set to 5.5M it can authenticate, but fails when it tries to get an address from the router. So this bug is definitely in 7.10.

Setting the rate down to 1M seems to work ok.

iwconfig eth1 rate 1M fixed

Strangely, I rebooted and it picked up the network fine. However, it has picked up the network with a bit rate of 24 Mb/s, which it was never able to before.

eth1 IEEE 802.11b/g ESSID:"zazz" Nickname:"Broadcom 4306"
          Mode:Managed Frequency=2.452 GHz Access Point: 00:19:DB:0E:36:2C
          Bit Rate=24 Mb/s Tx-Power=19 dBm
          RTS thr:off Fragment thr:off
          Link Quality=63/100 Signal level=-66 dBm Noise level=-69 dBm
          Rx invalid nwid:0 Rx invalid crypt:1 Rx invalid frag:0
          Tx excessive retries:0 Invalid misc:0 Missed beacon:0

It seems to drop a lot of packets at 24 Mb/s, at 1 Mb/s it seems pretty stable.

I had the same problem. Bu it seems that it was related to the interrupt controller. Setting kernel option noapic helped.

While I haven't tried the noapic solution, definitely resolved my flaky throughput issues with the fixed bitrate <= 11Mbps. I tried different drivers and even attempted to revert to using ndiswrapper.

It would make sense that it's the interrupt controller interaction. I'd like to help fix it, but just don't have the kernel source familiarity. All in time...

Thanks Ubuntu Team -- despite the bugs here and there, y'all have a stellar product.

I will second that "stellar product" comment.

However, these 43xx bugs really should be swatted. It's like a little stain
on an otherwise stunning white dress.

Please let me know how I can help.

zeddock

On 10/23/07, y2klemson <email address hidden> wrote:
>
> While I haven't tried the noapic solution, definitely resolved my flaky
> throughput issues with the fixed bitrate <= 11Mbps. I tried different
> drivers and even attempted to revert to using ndiswrapper.
>
> It would make sense that it's the interrupt controller interaction. I'd
> like to help fix it, but just don't have the kernel source familiarity.
> All in time...
>
> Thanks Ubuntu Team -- despite the bugs here and there, y'all have a
> stellar product.
>
> --
> Broadcom bcm43xx Wireless driver regression in gutsy
> https://bugs.launchpad.net/bugs/124159
> You received this bug notification because you are a direct subscriber
> of the bug.
>

After some digging it turned out that noapic doesn't work :( wifi sopts working at all. I dongraded to feisty kernel and... guess what everything works as a charm there is sth wrong with gutsy kernel I suppose.

After all this fighting, I upgraded to Gutsy release (wireless still wasn't working), installed ndiswrapper using Dell driver version 4.100 with v4 firmware. Works great. Very disappointed with the quality of native driver.

As a reminder, the bcm43xx native driver worked for me in Feisty. although only with WEP and only at 11MB/s. bcm43xx driver would load (with v3 firmware), but unable to find and/or connect to any wireless networks.

Would you mind linking to a post on HOW to get our wireless working better?

Thanx,

zeddock

On 10/24/07, michael37 <email address hidden> wrote:
>
> After all this fighting, I upgraded to Gutsy release (wireless still
> wasn't working), installed ndiswrapper using Dell driver version 4.100
> with v4 firmware. Works great. Very disappointed with the quality of
> native driver.
>
> As a reminder, the bcm43xx native driver worked for me in Feisty.
> although only with WEP and only at 11MB/s. bcm43xx driver would load
> (with v3 firmware), but unable to find and/or connect to any wireless
> networks.
>
> --
> Broadcom bcm43xx Wireless driver regression in gutsy
> https://bugs.launchpad.net/bugs/124159
> You received this bug notification because you are a direct subscriber
> of the bug.
>

@zeddock: Certainly.

I used this guide: https://help.ubuntu.com/community/WifiDocs/Driver/bcm43xx/Feisty_No-Fluff
My testimonial is posted inline on that page.

I can confirm this bug and that the line 'sudo iwconfig eth1 rate 5.5M fixed' solves this issue on a Dell Latitude D610
with Broadcom BCM4318 [AirForce One 54g] 802.11g Wireless LAN Controller

I have the issue too with gutsy released.

uname -r: 2.6.22-14-386
lspci: Network controller: Broadcom Corporation BCM94311MCG wlan mini-PCI (rev 01)

I blacklisted the bcm43xx native driver and compiled ndiswrapper 1.47 to use bcmwl5 one.
ndiswrapper -l
bcmwl5 : driver installed
        device (14E4:4311) present (alternate driver: bcm43xx)

I can scan the network, I can see ESSIDs, but I can't get any IP from DHCP servers.

The line 'sudo iwconfig eth1 rate 5.5M fixed' or whatever Meg didn't solve the problem.

Not that its necessary, but I'll confirm the gutsy problems.

uname -r : 2.6.22-14-generic
lspci : 02:02.0 Network controller: Broadcom Corporation BCM4306 802.11b/g Wireless LAN Controller (rev 02)

The sudo iwconfig hack seemed to work mildly for me. Before it was unusable, now it is just frustrating.

I too am experiencing this, with the following:

================================================================================
uname -r : 2.6.22-14-generic
lspci : 02:02.0 Network controller: Broadcom Corporation BCM4306 802.11b/g Wireless LAN Controller (rev 02)
================================================================================

Has there been any movement on this? Or will i be better off downgrading to feisty?

I just kept the loopback interface in /etc/network/interfaces
Thus I removed all the ethx entries in this file.

On Gutsy, network-manager was able to detect the wifi controller and connect to access-points.

Everything rox now!

Lau, What about non DHCP static connections?

Can we at least hope for a fix in Hardy?

EvilPaddy,

I did not get a chance to try non DHCP static connections. I will let you know asap.
My network controller Broadcom Corporation BCM94311MCG wlan mini-PCI (rev 01) is working 100% fine with Gutsy, kernel 2.6.22-14-generic, compiled ndiswrapper 1.47, bcmwl5 drivers and nm.

On Dec 12, 2007 8:35 AM, Thom Pischke <email address hidden> wrote:
> Can we at least hope for a fix in Hardy?

In hardy now work with linux image 2.6.22-14, idem to gutsy.
--
Cristian

The friend to whom I sold the laptop with the 4306 rev 2 decided to go wireless, so I'm looking at this issue again. Can confirm that setting wireless rate to 5.5M works wonders. Getting consistent 450 KB/s transfer rates now and seems stable. Am I right in concluding from previous comments that I should be able to bump the wireless rate to 11M with no adverse effects? This would be helpful for home network traffic.

Worth noting that I get noticeably better performance with 5.5M than 11M, counterintuitively.

Peak actual speed at 5.5M fixed rate: ~500KB/s, Average: 200-300 KB/s
Peak actual speed at 11M fixed rate: ~300KB/s, Average: 100-150

Speeds are quite erratic, so numbers above are just to make the comparative advantage of 5.5M rate over 11M rate bit more quantitative.

Glad you are back onto this even though it is a pain again for you. It
seems silly to me that this problem has not yet been resolved, but without
feedback of quality, as your feedback seems to be, I guess the fixers don't
have a lot to work with.

Please tell me how you are measuring the throughput? I am curious what this
newer Gusty install has left me with.

Thanx.

zeddock

On Dec 21, 2007 8:38 AM, Thom Pischke <email address hidden> wrote:

> Worth noting that I get noticeably better performance with 5.5M than
> 11M, counterintuitively.
>
> Peak actual speed at 5.5M fixed rate: ~500KB/s, Average: 200-300 KB/s
> Peak actual speed at 11M fixed rate: ~300KB/s, Average: 100-150
>
> Speeds are quite erratic, so numbers above are just to make the
> comparative advantage of 5.5M rate over 11M rate bit more quantitative.
>
> --
> Broadcom bcm43xx Wireless driver regression in gutsy
> https://bugs.launchpad.net/bugs/124159
> You received this bug notification because you are a direct subscriber
> of the bug.
>

Speeds above were observed while transferring a 4GB file over Samba via wireless connection. With other wireless cards, I typically get about 1.3 MB/s for the same transfer. With this frustrating broadcom card/driver the peak was just over 500KB/s with an average closer to 300. Usable and adequate for internet transfers, but lousy for home network.

Did an online test here: http://www.speedtest.net/

http://www.speedtest.net/result/214237258.png

That was at 5.5M.

Here's the same test at 11M
http://www.speedtest.net/result/214238098.png

And here at 24M:
http://www.speedtest.net/result/214238517.png

The trend is clear, increasing bitrate past 5.5M results in greater performance loss. Faster the bitrate, slower the transfer, ironically.

Upload speed is rock solid at all speeds.

Doh! That last comment was potentially misleading. Should have said that internet upload speed held constant at the limit of my internet connection bandwidth, 360 kbits/sec, regardless of wireless interface bitrate setting. This may be simply because it's far too slow to be impacted by this driver problem.

so how about someone write up an easy HOWTO for noobs, explaining how to set the rate to 5.5M permanently across reboots?

I'm also skeptical that this is fixed in hardy, since there has been some confusion in this post with another bug about not being able to connect to routers, which is unrelated to the original bug for which I opened this issue.

Not willing to upgrade (my non-technical friend's PC) to hardy just to test however.

One last speed test at 2M:
http://www.speedtest.net/result/214241873.png

Tried at 1M too, but it was slower than at 2M, around 2000 kbit/s

Note that I personally get the best performance at a rate of 2M, *not* 5.5M, and **definitely not** 11M

Testing again with Samba transfers over my home network, I see no practical difference between 2M and 5.5M, but 11M is definitely slower

Peak speed observed at 2M and 5.5M = 560 KB/s
Average: ~300 KB/s

(Rates observed via System Monitor Network Traffic Gauge)

Interestingly, I usually observe a short spike in speeds when I switch the bit rate. It will run at nearly 500 KB/s right after I switch from 5.5M to 2M, for instance, and then sink back to around 300 after 5-10 seconds. Weird stuff.

Ok, so here's my final complete workaround for this issue in gutsy, thanks to all those who have contributed! Hopefully this hack will not be needed in Hardy.

 1. Create a new script "bitratehack" in /etc/NetworkManager/dispatcher.d/
 2. Paste in the following:

#!/bin/sh
ACTION=$2
if [ "$ACTION" = "up" ]; then
     iwconfig eth1 rate 2M
fi

 3. sudo chmod 755 /etc/NetworkManager/dispatcher.d/bitratehack

Don't expect much progress on bcm43xx since it has been deprecated for new driver:
http://linuxwireless.org/en/users/Drivers/b43
http://bcm43xx.berlios.de/

Generally speaking don't expect much from these cards as Broadcom keeps the documentation secret and the native drivers are 100% reverse-engineered. And don't expect much from Ubuntu: they can do little more than packaging and shipping the code of kernel developers.

This aside I confirm that on my 4306 reducing the bitrate usually gives better stability and as a consequence a better throughput.

Just copy/paste the following statements *once* line by line to a console/terminal:

sudo su
echo -e '#!/bin/sh\niwconfig eth1 rate 5.5M auto' > /etc/network/if-pre-up.d/fixed-rate
echo -e '#!/bin/sh\niwconfig eth1 rate 5.5M auto' > /etc/network/if-up.d/fixed-rate
exit

Now disable/enable your wireless network or reboot to see the effect. Works for me.
This setting makes that your bcm will max out at 5.5M and go even lower if necessary.

Replace eth1 with your actual netwerk interface.

Peter

waddayaknow, previous comment was not entirely correct. It should have read:

sudo su
echo -e '#!/bin/sh\niwconfig eth1 rate 5.5M auto' > /etc/network/if-pre-up.d/fixed-rate
echo -e '#!/bin/sh\niwconfig eth1 rate 5.5M auto' > /etc/network/if-up.d/fixed-rate
chmod a+x /etc/network/if-pre-up.d/fixed-rate /etc/network/if-up.d/fixed-rate
exit

The files must be executable. Sorry for the noise.

Peter

I can confirm this! When I tried to switch from one to another I saw much
faster throughput for a short period, then it would die off. I do not have
numbers like Thom does, but I saw same nonetheless.

zeddock

On Dec 21, 2007 11:03 AM, Thom Pischke <email address hidden> wrote:

> Interestingly, I usually observe a short spike in speeds when I switch
> the bit rate. It will run at nearly 500 KB/s right after I switch from
> 5.5M to 2M, for instance, and then sink back to around 300 after 5-10
> seconds. Weird stuff.
>
> --
> Broadcom bcm43xx Wireless driver regression in gutsy
> https://bugs.launchpad.net/bugs/124159
> You received this bug notification because you are a direct subscriber
> of the bug.
>

Thom et. al.,

I've read with great interest this thread as I had recently crashed my Feisty installation which connected well at 11 Mb/s wirelessly to my router via the bcm43xx driver. I decided to move up to Gutsy, and decided to try to get connected wirelessly via ndiswrapper. Everything I tried for 2 days there failed and so I began researching online for help to try Gutsy with using fwcutter and the bcm43xx driver. I'm happy to report that I'm connected quite well with this driver and Gutsy (typing this wirelessly now). Some preliminary info:

Card: Linksys WMP54GS (Broadcom 4306)
PCI ID: 14e4:4320 (ver 03)
Linux: Ubuntu Gutsy Gibbon 7.10
uname -r: 2.6.22-14-generic
Connection Speed: NM reports 24 Mb/s. www.speedtest.net yielded
                  4,234 kb/s down and 4,840 up speed.

Since this was a fresh install of Gutsy just today (but from an October iso download), I'm in the process of downloading and applying updates. Hopefully this won't kill anything I've gotten working today.

I have to admit I'm still very much a Linux noob (pretty experienced with Windows computers though) as well as a Bugs.Launchpad.net total noob so my apologies if I'm not posting correctly here. But if there's additional information that I can provide to help this thread, please let me know. Thanks.

This looks like it is fixed in the Hardy alpha 2 with the 2.6.24 kernel. The newer b43 driver seems to work quite well.

Testing Live CD:
http://cdimage.ubuntu.com/releases/hardy/alpha-2/
https://wiki.ubuntu.com/HardyHeron/Alpha2

I am a new linux user who is experiencing a complete lack of functionality at all out of my broadcom 4306 rev 3 chipset. I t is on a belkin card. I would very much so like to know wher to get that functional driver.

The restricted Driver Manager should have offered to install it automatically. This issue is about stability issues pertaining to the driver it installs.

As Asleigh Gordon stated I can also confirm that my Broadcom card now works solidly on Hardy using b43-fwcutter.

@trj021782 you might be interesting on trying this on previous releases, as the page states these packages are unofficial so YMMV http://backports.trausch.us/2008/01/04/new-package-backports-b43-fwcutter/

@Thom Pischke
How difficult would it be to officially back port b43-fwcutter assuming it works OK?

i'm running Hardy alpha 4 with a Bcm4318 and the situation hasn't improved at all since Gutsy. I used b43-fwcutter to get the card working (seems like Ubuntu should prompt this automatically).

I'm getting sub 50Kps performance

The problem is still present in Hardy Alpha 5 with b43legacy (and the firmware that b43 firmware-cutter is automatically getting from the net). However b43legacy is a small step forward compared to bcm43xx since it now suspends/resumes OK :)

What is worse is that in Hardy there is also a big problem with ndiswrapper :(

(Broadcom cip is 4309 - pci id 4324 = Dell Wireless 1400 a/b/g or similar)

Hi Thom,

Since you are the original bug reporter, can you comment on if this is still an issue for you with the latest Hardy Alpha release? You can download and try the new Hardy Heron Alpha release from http://cdimage.ubuntu.com/releases/hardy/ . You should be able to then test the new kernel via the LiveCD. General information regarding the release can also be found here: http://www.ubuntu.com/testing/ . Thanks.

Well, I sold the laptop on which I originally had the issue. I still help the new owner with issues like these, so I will try to test with the LiveCD next time I'm over at his place, but since I'm about to head off on a three month vacation - this probably won't happen until after hardy has released. Not much help to you I suppose. Sorry!

Leann,

Here's my report for Hardy.

I have a Broadcom card:
05:00.0 Network controller: Broadcom Corporation BCM94311MCG wlan mini-PCI (rev 01)

And I can confirm that it works half decently in Hardy, but the speed still fluctuates a lot 12 kB/s to 109 kB/s (the later is the speed my ISP provides) but the problem is the "sensitivity" of the card, it only works if the laptop is on the same room that the wireless router is, if the laptop is moved to the next room connection is lost.

Problem still exists for me with Hardy Beta and BCM4318 AirForce One 54g on Dell Inspiron 2200. Looks like poor sensivity for me:

$ iwconfig wlan0
wlan0 IEEE 802.11g ESSID:"xxxx"
          Mode:Managed Frequency:2.437 GHz Access Point: 00:17:9A:C9:B8:29
          Bit Rate=2 Mb/s Tx-Power=10 dBm
          Retry min limit:7 RTS thr:off Fragment thr=2346 B
          Link Quality=80/100 Signal level=-25 dBm Noise level=-36 dBm
          Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0
          Tx excessive retries:0 Invalid misc:0 Missed beacon:0

There were no such problem with ndiswrapper (which i can't use now, btw).

I'm running into range issues (2 meters max) with the latest Hardy Beta.
03:02.0 Network controller: Broadcom Corporation BCM4318 [AirForce One 54g] 802.11g Wireless LAN Controller (rev 02)

Previously, when using ndiswrapper it was fine.

>waddayaknow, previous comment was not entirely correct. It should have read:
>
>sudo su
>echo -e '#!/bin/sh\niwconfig eth1 rate 5.5M auto' > /etc/network/if-pre-up.d/fixed-rate
>echo -e '#!/bin/sh\niwconfig eth1 rate 5.5M auto' > /etc/network/if-up.d/fixed-rate
>chmod a+x /etc/network/if-pre-up.d/fixed-rate /etc/network/if-up.d/fixed-rate
>exit
>
>The files must be executable. Sorry for the noise.
>
>Peter

Works like a charm on my hp 6710b!

Speed raised from approx 108kBps to 2204kBps

The Ubuntu Kernel Team is planning to move to the 2.6.27 kernel for the upcoming Intrepid Ibex 8.10 release. As a result, the kernel team would appreciate it if you could please test this newer 2.6.27 Ubuntu kernel. There are one of two ways you should be able to test:

1) If you are comfortable installing packages on your own, the linux-image-2.6.27-* package is currently available for you to install and test.

--or--

2) The upcoming Alpha5 for Intrepid Ibex 8.10 will contain this newer 2.6.27 Ubuntu kernel. Alpha5 is set to be released Thursday Sept 4. Please watch http://www.ubuntu.com/testing for Alpha5 to be announced. You should then be able to test via a LiveCD.

Please let us know immediately if this newer 2.6.27 kernel resolves the bug reported here or if the issue remains. More importantly, please open a new bug report for each new bug/regression introduced by the 2.6.27 kernel and tag the bug report with 'linux-2.6.27'. Also, please specifically note if the issue does or does not appear in the 2.6.26 kernel. Thanks again, we really appreicate your help and feedback.

Leann,

Just to confirm I still see rather poor performance/sensitivity on my wireless card with the latest updates. My details below:
$ uname -a
Linux inspiron-1501 2.6.27-4-generic #1 SMP Mon Sep 22 04:40:44 UTC 2008 i686 GNU/Linux
$ lspci -vvnn|grep etwork
05:00.0 Network controller [0280]: Broadcom Corporation BCM4311 802.11b/g WLAN [14e4:4311] (rev 01)

The latest update really worsened this situation as I can now see 200B/s speeds while doing aptitude update and frequent disconnects even when I'm 1.5 meters from the wireless router.

Please let me know what else is needed on my end. I really would like for this to be solved for good.

Marking invalid for linux-source-2.6.22, which is no longer present (in gutsy and beyond).

This is Kubuntu 8.10,

Linux deneb 2.6.27-7-generic #1 SMP Thu Oct 30 04:12:22 UTC 2008 x86_64 GNU/Linux

My network controller identifies as lspci
Network controller: Broadcom Corporation BCM4328 802.11a/b/g/n (rev 03)

Under gutsy I installed ndiswrapper and manually copied the appropriate drivers in place: worked great

Kubuntu Intrepid brought up the restricted driver manager, install worked and connect to wifi too.

But I experience the SAME problems as mentioned: When I am very close to the wifi router, speed is ok, when I am farther away it is unacceptable. The fix

iwconfig eth2 rate 5.5M auto

worked great.

Per a decision made by the Ubuntu Kernel Team, bugs will longer be assigned to the ubuntu-kernel-team in Launchpad as part of the bug triage process. The ubuntu-kernel-team is being unassigned from this bug report. Refer to https://wiki.ubuntu.com/KernelTeamBugPolicies for more information. Thanks.

Unfortunately it seems this bug is still probably an issue. Can you confirm this issue exists with the most recent Jaunty Jackalope 9.04 release - http://www.ubuntu.com/news/ubuntu-9.04-desktop . Please let us know your results. Thanks.

Hi,

Yes I confirm. Installed Jaunty a couple of days ago and had to go thru a
set of instructions to do a workaround regarding the PCMCIA Linksys card
that uses that chip; only after that workaround I was able to connect to a
wi-fi network. The last three releases I had to use this set of
instructions:
https://help.ubuntu.com/community/WifiDocs/Driver/bcm43xx/Feisty_No-Fluff .
For Jaunty I had to do the "hard bug fix" because - "If you type in lshw -C
network you might "module=ssb" instead of "module=ndiswrapper" This is
because Hardy has a module loading bug that takes control away from
ndiswrapper."

After that, working great!!! Great work, Ubuntu! And all the products,
people and ideas working around Linux!

Regards,
Marco Antunes.

-----Original Message-----
From: <email address hidden> [mailto:<email address hidden>] On Behalf Of
Colin King
Sent: terça-feira, 12 de Maio de 2009 10:21
To: <email address hidden>
Subject: [Bug 124159] Re: Broadcom bcm43xx Wireless driver regression in
gutsy

Unfortunately it seems this bug is still probably an issue. Can you confirm
this issue exists with the most recent Jaunty Jackalope 9.04 release -
http://www.ubuntu.com/news/ubuntu-9.04-desktop . Please let us know your
results. Thanks.

--
Broadcom bcm43xx Wireless driver regression in gutsy
https://bugs.launchpad.net/bugs/124159
You received this bug notification because you are a direct subscriber of
the bug.

On Marco's note https://bugs.launchpad.net/ubuntu/+source/linux/+bug/124159/comments/128 will mark this as Fix released.