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.

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.