bcm4306, bcm4309, bcm4311, bcm4312 with b43 : Authentication with AP doesn't work.

dmesg output. Only ndiswrapper was blacklisted.

$sudo mv etc/udev/rules.d/70-persistent-net.rules
/etc/udev/rules.d/70-persistent-net.rules.old

References:
http://bugzilla.kernel.org/show_bug.cgi?id=9402#c12
http://bugzilla.kernel.org/show_bug.cgi?id=9402#c14

It didn't change anything. (to be sure, I tried the extracted firmwares from wl_apsta_mimo.o then wl_apsta.o)

Attachment : dmesg after rebooting, lshw, ifconfig and network restart output.

hi,
today I upgraded my notebook to hardy (kernel 2.6.24-5.8) and I saw that putting my pcmcia broadcom 4306 card results in a 100% lockup system.
I haven't blacklisted anything and no firmware downloaded yet, anyway the lock shouldn't happen imo isn't?

hi all,

I've installed kubuntu hardy in my hp tx1000z notebook after installing in gutsy gibbon. In gutsy I got my wireless working after following this thread to use ndiswrapper:
http://ubuntuforums.org/showthread.php?t=297092

But in gutsy it didn't work. The problem was that ssb module was loaded. To rmmod it I had to rmmod ohci_hcd first. Then I reloaded ndiswrapper and it worked.

The problem is that I have to do that every time I start the computer, cause blacklist is not working to inhibit ssb loading. I tried $sudo mv etc/udev/rules.d/70-persistent-net.rules /etc/udev/rules.d/70-persistent-net.rules.old
and restarting, I've got this file changed, invoking ndiswrapper as driver, but ssb is in the middle all the way and I have to rmmod it to get wireless working.

Here my /etc/modprobe.d/blacklist, Hope it helps :) :

I had open a thread on:
https://bugs.launchpad.net/ubuntu/+source/ndiswrapper/+bug/188621

To resolve the problem i crate a boot script using this steps:

1) U must create a file in /etc/init.d/ndiswrapper:

sudo nano /etc/init.d/ndiswrapper

1.a) and paste in it this text:

#! /bin/sh
### BEGIN INIT INFO
# Provides: ndiswrapper
# Required-Start:
# Required-Stop:
# Default-Start: S
# Default-Stop:
# Short-Description: enable to load ndiswrapper
# Description: enable to load ndiswrapper
### END INIT INFO

rmmod ohci_hcd
rmmod ssb
rmmod ndiswrapper
modprobe ndiswrapper
modprobe ssb
modprobe ohci_hcd

############# end file ############

2) then set file access permissions:

sudo chmod 755 /etc/init.d/ndiswrapper

3) check if permissions are ok. Type:

ls -l /etc/init.d/ndiswrapper

[... ]
-rwxr-xr-x 1 root root 4388 2008-02-03 14:57 /etc/init.d/ndiswrapper
[... ]

4) last, create a symbolic link call S99ndiswrapper in the folder /etc/rc2.d, from /etc/init.d/ndiswrapper:

sudo ln -s /etc/init.d/ndiswrapper /etc/rc2.d/S99ndiswrapper

5) unplug your usb devices and pcmicia card and then reboot your machine.
6) when GDM start (the login screen), plug all USB device and pcmica cards that U want.

I had put in blacklist b43legacy and bcm43xx

If i try to use b43legacy the machine stop and i can't log the dmsg

Please Guys, this bug report is not about Ndiswrapper or system lockup.

Different troubles = Different bug reports. Thank you.

I wonder if this is close to what I have going on. Although the original poster has done far more then I could have guessed, so I need to try some of that and see if I get similar results at all.

My wireless worked under 7.10, although I would have to tell it to connect 3 or 4 times before it finally would, but once on it was fine.

However after I upgraded to 8.04 it did not even find the card. A few days ago more updates were released, and it then found the card, but it does not see any of the 4 wireless networks around me (I only ever used my own, but I could always at least see others).

I don't want to waste people's time, but I can't imagine that the issue I am having is mine alone. If there is something for me to post that might help connect it to this issue, or would tell if I should submit a separate bug report please let me know. I've just started trying to help out with bug reporting.

I've never used ndiswrapper either btw.

krop, from my understanding this bug always occurs i.e. no matter if you are using ndiswrapper or the native drivers. You could replace ndiswrapper with b43 in the example above and it should work.

Duplicating my comments from 188621...

Regarding the ohci_hcd / ssb issue, the required fix is CONFIG_USB_OHCI_HCD_SSB=n in kernel build config. This option, when enabled, makes ohci_hcd depend on ssb, but is only needed to support a USB controller that is found only in embedded devices (so not relevant to standard Ubuntu). As long as that option's set to y, ssb will be loaded whenever ohci_hcd is loaded, regardless of blacklisting or anything else.

In Mandriva's case, ohci_hcd was being loaded on all systems (even systems with no USB controller requiring the ohci_hcd driver) due to a change in mkinitrd. I don't know if this part also affects Ubuntu, but regardless, the above fixes the problem. Bug should be sent to your kernel devs.

The boot script from RedBass don't solve everything...
I have a bcm4306 wireless card in my Dell Inspiron 5150 laptop and with the script, it solve my wireless problem (using ndiswrapper by the way).

BUT: i have b44 module used to manage my wired ethernet port that is no more loaded because of the script...

Had to modify the script like this to correct my problem:

#! /bin/sh
### BEGIN INIT INFO
# Provides: ndiswrapper
# Required-Start:
# Required-Stop:
# Default-Start: S
# Default-Stop:
# Short-Description: enable to load ndiswrapper
# Description: enable to load ndiswrapper
### END INIT INFO

rmmod b44
rmmod ohci_hcd
rmmod ssb
rmmod ndiswrapper
modprobe ndiswrapper
modprobe ssb
modprobe ohci_hcd
modproble b44

############# end file ############

I can confirm that in Hardy Alpha 5 the problem that Adam is mentioning two comments above this one ( https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.24/+bug/182716/comments/13 ) IS STILL PRESENT !!! (that approach managed to fix the same problem under Mandriva so I guess the same workaround could be used in Ubuntu too)

I would like to CONFIRM that this bug still persists even with all Hardy updates as of today...

Hi All,

Just adding some extra info. The current Hardy kernel config shows the following. I'll have the kernel team to take a look to consider changing. Thanks.

:~/ubuntu-hardy/debian/config$ grep -rn "CONFIG_USB_OHCI_HCD_SSB" *
amd64/config:2784:CONFIG_USB_OHCI_HCD_SSB=y
hppa/config:1247:CONFIG_USB_OHCI_HCD_SSB=y
i386/config.386:1912:CONFIG_USB_OHCI_HCD_SSB=y
i386/config.generic:1908:CONFIG_USB_OHCI_HCD_SSB=y
i386/config.server:1914:CONFIG_USB_OHCI_HCD_SSB=y
ia64/config:2259:CONFIG_USB_OHCI_HCD_SSB=y
lpia/config:2566:CONFIG_USB_OHCI_HCD_SSB=y
powerpc/config:2430:CONFIG_USB_OHCI_HCD_SSB=y
sparc/config:1894:CONFIG_USB_OHCI_HCD_SSB=y

This bug was fixed in the package linux - 2.6.24-12.18

---------------
linux (2.6.24-12.18) hardy; urgency=low

  [Amit Kucheria]

  * Move Marvell 8686 and 8688 to LUM
  * Poulsbo: Sync patches with moblin/ume-hardy tree
  * Break if a patch fails to apply
  * SAUCE: implement smarter atime updates support
    - LP: #199427
  * Enable USB_PERSIST to allow devices with /root on usb to work with
    suspend
  * Enable USB_PERSIST across the board

  [Ben Collins]

  * build/config: Really fix ide on smp ppc configs
  * build/configs: Enable relatime config option for all flavors
  * build/abi: Ignore ide-core module for ppc, moved to built-in

  [Colin Ian King]

  * fix reversed logic for bbuild check leads to -j1 default
    - LP: #197040
  * Enable IDE_PMAC for powerpc-smp
    - LP: #196686
  * Disable CONFIG_USB_OHCI_HCD_SSB
    - LP: #182716
  * SAUCE: fix arcmsr + archttp64 calls dma_free_coherent() with irqs
    disabled - dmesg filled with warnings
    - LP: #194207

  [Jorge Boncompte [DTI2]]

  * Fix Messed multicast lists after dev_mc_sync/unsync
    - LP: #193468

  [Stefan Bader]

  * Add support for Apple Aluminium keyboards.
    - LP: #162083
  * SAUCE: Restore VT fonts on switch

  [Upstream Kernel Changes]

  * [NET]: Messed multicast lists after dev_mc_sync/unsync
  * KVM: x86 emulator: add support for group decoding
  * KVM: x86 emulator: group decoding for group 1A
  * KVM: x86 emulator: Group decoding for group 3
  * KVM: x86 emulator: Group decoding for groups 4 and 5
  * KVM: x86 emulator: add group 7 decoding
  * KVM: constify function pointer tables
  * KVM: Only x86 has pio
  * KVM: x86 emulator: group decoding for group 1 instructions
  * KVM: MMU: Decouple mmio from shadow page tables
  * KVM: Limit vcpu mmap size to one page on non-x86
  * KVM: VMX: Enable Virtual Processor Identification (VPID)
  * KVM: Use CONFIG_PREEMPT_NOTIFIERS around struct preempt_notifier
  * KVM: Disable pagefaults during copy_from_user_inatomic()
  * KVM: make EFER_RESERVED_BITS configurable for architecture code
  * KVM: align valid EFER bits with the features of the host system
  * KVM: allow access to EFER in 32bit KVM
  * kvm: i386 fix
  * KVM: export information about NPT to generic x86 code
  * KVM: MMU: make the __nonpaging_map function generic
  * KVM: export the load_pdptrs() function to modules
  * KVM: MMU: add TDP support to the KVM MMU
  * KVM: x86 emulator: Fix 'jmp abs'
  * KVM: x86 emulator: fix group 5 decoding
  * KVM: Fix kvm_arch_vcpu_ioctl_set_sregs so that set_cr0 works properly
  * KVM: Make the supported cpuid list a host property rather than a vm
    property
  * KVM: emulate access to MSR_IA32_MCG_CTL
  * KVM: remove the usage of the mmap_sem for the protection of the memory
    slots.
  * KVM: SVM: allocate the MSR permission map per VCPU
  * KVM: make MMU_DEBUG compile again
  * KVM: paravirtualized clocksource: host part
  * KVM: Add missing semicolon
  * KVM: x86 emulator: add ad_mask static inline
  * KVM: x86 emulator: make register_address, address_mask static inlines
  * KVM: x86 emulator: make register_address_increment and JMP_REL static
    inlines
  * KVM: Add API to retrieve the number of supported...

For what I can see with 2.6.24-12.20, SSB is still loaded when modprob'ing b43. Even with the latest kernel version, I can't use b43 to connect to my AP.

@krop
This will never change because b43 needs ssb.

Do you have proper firmware-files installed (do you have b43 and b43legacy directories in /lib/firmware)? If so, can you test the file-permissions (hardy b43-fwcutter-package did not fix file-permissions until recent upload of version 011). If this does not change anything or you do not have the required firmware, can you try to install latest b43-fwcutter-package and re-run /usr/share/b43-fwcutter/install_bcm43xx_firmware.sh as root manually?

Here's the result after running this script (the directory has the correct permissions in /lib/firmware) :

root@mokona:~# rmmod bcm43xx
root@mokona:~# modprobe b43
root@mokona:~# dmesg
[cut]
[360324.734065] ACPI: PCI Interrupt 0000:02:09.0[A] -> Link [APC4] -> GSI 19 (level, low) -> IRQ 19
[360324.754205] ssb: SPROM revision 1 detected.
[360324.771029] ssb: Sonics Silicon Backplane found on PCI device 0000:02:09.0
[360324.783051] b43-phy3: Broadcom 4306 WLAN found
[360324.858103] phy3: Selected rate control algorithm 'simple'
[360324.983406] udev: renamed network interface wlan0 to eth0
[360325.047452] input: b43-phy3 as /devices/virtual/input/input11
[360326.687343] Registered led device: b43-phy3:tx
[360326.688405] Registered led device: b43-phy3:rx
[360326.689284] Registered led device: b43-phy3:radio
[360327.675103] eth0: Initial auth_alg=0
[360327.675114] eth0: authenticate with AP 7a:7c:62:6a:c2:b4

root@mokona:~# ifconfig -a
eth0 Link encap:Ethernet HWaddr 00:0f:66:f2:8e:4a
          UP BROADCAST MULTICAST MTU:1500 Metric:1
          Packets reçus:0 erreurs:0 :0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 lg file transmission:1000
          Octets reçus:0 (0.0 B) Octets transmis:0 (0.0 B)

lo Link encap:Boucle locale
          inet adr:127.0.0.1 Masque:255.0.0.0
          UP LOOPBACK RUNNING MTU:16436 Metric:1
          Packets reçus:13596 erreurs:0 :0 overruns:0 frame:0
          TX packets:13596 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 lg file transmission:0
          Octets reçus:6626713 (6.3 MB) Octets transmis:6626713 (6.3 MB)

wmaster0 Link encap:UNSPEC HWaddr 00-0F-66-F2-8E-4A-00-00-00-00-00-00-00-00-00-00
          UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
          Packets reçus:0 erreurs:0 :0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 lg file transmission:1000
          Octets reçus:0 (0.0 B) Octets transmis:0 (0.0 B)

root@mokona:~# iwconfig
lo no wireless extensions.

wmaster0 no wireless extensions.

eth0 IEEE 802.11g ESSID:"freebox"
          Mode:Managed Frequency:2.447 GHz Access Point: 7A:7C:62:6A:C2:B4
          Tx-Power=27 dBm
          Retry min limit:7 RTS thr:off Fragment thr=2346 B
          Encryption key:off
          Link Quality:0 Signal level:0 Noise level:0
          Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0
          Tx excessive retries:0 Invalid misc:0 Missed beacon:0

root@mokona:~# /etc/init.d/networking restart
 * Reconfiguring network interfaces...There is already a pid file /var/run/dhclient.eth0.pid with pid 16242
killed old client process, removed PID file
Internet Systems Consortium DHCP Client V3.0.6
Copyright 2004-2007 Internet Systems Consortium.
All rights reserved.
For info, please visit http://www.isc.org/sw/dhcp/

wmaster0: unknown hardware address type 801
wmaster0: unknown hardware address type 801
Listening on LPF/eth0/00:0f:66:f2:8e:4a
Sending on LPF/eth0/00:0f:66:f2:8e:4a
Sending on Socket/fallback
DHCPRELEASE on eth0 to 192.168.15.254 port 67
send_packet: Network is un...

I have similar problems with my bcm4328.

I had to blacklist 'ssb' (and maybe b43) in /etc/modprobe.d/blacklist

blacklist ssb
blacklist b43

And then I used ndiswrapper with bcmwl5.inf

The b43 driver should not work with your hardware. According to the developers a 4306 w/ a revision less than 4 (your lshw says version=3) should use b43legacy. Please try that one and try again. Someone should fix the udev scripts to pull in the correct driver if they didn't already. What confuses me is that they say the kernel autoloader should have done the "right thing."

http://www.linuxwireless.org/en/users/Drivers/b43

Already done with the same result. Note that in both case, iwlist "sees" the wifi routers around me but fails to associate with the same timeout message.

With my bcm4311 I can connect with the b43 driver but the connection drops often and is slow. I get quite some dropped packets. A few kernels ago in hardy it worked very well

Relevant lshw output

           *-network
                description: Network controller
                product: BCM4311 [AirForce 54g] 802.11a/b/g PCI Express Transceiver
                vendor: Broadcom Corporation
                physical id: 3
                bus info: pci@0000:02:03.0
                version: 02
                width: 32 bits
                clock: 33MHz
                capabilities: bus_master
                configuration: driver=b43-pci-bridge latency=64 module=ssb

I have the same chipset and I can confirm the same behavior. The b43 can scan and see the networks, but not associate. It shows up in network-admin as 2 wired connections (a wlan0_rename and an eth0).
I tried b43legacy but it does absolutely nothing...

Same behavior with

02:03.0 Network controller: Broadcom Corporation BCM4309 802.11a/b/g (rev 02)

Can you explain why this has been marked as "Invalid" and "Fix Released" it its packages despite the fact that people have still been confirming this?

Weird thing is that dmesg reports that I have 4318 while lshw (see above) and lspci tell me I've got a 4311

[ 19.397550] b43-phy0: Broadcom 4318 WLAN found

This has not been fixed.

Can confirm that this bug still persists using a clean install of Hardy 8.04 beta, after applying all updates available as of 2000 UTC 22/03/2008.

Hardware: Dell Inspiron 500m laptop using Broadcom 4306 wireless card:-

ben@foo:~$ lspci -nn | fgrep Broadcom
01:03.0 Network controller [0280]: Broadcom Corporation BCM4306 802.11b/g Wireless LAN Controller [14e4:4320] (rev 02)

On first boot, suitable firmware was not present, and I was not prompted by the restricted devices manager. Used "sudo apt-get install b43-fwcutter" to get and extract firmware. Following this, the driver claims to be working:-

ben@foo:~$ dmesg | fgrep b43
[ 90.815294] b43legacy-phy0 debug: Loading firmware version 0x127, patch level 14 (2005-04-18 02:36:27)
[ 97.314665] Registered led device: b43legacy-phy0:tx
[ 97.315141] Registered led device: b43legacy-phy0:rx
[ 227.125221] b43legacy-phy0 debug: Chip initialized
[ 227.126611] b43legacy-phy0 debug: 30-bit DMA initialized
[ 227.127645] b43legacy-phy0 debug: Wireless interface started
[ 227.133624] b43legacy-phy0 debug: Adding Interface type 2
[ 968.018948] b43legacy-phy0 debug: Removing Interface type 2
[ 968.021628] b43legacy-phy0 debug: Wireless interface stopped
[ 968.021723] b43legacy-phy0 debug: DMA-32 0x0260 (RX) max used slots: 1/64
[ 968.021810] b43legacy-phy0 debug: DMA-32 0x0200 (RX) max used slots: 1/64
[ 968.021917] b43legacy-phy0 debug: DMA-32 0x02A0 (TX) max used slots: 0/128
[ 968.031654] b43legacy-phy0 debug: DMA-32 0x0280 (TX) max used slots: 0/128
[ 968.037434] b43legacy-phy0 debug: DMA-32 0x0260 (TX) max used slots: 0/128
[ 968.039134] b43legacy-phy0 debug: DMA-32 0x0240 (TX) max used slots: 0/128
[ 968.046624] b43legacy-phy0 debug: DMA-32 0x0220 (TX) max used slots: 2/128
[ 968.050723] b43legacy-phy0 debug: DMA-32 0x0200 (TX) max used slots: 0/128
[ 968.051957] b43legacy-phy0 debug: Radio initialized
[ 968.052106] b43legacy-phy0 debug: Radio initialized
[ 419.357337] b43legacy-phy0 debug: Loading firmware version 0x127, patch level 14 (2005-04-18 02:36:27)
[ 419.360620] Registered led device: b43legacy-phy0:tx
[ 419.361095] Registered led device: b43legacy-phy0:rx
[ 419.367056] b43legacy-phy0 debug: Chip initialized
[ 419.367844] b43legacy-phy0 debug: 30-bit DMA initialized
[ 419.368346] b43legacy-phy0 debug: Wireless interface started
[ 419.374583] b43legacy-phy0 debug: Adding Interface type 2

NetworkManager can then correctly probe networks, but cannot connect:

root@foo:~# NetworkManager --no-daemon
NetworkManager: <info> starting...
NetworkManager: <info> Found radio killswitch /org/freedesktop/Hal/devices/dell_wlan_switch
NetworkManager: <info> eth0: Device is fully-supported using driver 'e100'.
NetworkManager: <info> nm_device_init(): waiting for device's worker thread to start
NetworkManager: <info> nm_device_init(): device's worker thread started, continuing.
NetworkManager: <info> Now managing wired Ethernet (802.3) device 'eth0'.
NetworkManager: <info> Deactivating device eth0.
NetworkManager: <info> wlan0: Device is fully-supported using driver '(null)'.
NetworkManager: <info> wlan0: driver supports SSID scans (scan_capa 0x01).
NetworkManager: <inf...

I think this is a regression of the new network-manager-0.6.6 introduced some days ago.
Someone that can try an earlier build can confirm?

@ monoi, what do you get from
ifconfig
iwconfig

@Nattgew: I get an interface:-

root@foo:~# ifconfig
eth0 Link encap:Ethernet HWaddr 00:0d:56:72:25:37
          inet addr:192.168.1.66 Bcast:192.168.1.255 Mask:255.255.255.0
          inet6 addr: fe80::20d:56ff:fe72:2537/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
          RX packets:8164 errors:0 dropped:0 overruns:0 frame:0
          TX packets:5456 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:11037281 (10.5 MB) TX bytes:601170 (587.0 KB)

lo Link encap:Local Loopback
          inet addr:127.0.0.1 Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING MTU:16436 Metric:1
          RX packets:70 errors:0 dropped:0 overruns:0 frame:0
          TX packets:70 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:3500 (3.4 KB) TX bytes:3500 (3.4 KB)

wlan0 Link encap:Ethernet HWaddr 00:90:4b:1b:57:a6
          UP BROADCAST MULTICAST MTU:1500 Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)

wmaster0 Link encap:UNSPEC HWaddr 00-90-4B-1B-57-A6-00-00-00-00-00-00-00-00-00-00
          UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)

root@foo:~# iwconfig
lo no wireless extensions.

eth0 no wireless extensions.

wmaster0 no wireless extensions.

wlan0 IEEE 802.11g ESSID:""
          Mode:Managed Frequency:2.412 GHz Access Point: Not-Associated
          Tx-Power=27 dBm
          Retry min limit:7 RTS thr:off Fragment thr=2346 B
          Encryption key:off
          Link Quality:0 Signal level:0 Noise level:0
          Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0
          Tx excessive retries:0 Invalid misc:0 Missed beacon:0

The fact that NetworkManager can scan for APs correctly seems to suggest that b43legacy is at least partly operational...

Odd... b43legacy doesn't work at all for me, but b43 gets me exactly what you are getting.

Definitely b43legacy for me:

root@foo:~# lsmod | fgrep b43
b43legacy 129564 0
rfkill 8592 1 b43legacy
mac80211 165652 1 b43legacy
led_class 6020 1 b43legacy
input_polldev 5896 1 b43legacy
ssb 32772 1 b43legacy

I've just tried removing the network-manager package and configuring manually, and my wireless now works -- using it to post this. Therefore, looks like this is a regression in NetworkManager, as suggested by Cimmo...

@Nattgew: from http://linuxwireless.org/en/users/Drivers/b43,

"b43legacy should be used on all 4301 and 4303 cards. 4306 and 4309 cards with a MAC core revision of 4 or less should also use b43legacy. b43 should be used on all other cards."

My 4306 is rev 02, hence me being on b43legacy.

Changing to "Fix Released" as bug appears to be in NetworkManager, not b43 / ssb.

Yeah, I know that, but when I modprobe b43legacy, it does nothing. Modprobing b43 gives me what you got.
I couldn't get it to work even without Network Manager.

Ok, so all you did to get it to work is to install b43-fwcutter and it installed the firmware, and automatically started b43legacy.
And then you removed network-manager... how exactly did you configure it manually? Through the GUI or via iwconfig?

I disagree with you monoi. I get the timeout issue without using networkManager.
BTW, 4306 with a rev 03 also needs b43 :
- blacklist b43 and modproble b43legacy => no interface is created
- if b43 is not blacklisted, loading b43legacy also loads b43 (I don't know if it is a normal behaviour)

OK, it seems we possibly have two bugs -- one in NM, and one in the driver? If so, could someone who is still experiencing this bug change the status back to Confirmed?

To get my card working, I installed b43-fwcutter, which automatically downloaded and extracted some firmware, then I removed network-manager, then I used the System -> Network GUI to configure an access point.

According to /lib/modules/2.6.24-12-generic/modules.pcimap, my card (PCI ID 14e4:4320) is associated with bcm43xx and ssb -- but bcm43xx is blacklisted in /etc/modprobe.d/blacklist, so the ssb module gets loaded. I guess ssb must decide which of the b43, b43legacy drivers gets loaded, and this is what is going right for me but wrong for you? If so, this looks like a problem that needs to go up to the b43/ssb developers...

Yes, I think we need to figure out what exactly this bug is...
Do you have the b43 module or the bcm43xx running when it works?
From the previous comments, it seems that it works the other way around, that b43 calls ssb.

Ok, so, another confirm, this time with a 4311 rev 2 (Worked fine under bcm43xx, worked fine under older (2.6.24-5 and 2.6.24-8) kernels.

Card seems to drop connection every 20 minutes or so (actually deassociates from Access point (despite being less than 15 feet away, open air)). This reults in NetworkManager showing the card disconnected (and really annoying me).

I installed the card with b43-fwcutter autoinstalling the firmware

ifconfig:

me@me-laptop:~$ ifconfig
eth0 Link encap:Ethernet HWaddr 00:1b:38:8b:80:be
          UP BROADCAST MULTICAST MTU:1500 Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
          Interrupt:21 Base address:0x1000

lo Link encap:Local Loopback
          inet addr:127.0.0.1 Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING MTU:16436 Metric:1
          RX packets:35617 errors:0 dropped:0 overruns:0 frame:0
          TX packets:35617 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:1781596 (1.6 MB) TX bytes:1781596 (1.6 MB)

wlan0 Link encap:Ethernet HWaddr 00:1a:73:b0:8b:1b
          UP BROADCAST MULTICAST MTU:1500 Metric:1
          RX packets:128413 errors:0 dropped:0 overruns:0 frame:0
          TX packets:65880 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:142615884 (136.0 MB) TX bytes:6819396 (6.5 MB)

wmaster0 Link encap:UNSPEC HWaddr 00-1A-73-B0-8B-1B-00-00-00-00-00-00-00-00-00-00
          UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)

iwconfig:

me@me-laptop:~$ iwconfig
lo no wireless extensions.

eth0 no wireless extensions.

wmaster0 no wireless extensions.

wlan0 IEEE 802.11g ESSID:"home"
          Mode:Managed Frequency:2.437 GHz Access Point: 00:0C:E5:51:90:1A
          Bit Rate=1 Mb/s Tx-Power=27 dBm
          Retry min limit:7 RTS thr:off Fragment thr=2346 B
          Link Quality=71/100 Signal level=-61 dBm Noise level=-73 dBm
          Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0
          Tx excessive retries:0 Invalid misc:0 Missed beacon:0

I'll get a dmesg up soon, but includes quite a few lines (1800), many including reassociate and deassociate(reason 3).

Sounds good, I might get one up, too, I'm working on getting a test rig up for it.
Changed the summary to reflect confirmations on other cards.

I too confirm that this bug still exists. I have bcm4306 rev 3 chipset in Linksys WPC54G Notebook Adapter. I did as mentioned in the original report - changed blacklist to enable bcm43xx, blacklist b43 and ssb and modprobe bcm43xx. Then installed bcm43ww-fwcutter using synaptic and hence the firmware. Then (having set up my wireless essid and WPA etc.) wireless worked. However, it still needs essid and WPA set up using iwconfig every bootup to get wireless working.

Correction to above. Should be bcm43xx-fwcutter.

Got a thread that seems to regard this here.
http://ubuntuforums.org/showthread.php?p=4570403
A 4312 rev 02

Maybe we should split the networkManager bug and the "timeout when authentificating" one since they don't seem to be linked ?

Look at the dates, I've been experiencing this issue for more than two monthes now. The bug NM users have appeared a few days ago.

I think that someone with the NM bug should report that. I had this bug regardless of NM.

The problem: WLAN does not work with network-manager 0.6.6-0ubuntu2 in Hardy beta.

Hardware: Broadcom 4311 WLAN on a HP nc8430

The problem appears when enabling wireless after disconnecting LAN or when connecting to another WLAN or when choosing a wireless network from nm-applet (it finds existing WLANs). Network-manager accepts the passwords & WLAN security settings. Problem begins when pressing "connect":

The animated "balls" (nm-applet) keep animating (trying to connect) but stay grey (no green).
Alternatively, the signal strength bars appear immediately without the animated balls appearing first. The bars remain grey.

Network-manager ceases at this point to respond to any controls: manual wlan switch, trying to switch to another network (wlan or lan), ticking off the boxes (network, wireless) on nm-applet, trying to kill nm through system administration program.

The connection does not work, the adapter doen not get an IP address, it seems to keep keep negotiating/waiting (for the network key?) indefinitely. The processor is also getting hot at this point, until rebooting. Some process gets into a loop presumably.

With network-manager 0.6.6-0ubuntu1 everything worked as expected.
Solution to problem so far: everything started working as expected immediately when downgrading back to 0.6.6-0ubuntu1

The files for working and non-working cases are attached.
In the non-working case the listings have been taken with nm/wlan trying to make a connection.
In the working scenario the listings havve been taken with wlan connected.

Here's the working solution data.

@ Juksu: I think your issue (which is identical to the one I saw) might be the same as the one logged in https://bugs.launchpad.net/bugs/205259.

This thread is for a separate issue with the b43/b43legacy driver itself and BCM4306 rev 03 cards.

@monoi: I am using the BCM4311 card with b43-fwcutter on Hardy beta. With the same symptoms as many others in this thread are getting. My post is FYI only to help solve this problem, wherever its root cause is. Thanks, i'll investigate furher.

My bcm4306 rev 03 works reasonably well (drops out a lot on my home network), with b43/ssb (NOT b43-legacy). Seems wierd, but it's true :) (although I started this morning, and knetworkmanager isn't showing up..)

happy to do testing if requested (be specific)

naught101@naught101-laptop:~$ lsmod|grep b43
b43 118304 0
rfkill 8848 3 rfkill_input,b43
mac80211 168212 1 b43
led_class 6148 1 b43
input_polldev 5896 1 b43
ssb 33028 1 b43

naught101@naught101-laptop:~$ lspci
02:03.0 Network controller: Broadcom Corporation BCM4306 802.11b/g Wireless LAN Controller (rev 03)

and more specifically:
naught101@naught101-laptop:~$ lspci -vvnnn
02:03.0 Network controller [0280]: Broadcom Corporation BCM4306 802.11b/g Wireless LAN Controller [14e4:4320] (rev 03)
        Subsystem: Dell Wireless 1350 WLAN Mini-PCI Card [1028:0003]
        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: 64
        Interrupt: pin A routed to IRQ 18
        Region 0: Memory at dfcfe000 (32-bit, non-prefetchable) [size=8K]

That's odd that yours works and ours don't... did you do anything special?
I did a base install of the Beta, put in the firmware for bcm43xx, rmmodded b43 and ssb, loaded bcm43xx, and updated and stuff over the wireless. I then rmmodded bcm43xx and loaded b43... no go. This is what I had:

all I did was install from alpha6, then run the FWcutter script at
/usr/share/b43-fwcutter/install_bcm43xx_firmware.sh
and it worked.

as far as I can tell, I SHOULD be using b43legacy, right? should all the
cards in this bug run under b43legacy?

ned

Nattgew wrote:
> That's odd that yours works and ours don't... did you do anything special?
> I did a base install of the Beta, put in the firmware for bcm43xx, rmmodded b43 and ssb, loaded bcm43xx, and updated and stuff over the wireless. I then rmmodded bcm43xx and loaded b43... no go. This is what I had:
>
>
>
> ** Attachment added: "dmesg and iwconfig"
> http://launchpadlibrarian.net/12832491/Dump
>

--
Contact me on:
Jabber/googletalk: <email address hidden>
Skype: naught101
msn: <email address hidden>
ICQ: 93344350
IRC: irc.indymedia.org #climateimc #oceania
phone: 0417 484 73
--------------------------------------------
http://eco101.wordpress.com

ENVIROWIKI is growing, but needs YOUR help
http://www.envirowiki.info/ - the wiki resource for enviro and social
justice activists that YOU can edit!

"This is the first age that's ever paid much attention to the future,
which is a little ironic since we may not have one." - Arthur C. Clarke
--------------------------------------------

Ok, can you do a dmesg for us? Maybe right after you boot and it works?
Also, have you updated from Alpha 6?
Yes, b43legacy should be it, but for me it does nothing. I find that b43 works but gives the "link not ready" message.
I ran my Beta... did all kinds of module loading... got nothing. I tried rebooting... nothing. Still "link not ready."

dmesg attached.

Today I cannot connect to my home wireless at all. It uses WEP. Since installing hardy I've always been able to connect to my girlfriend's home network, which uses WPA.

I'm getting lines like this in my system log:
24/03/08 13:08:27 naught101-laptop avahi-autoipd(wmaster0)[7213] Found user 'avahi-autoipd' (UID 104) and group 'avahi-autoipd' (GID 112).
24/03/08 13:08:27 naught101-laptop avahi-autoipd(wmaster0)[7213] Interface not suitable.
24/03/08 13:08:27 naught101-laptop avahi-autoipd(wmaster0)[7213] Successfully called chroot().
24/03/08 13:08:27 naught101-laptop avahi-autoipd(wmaster0)[7213] Successfully dropped root privileges.
24/03/08 13:08:27 naught101-laptop dhclient No DHCPOFFERS received.
24/03/08 13:08:27 naught101-laptop dhclient No working leases in persistent database - sleeping.
24/03/08 13:08:27 naught101-laptop NetworkManager <info> Activation (wlan0): waiting for device to cancel activation.
24/03/08 13:08:57 naught101-laptop none last message repeated 30 times
24/03/08 13:09:57 naught101-laptop none last message repeated 60 times
24/03/08 13:10:42 naught101-laptop none last message repeated 45 times
24/03/08 13:10:43 naught101-laptop dhclient DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 4
24/03/08 13:10:46 naught101-laptop none last message repeated 3 times
24/03/08 13:10:47 naught101-laptop dhclient DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 9
24/03/08 13:10:55 naught101-laptop none last message repeated 8 times
24/03/08 13:10:56 naught101-laptop dhclient DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 10
24/03/08 13:11:05 naught101-laptop none last message repeated 9 times
24/03/08 13:11:06 naught101-laptop dhclient DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 8
24/03/08 13:11:13 naught101-laptop none last message repeated 7 times
24/03/08 13:11:14 naught101-laptop dhclient No DHCPOFFERS received.
24/03/08 13:11:14 naught101-laptop dhclient No working leases in persistent database - sleeping.
24/03/08 13:11:45 naught101-laptop none last message repeated 31 times
24/03/08 13:12:29 naught101-laptop none last message repeated 44 times
24/03/08 13:12:30 naught101-laptop dhclient DHCPDISCOVER on wmaster0 to 255.255.255.255 port 67 interval 5
24/03/08 13:12:30 naught101-laptop NetworkManager <info> Activation (wlan0): waiting for device to cancel activation.
24/03/08 13:12:34 naught101-laptop none last message repeated 4 times
24/03/08 13:12:35 naught101-laptop dhclient DHCPDISCOVER on wmaster0 to 255.255.255.255 port 67 interval 14
24/03/08 13:12:35 naught101-laptop NetworkManager <info> Activation (wlan0): waiting for device to cancel activation.
24/03/08 13:12:48 naught101-laptop none last message repeated 12 times
24/03/08 13:12:49 naught101-laptop dhclient DHCPDISCOVER on wmaster0 to 255.255.255.255 port 67 interval 10
24/03/08 13:12:49 naught101-laptop NetworkManager <info> Activation (wlan0): waiting for device to cancel activation.
24/03/08 13:12:58 naught101-laptop none last message repeated 9 times
24/03/08 13:12:59 naught101-laptop dhclient DHCPDISCOVER on wmaster0 to 255.255.255.255 port 67 interval 2
24/03/08 13:12:59 naught101-laptop Net...

Ok, thanks for the info.
I'll attempt a configuration with WPA sometime tonight or tomorrow (or the next day?) to see if it works with that and not WEP.
Have you tried removing or killing network-manager (killall nm-applet), and configuring it with the Gnome tool or command line?

I can successfully connect to my home network with wlassistant, but the automatic dchp connection doesn't work, and I have to run "sudo dhclient" after connecting. But it still seems to be dropping out regularly (ever few minutes), and generally having trouble connecting to websites, even though I'm right next to the router.

I'm going to try upgrading to the debian unstable version of networkmanager (0.6.2 > 0.6.5)

/me goes back to wired connection to post

ignore that last sentence .

@nattgew : I am using WPA and have the issue.
@naught101 : Thank you for your report. We have the same chipset (on different pci cards). What I thought is now confirmed : this chipset *uses* b43 and not b43legacy despite the rev. being < 4.

02:09.0 Network controller [0280]: Broadcom Corporation BCM4306 802.11b/g Wireless LAN Controller [14e4:4320] (rev 03)
        Subsystem: Linksys Unknown device [1737:0013]
        Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
        Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
        Latency: 32
        Interrupt: pin A routed to IRQ 20
        Region 0: Memory at fdffe000 (32-bit, non-prefetchable) [size=8K]

Yeah, naught101 has a different card. krop and I have the same one. I guess that's the difference?
So is it just this one card specifically or do other cards have the same symptoms?

I sent a message to bcm43xx-dev mailing list with a link to this bug report. The answers should be readable here : https://lists.berlios.de/pipermail/bcm43xx-dev/2008-March/007090.html

This affects BCM4328 as well.
My solution is as follows:
____________________________
rmmod b43
rmmod b44
rmmod ssb
rmmod ndiswrapper
modprobe ndiswrapper
modprobe b44
___________________________

This fixes all troubles. SSB will load no matter what (even when blacklisted) so the only solution I have found is to run these commands at boot.

Yeah, ndiswrapper and bcm43xx seem to still work (mostly), so that's good.
@ krop, thanks for doing that. It's not specific to WPA, though... I get the same with WEP. Probably unencrypted, too.

Right. as of an upgrade yesterday, my card is no-longer being picked up at all by knetworkmanager. I can't see any wireless networks.

attached is all the packages that I upgraded (or installed) yesterday, from dpkg.log

First I'm unlinking this kernel bug since they never mention what kind of card it is, and that fix does not work here.
http://bugzilla.kernel.org/show_bug.cgi?id=9402

I'm unlinking the Mandriva bug too, because that's about ssb loading when it should not be, and that does not appear to be the issue here.
https://qa.mandriva.com/show_bug.cgi?id=36972

If this is wrong, please do link them back.

Same problem here. I have an eth0 (broadcom 4401-b0) which uses module b44 (and it pulls in ssb) and trying to use ndiswrapper for my wlan0 (broadcom 4328). wlan0 does not work when I load ndiswrapper, and no error messages. However, if I rmmod b44 and ssb, then modprobe ndiswrapper, wlan0 gets created and works fine.

Since b44 is an ethernet module, I don't understand how it can be the "same problem", sorry.
If you don't use your ethernet card, just blacklist b44 or disable it your computer bios (if possible).

The issue is that ssb and ndiswrapper conflict. b44 relies on ssb, and is
loaded before ndiswrapper. Further, blacklisting will not prevent the b44,
b43, or ssb modules from being loaded.

On Mon, Mar 31, 2008 at 10:49 AM, krop <email address hidden> wrote:

> Since b44 is an ethernet module, I don't understand how it can be the
> "same problem", sorry.
> If you don't use your ethernet card, just blacklist b44 or disable it your
> computer bios (if possible).
>
> --
> bcm4306, bcm4309, bcm4311, bcm4312 don't work with b43 / ssb
> https://bugs.launchpad.net/bugs/182716
> You received this bug notification because you are a direct subscriber
> of the bug.
>

So I confirm it is unrelated to what I reported.
The triage team considers that every problem related to SSB are duplicates of this one for unknown reasons.

I'm very happy we have learnt how to get rid of the wlan0_rename interface (or at least get a proper name). I'm pleased to see that ohci_hcd does not require ssb anymore, but all that has nothing to do with the timeouts Nattgew and I encounter when using the b43 driver.

See the last posts and the thread on bcm43xx-dev mailing list.

I would just like to add that the bcm4318 is also affected by this bug.

My wireless worked with Alpha 6 but ceased to do so since Beta (possibly even before, I haven't updated in between). The light will turn on, but no connection is detected. The same machine connects using Gutsy.

Maybe this whole issue is also related to bug 197959.

Sokraates have you checked the bug #184976 ?

I own a bcm4318 too and it works after running a skript. See my comments at:

https://bugs.launchpad.net/ubuntu/+bug/184976/comments/15
https://bugs.launchpad.net/ubuntu/+bug/184976/comments/21
https://bugs.launchpad.net/ubuntu/+source/ndiswrapper/+bug/188621/comments/21

There are so many bug reports about bcm43xx that I get the impression ... we don't know in where to post. At least for the bcm4318 I can verify that it works using the refered skript. If more users can verify that ..we could distinguish this problem from other bugs.

Running fwcutter manually and a reboot helped me. Thanks!

# sudo /usr/share/b43-fwcutter/install_bcm43xx_firmware.sh

My Info:
# lspci | grep Broadcom\ Corporation
03:00.0 Network controller: Broadcom Corporation BCM94311MCG wlan mini-PCI (rev 01)

I have a bcm4318 (rev 2) card.
I cannot get it to work.
The script to install manually also didn't help here.

Hello:

I have an ASUS WL-138G V2 PCI wireless card with the following lspci stamp:

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

When I load B43 (have the b43-fwcutter) firmware all installed, I keep getting the dreaded:

Apr 10 14:19:29 hero kernel: [ 115.595095] wlan0: authenticate with AP 00:06:25:f6:ed:f8
Apr 10 14:19:29 hero kernel: [ 115.794734] wlan0: authenticate with AP 00:06:25:f6:ed:f8
Apr 10 14:19:30 hero kernel: [ 115.994576] wlan0: authenticate with AP 00:06:25:f6:ed:f8
Apr 10 14:19:30 hero kernel: [ 116.194421] wlan0: authentication with AP 00:06:25:f6:ed:f8 timed out

after trying WEP, WPA2 Personal and open network, I decided to go back to BCM43xxx (old driver). I installed the firware and now my card works fine over an open network. WEP secured network is really slow.

This is much better than B43 kernel module. BTW, I removed b43 and ssd modules.

Kernel using is:

Linux hero 2.6.24-15-generic #1 SMP Tue Apr 8 00:33:51 UTC 2008 i686 GNU/Linux

This was a fresh install from the Ubuntu 8.04 (Hardy Heron) Beta CD with all the updates as of 22:49 UTC (April 10)

Hope this helps

Hi guys,

I think I have the same bug here.

My details:
* 8.04 Hardy Beta (installed 2 weeks ago or so) with updates to now (April 12 11pm GMT +1)
* Kernel: Linux xxx 2.6.24-16-generic #1 SMP Thu Apr 10 12:47:45 UTC 2008 x86_64 GNU/Linux (2.6.24-12 and 2.6.24-15 weren't working either)
* 04:04.0 Network controller [0280]: Broadcom Corporation BCM4318 [AirForce One 54g] 802.11g Wireless LAN Controller [14e4:4318] (rev 02)
* Installed b43-fwcutter and run /usr/share/b43-fwcutter/install_bcm43xx_firmware.sh manually (checked file perms)
* module b43 loaded (this is the one recommended by the b43 developers. See: http://linuxwireless.org/en/users/Drivers/b43/faq#Q.3AI.27mconfusedaboutthisb43.2BAC8-b43legacybusiness.WhichonedoIneed.3F)
* Tried setup with NM and manually
* Used to work with gutsy (not flawlessly but it did)
* I can see the AP with
  $ sudo iwlist wlan0 scan
wlan0 Scan completed :
          Cell 01 - Address: 00:1D:7E:C6:9D:C5
                    ESSID:"essid"
                    Mode:Master
                    Channel:11
                    Frequency:2.462 GHz (Channel 11)
                    Quality=65/100 Signal level=-42 dBm Noise level=-50 dBm
                    Encryption key:on
                    IE: WPA Version 1
                        Group Cipher : TKIP
                        Pairwise Ciphers (1) : TKIP
                        Authentication Suites (1) : PSK
                    Bit Rates:1 Mb/s; 2 Mb/s; 5.5 Mb/s; 11 Mb/s; 18 Mb/s
                              24 Mb/s; 36 Mb/s; 54 Mb/s; 6 Mb/s; 9 Mb/s
                              12 Mb/s; 48 Mb/s
                    Extra:tsf=00000019e75db186

* dmesg output
Apr 12 23:21:54 xxx kernel: [11484.584600] wlan0: Initial auth_alg=0
Apr 12 23:21:54 xxx kernel: [11484.584602] wlan0: authenticate with AP 00:1d:7e:c6:9d:c5
Apr 12 23:21:55 xxx kernel: [11484.784331] wlan0: authenticate with AP 00:1d:7e:c6:9d:c5
Apr 12 23:21:55 xxx kernel: [11484.983729] wlan0: authenticate with AP 00:1d:7e:c6:9d:c5
Apr 12 23:21:55 xxx kernel: [11485.183373] wlan0: authentication with AP 00:1d:7e:c6:9d:c5 timed out

Hopefully we can track down this problem!

Cheers,
livewire

Hello Guys:

I did some sniffing around the B43 mailing list and found a lengthy thread about the ASUS WL-138G v2, which uses Broadcom Corporation BCM4318 [AirForce One 54g] 802.11g Wireless LAN Controller (rev2).

It seems that Asus mucked with the registers (sorry if I am using the wrong wording). There is a patch for 2.6.26 kernel but it is more of "detect this ID then do something specific".. What it boils down to is that Asus enabled some Bluetooth interference trigger that is causing B43 kernel module to freak out and that is why it is timing out.

Here it he patch for whoever is interested. Just remember, it is for 2.6.26 kernel <http://lists.berlios.de/pipermail/bcm43xx-dev/2008-April/007330.html>. Also the entire thread if very interesting and worth a read. You can get it here <http://lists.berlios.de/pipermail/bcm43xx-dev/2008-April/007312.html>

I am not going to fart around with this card any more. I will go and get me a simpler card for about $25 bucks cause it sounds like ASUS messed this card up.

Originally, I had the same problem - Dmesg reported that with b43 and the correct firmware installed, using network-manager to try to connect to my WPA protected network, the attempts to associate with the access point would repeatedly "time out".

Using Hardy Heron with 2.6.24-16-generic kernel.

Here's my card info:

00:0a.0 Network controller [0280]: Broadcom Corporation BCM4306 802.11b/g Wireless LAN Controller [14e4:4320] (rev 03)
 Subsystem: Linksys Unknown device [1737:0013]
 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: 32
 Interrupt: pin A routed to IRQ 11
 Region 0: Memory at ea010000 (32-bit, non-prefetchable) [size=8K]

My solution was to, as has been suggested before, blacklist b43 and ssb, and modprobe bcm43xx. The steps I took are as follows:
Replaced the firmware files from a successful bcm43xx-fwcutter run that I knew from previous experience would work to /lib/firmware;
(Notice that the difference between bcm43xx and b43-fwcutters is quite important);
I blacklisted b43 and ssb, and unblacklisted bcm43xx while I was there (I used "sudo nano /etc/modprobe.d/blacklist");
Re-started, network-manager reported no wireless devices, so I just un-installed it;
Wrote my /etc/network/interfaces file by hand;
Then using ifup I brought the card up, and it works fairly okay - I not reached peak speed with it yet, but it's yet to drop packets or anything.

Sorry for the double post, didn't figure out how to (if it's possible) edit a comment.

Something pretty strange just happened to me.

I got the connection working fine - as posted above - so I restarted the computer.

It came back up and the wlan0 was missing.

I tried all kinds of combinations of things, before finally
sudo modprobe -r bcm43xx
sudo modprobe bcm43xx

worked.

What does that mean? Does that mean that it has to be loaded AFTER the initial boot process to work? Is there any way that I could automate that?

Sorry, it seems that removing then reloading the bcm43xx isn't enough -

I had to
sudo modprobe -r bcm43xx
sudo modprobe b43
sudo modprobe -r b43
sudo modprobe bcm43xx

@Jimmey : Actually, that's a workaround, not a solution. It seems this bug won't be resolved in kernel 2.6.24.

If you don't need b43 nor ssb, blacklist them both. Only bcm43xx will be loaded.

@krop
I had the same problem as Jimmey described. My broadcom 4306 v03 was working under Gutsy (probably with bcm43xx), and then I did as suggested
- Blacklisted b43 and ssb in /etc/modprobe.d/blacklist
- authorized bcm43xx
- reinstalled the bcm43xx-firmware
reboot; wireless did not work

then with b43 and ssb still blacklisted I did
sudo modprobe -r bcm43xx
sudo modprobe bcm43xx
still a no go

and then as he suggested afterward
sudo modprobe -r bcm43xx
sudo modprobe b43
sudo modprobe -r b43
sudo modprobe bcm43xx

this time it started -> I am actually posting with the wireless ;)

This is a bad method, is there a workaround?

[quote]
sudo modprobe -r b43
sudo modprobe bcm43xx
[/quote]

That just means you're using the same workaround : unloading the b43 module and loading bcm43xx instead.

Actually not. b43 being blacklisted it isn't loaded at startup (I verified
it)

On the contrary I unload bcm43xx
load b43
unload b43
and then load again bcm43xx

It seems to me that b43 does some kind of initialisation which allows iwlist
scanning to work but not to associate with an AP. Then by reloading bcm43xx
I can associate with AP

2008/4/26 krop <email address hidden>:

> [quote]
> sudo modprobe -r b43
> sudo modprobe bcm43xx
> [/quote]
>
> That just means you're using the same workaround : unloading the b43
> module and loading bcm43xx instead.
>
> --
> bcm4306, bcm4309, bcm4311, bcm4312 with b43 : Authentification with AP
> doesn't work.
> https://bugs.launchpad.net/bugs/182716
> You received this bug notification because you are a direct subscriber
> of the bug.
>

That is what is bug report is talking about.

We *know* bcm43xx is working... bcm43xx is now deprecated and will be removed in future kernels.
The way you load or unload b43 or bcm43xx is irrelevant. The problem remains the same : some wireless cards are unable to associate with their AP in kernel 2.6.24.

Unfortunately, that's not the actual stable kernel but the one shipped with Ubuntu Hardy.

[quote]That is what is bug...

That is what this* bug... (sorry)

Hi guys,

i have same problems with the b43 driver. I have a „Asus WL-138G v2“ wlan pci card. I can scan network but i can't connect. In the kernel log I see timeouts . On ubuntuusers more than me have the same problems (http://forum.ubuntuusers.de/topic/168892).

I have test it on an upgraded computer and a new installed computer.

I use now the bcm43xx driver, too. That works correct

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

 Subsystem: ASUSTeK Computer Inc. Unknown device 100f

 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: 64

 Interrupt: pin A routed to IRQ 19

 Region 0: Memory at feafe000 (32-bit, non-prefetchable) [size=8K]

error in the kernel log
wlan0: Initial auth_alg=0

wlan0: authenticate with AP 00:16:01:4b:xx:xx

wlan0: authenticate with AP 00:16:01:4b:xx:xx

wlan0: authenticate with AP 00:16:01:4b:xx:xx

wlan0: authentication with AP 00:16:01:4b:xx:xx timed out

Hi.

I'd like to confirm the issue with the Asus-based bcm4318 card as already described in full length above. Some details follow, but nothing new which has not already been told.

Using a fresh installation of Kubuntu Hardy 8.04 on a Dell Inspiron 531.

~$ uname -a
Linux gromp 2.6.24-16-generic #1 SMP Thu Apr 10 12:47:45 UTC 2008 x86_64 GNU/Linux

~$ lspci -v
[snipped for brevity]
01:09.0 Network controller: Broadcom Corporation BCM4318 [AirForce One 54g] 802.11g Wireless LAN Controller (rev 02)
        Subsystem: ASUSTeK Computer Inc. Unknown device 100f
        Flags: bus master, fast devsel, latency 32, IRQ 17
        Memory at fddfe000 (32-bit, non-prefetchable) [size=8K]

~$ lshw -C network
WARNING: you should run this program as super-user.
  *-network
       description: Wireless interface
       product: BCM4318 [AirForce One 54g] 802.11g Wireless LAN Controller
       vendor: Broadcom Corporation
       physical id: 9
       bus info: pci@0000:01:09.0
       logical name: eth1
       version: 02
       serial: ca:ff:ee:af:fe:01
       width: 32 bits
       clock: 33MHz
       capabilities: bus_master ethernet physical wireless
       configuration: broadcast=yes driver=bcm43xx driverversion=2.6.24-16-generic ip=192.168.2.102 latency=32 module=bcm43xx multicast=yes wireless=IEEE 802.11b/g

# blacklisted b43 abd b43legacy

# removed all additional firmware as extracted by b43-fwcutter during previous setup

# whitelisted bcm43xx

# added firmware as extracted by bcm43xx-fwcutter

~$ modprobe -r b43
~$ modprobe -r b43legacy
~$ lsmod | grep b43
[no output]

~$ modprobe bcm43xx
~$ lsmod | grep bcm
bcm43xx 141800 0
ieee80211softmac 34688 1 bcm43xx
ieee80211 38344 2 bcm43xx,ieee80211softmac

knetworkmanager now recognizes the card as eth1 and is able to associate with my AP (using WPA and everything).
Adding bcm43xx to /etc/modules does not resolve the issue during startup, I have to load the module by hand after the boot process in order to get it working. Seems to relate to the Asus hacks which Anmar talks about in [https://bugs.launchpad.net/ubuntu/+source/linux/+bug/182716/comments/80 Comment 80] and the possible workaround modprobe'ing b43 in between and the using bcm43xx to get the card working at all.

Interestingly, my wireless fails completely now. I think this might be since the last kernel upgraded (to 2.6.24-17). Knetwork manager recognises that the device exists, however it won't find any networks, regardless of what I do. As soon ad I modprobe either b43 OR bcm43xx, knetworkmanager recognises that there's a device:

$ uname -a
Linux naught101-laptop 2.6.24-17-generic #1 SMP Thu May 1 14:31:33 UTC 2008 i686 GNU/Linux

$ sudo modprobe -r bcm43xx
$ sudo modprobe -r b43
lsmod returns no instances of b43 or bcm43xx
knetworkmanager doesn't see any wireless device

$ sudo modprobe bcm43xx
$ lsmod | grep bcm43xx
bcm43xx 127720 0
ieee80211softmac 30976 1 bcm43xx
ieee80211 35528 2 bcm43xx,ieee80211softmac
Knetworkmanager finds device "Broadcom Corporation BCM4306 802.11b/g Wireless LAN Controller (wlan0)

$ sudo modprobe -r bcm43xx
naught101@naught101-laptop:~$ sudo modprobe b43
naught101@naught101-laptop:~$ lsmod|grep b43
b43 115104 0
ssb 32260 1 b43
led_class 6020 1 b43
input_polldev 5896 1 b43
mac80211 165652 2 b43,rtl8187
rfkill 8592 3 b43,rfkill_input
Knetworkmanager finds device "Unknown Unknown (wlan0)"

wmaster0 is only created with b43, and not bcm43xx, and it has no wireless extensions:
$ iwconfig
lo no wireless extensions.
eth0 no wireless extensions.
wmaster0 no wireless extensions.
wlan0 IEEE 802.11g ESSID:""
          Mode:Managed Frequency:2.412 GHz Access Point: Not-Associated
          Tx-Power=27 dBm
          Retry min limit:7 RTS thr:off Fragment thr=2346 B
          Link Quality:0 Signal level:0 Noise level:0
          Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0
          Tx excessive retries:0 Invalid misc:0 Missed beacon:0

I can't set the card to ad-hoc:
$ sudo iwconfig wlan0 mode Ad-Hoc
Error for wireless request "Set Mode" (8B06) :
    SET failed on device wlan0 ; Device or resource busy.

If I can provide any more useful information, let me know what it is an how to get it.

If this problem is due to the ASUS hack mentioned earlier, a fix for that has been submitted to the Ubuntu Kernel Team. I will be watching this bug for progress.

same thing happens to me and it doesn't seem related to ASUS. I've an HP zd8000 and `lspci -vvv` lists the wireless card as:

----------cut
0b:03.0 Network controller: Broadcom Corporation BCM4306 802.11b/g
Wireless LAN Controller (rev 03)
        Subsystem: Hewlett-Packard Company Presario R3000 802.11b/g
        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: 64
        Interrupt: pin A routed to IRQ 17
        Region 0: Memory at b0206000 (32-bit, non-prefetchable)
[size=8K]
----------cut

I also tried hardy with 2.6.25 and nothing changes. Should you need any info/test, let me know.

rgds,
k

I'll chime with another "me too." BCM4306 rev.03 doesn't work. Doesn't show networks in KNetworkManager, doesn't connect to manually configured AP. It's screwed up. Is anybody actively working on this bug? It makes Kubuntu-on-the-laptop much less usable... :-(

After my last report, I removed all packages associated with
broadcom4306 and then re-installed from source following the
instructions at http://www.linuxwireless.org/en/users/Drivers/b43
Since then my wireless has been working better than any time since I
installed hardy (beta4), not dropping out much at all. However, I'm
still only getting 1mb/s.

The driver is automatically choosing b43 and not b43-legacy.

$ lsmod|grep b43
b43 115104 0
rfkill 8592 3 rfkill_input,b43
mac80211 165652 1 b43
led_class 6020 1 b43
input_polldev 5896 1 b43
ssb 32260 1 b43

Any chance to get an update for Hardy, with a patched b43 driver?
I only experience this with WPA enterprise (eduroam)

This is a blocker for students in Europe and Australia, since they have Eduroam WIFI access on their universities...

Best regards!

You say that "I only experience this with WPA enterprise (eduroam)". Does this mean that it works with WEP and WPA-PSK?

Larry

Just echoing what everybody else says, b43 doesn't seem to work.

$ uname -a
Linux pippin 2.6.24-19-generic #1 SMP Wed Jun 18 14:43:41 UTC 2008 i686 GNU/Linux

version: Ubuntu 8.04 standard i386, up-to-date as of 7/6/2008
computer type: Dell D600 laptop, circa 2005

$lspci -vvv
<snip>
02:03.0 Network controller: Broadcom Corporation BCM4306 802.11b/g Wireless LAN Controller (rev 03)
 Subsystem: Dell Wireless 1350 WLAN Mini-PCI Card
 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: 32
 Interrupt: pin A routed to IRQ 5
 Region 0: Memory at fafee000 (32-bit, non-prefetchable) [size=8K]
<snip>

I get it to work by
$ sudo modprobe -r b43
$ sudo modprobe bcm43xx
Note: blacklisting b43 and whitelisting bcm43xx doesn't work for me, I need to start the driver once the system is up and running.

regards,
Ben

Despite what "everybody" says, b43 does work. What b43 does that bcm43xx does not do is look at the state of the radio-kill switch.

When you boot the system, what output is produced by the command

dmesg | grep b43

What sort of hardware does your Dell computer have to control the radio?

FYI, the driver that is loaded in response to the PCI ID of the BCM4306 is ssb. Based on the revision level of internal parts, ssb then loads b43 or b43legacy. If you want to blacklist anything, it should be ssb.

Because bcm43xx disappears from the kernel in the next release, it is worth some effort to get b43 working now, as bcm43xx will not be available when Ubuntu releases their next version.

You start out by saying that b43 does work, and end by saying that it needs to be fixed?
Thanks for the info, though. I guess it will be nice if the switch actually works, because my Dell computer does have a switch for the wi-fi.
I have b43 and ssb blacklisted, so the dmesg command gives me nothing. Maybe it's because I don't have a fresh boot?
I'm using Ndiswrapper right now and it's working great. I'd rather have b43 working, of course. I do have some computers (not Dell, no switches) that will only work with bcm43xx, as Ndiswrapper seemed to freeze them up.

Hi Larry,

As requested:

bwarren@pippin:~$ dmesg | grep b43
[ 89.647611] b43-phy0: Broadcom 4306 WLAN found
[ 89.695716] b43-phy0 debug: Found PHY: Analog 2, Type 2, Revision 2
[ 89.695773] b43-phy0 debug: Found Radio: Manuf 0x17F, Version 0x2050, Revision 2
[ 318.416438] input: b43-phy0 as /devices/virtual/input/input9
[ 319.717479] b43-phy0 debug: Loading firmware version 351.126 (2006-07-29 05:54:02)
[ 138.583575] b43-phy0 debug: !WARNING! Idle-TSSI phy->cur_idle_tssi measuring failed. (cur=37, tgt=62). Disabling TX power adjustment.
[ 138.583727] b43-phy0 debug: Chip initialized
[ 138.584244] b43-phy0 debug: 30-bit DMA initialized
[ 138.585106] Registered led device: b43-phy0:tx
[ 138.585155] Registered led device: b43-phy0:rx
[ 138.585206] Registered led device: b43-phy0:radio
[ 138.585308] b43-phy0 ERROR: PHY transmission error
[ 138.585489] b43-phy0 debug: Wireless interface started
[ 138.585503] b43-phy0 debug: Adding Interface type 2
[ 138.714058] b43-phy0 ERROR: PHY transmission error
[ 138.714278] b43-phy0 ERROR: PHY transmission error
[ 194.489854] b43-phy0 debug: Removing Interface type 2
[ 194.629854] b43-phy0 debug: Wireless interface stopped
[ 194.630197] b43-phy0 debug: DMA-32 0x0200 (RX) max used slots: 1/64
[ 194.630336] b43-phy0 debug: DMA-32 0x02A0 (TX) max used slots: 0/128
[ 194.648528] b43-phy0 debug: DMA-32 0x0280 (TX) max used slots: 0/128
[ 194.667202] b43-phy0 debug: DMA-32 0x0260 (TX) max used slots: 0/128
[ 194.685859] b43-phy0 debug: DMA-32 0x0240 (TX) max used slots: 0/128
[ 194.704545] b43-phy0 debug: DMA-32 0x0220 (TX) max used slots: 2/128
[ 194.723189] b43-phy0 debug: DMA-32 0x0200 (TX) max used slots: 0/128
-----------------

I'd never used it before, but apparently this laptop has a radio enable/disable bound to Fn+F2. Toggling this function and reloading b43 doesn't seem to make a difference (same dmesg), so I don't know if the key combination is being detected correctly.

Thanks for the background information. Of course I want to help to get b43 working rather than using a deprecated driver.

regards,
Ben

Hi Ben,

I've encountered the same problem with the radio hotkey not being recognised (although I use ndiswrapper not b43). I believe this occurs if the device is not active during boot, it appears as though X (which controls inputs such as this) does not realise the key should do anything unless the device tells it that it should (or some such). I believe you can send the same trigger to the kernel, however, by altering a file in /proc. Unfortunately I'm not sure what it is, as I've disabled the hotkey in my bios (which is your second option for getting around this). If you want to try the first option, try:
tree -f /proc | grep rfkill
It should be called rfkill, or rfkill_enable, if what I recall is correct. Then try using 'cat' to read the file (you'll probably have to do this as root), you'll get a binary value in return, 'echo' the opposite value into the file and see what happens.

The hotkey has a very complex handling and generally goes to the ACPI related to the BIOS - if that is not very well recognized in your Linux installation it will NOT work !

I have seen major differences with b43legacy from one revision of the card to another - 4306 rev3 works acceptable but 4306 rev1 is quite bad.

Also I have seen HUGE differences with the 'helper' programs with WEP/WPA - by FAR Ubuntu is the best, Mandriva subpar and OpenSUSE 11 the worst :(

The poor performance of the early BCM4306 units - the ones that use b43legacy - is known to us. Those models have the least work done by the firmware, and the most by the host cpu. The mistakes in the reverse engineering all add up and lead to the result you noted. By the time you get to BCM4306 rev3, then driver b43 is used and the performance is better.

In terms of the hotkey, the key needs to return the keycode 238 (KEY_WLAN) for press and release. I don't know enough about keyboard mapping to figure out how to check for the code emitted from your button, or how to set it up.

Same problem with 4311 rev 01 card. Workarounds (such as /usr/share/b43-fwcutter/install_bcm43xx_firmware.sh and modprobe bcm43xx and ndiswrapper with bcmlw5 driver) don't work. Also, Edimax 7318USg dongle cannot be made to work with rt73usb driver. Therefore, no usable wireless - what a pain!

Just wanted to confirm this once again.
bcm4306 rev 03
I did a fresh install, got all the latest updates, installed with Jockey... it's so sad, everything looks great until you try to connect, and you get that authentication timed out message in dmesg...

In a terminal, please enter the command '/sbin/lspci -nnv' and post the first two lines of the output for your BCM4306.

We have found a number of devices with the SPROM incorrectly coded. A fix has been entered into both the Hardy and Intrepid code base, but the above data will show if your card will be fixed.

Thanks for the quick reply... I assume you're replying to me, correct?
Do I have to be attempting to use the b43 driver/module for this code to show you what you want? And do I have to have lspci in /sbin, or just run as root?
Here's the output running "sudo lspci -nnv" on the machine while using the bcm43xx firmware. Is the "Unknown device" what you're after?

01:08.0 Network controller [0280]: Broadcom Corporation BCM4306 802.11b/g Wireless LAN Controller [14e4:4320] (rev 03)
 Subsystem: Linksys Unknown device [1737:0015]

Larry Finger wrote:
> In a terminal, please enter the command '/sbin/lspci -nnv' and post the
> first two lines of the output for your BCM4306.
>
>
02:03.0 Network controller [0280]: Broadcom Corporation BCM4306
802.11b/g Wireless LAN Controller [14e4:4320] (rev 03)
    Subsystem: Dell Wireless 1350 WLAN Mini-PCI Card [1028:0003]
    Flags: bus master, fast devsel, latency 32, IRQ 5
    Memory at fafee000 (32-bit, non-prefetchable) [size=8K]

> We have found a number of devices with the SPROM incorrectly coded. A
> fix has been entered into both the Hardy and Intrepid code base, but the
> above data will show if your card will be fixed.
>
>
fingers crossed,
Ben

For Nattgew:

The numbers you provided are definitive. The patch that was accepted today will fix your device. You can (1) wait for the fixes to propagate through the system, (2) you can patch your own kernel, or (3) we can rewrite your SPROM. Please let me know which you prefer. If the latter, follow the steps outlined below.

For Ben Warren:

Your device may have the same problem, but it is not one of the units that is fixed by the patch. For you, we will need to try the SPROM patch method. What I would like you to do enter the following commands in a terminal:

SPROM=$(find /sys/device -name ssb_sprom)
sudo cat $SPROM > sprom.dat

Next, post the file sprom.dat here.

Larry

Hi Larry,

Larry Finger wrote:
> <snip>
> For Ben Warren:
>
> Your device may have the same problem, but it is not one of the units
> that is fixed by the patch. For you, we will need to try the SPROM patch
> method. What I would like you to do enter the following commands in a
> terminal:
>
> SPROM=$(find /sys/device -name ssb_sprom)
> sudo cat $SPROM > sprom.dat
>
I didn't find that file, but how about this one:

bwarren@pippin:/sys/module/bcm43xx/drivers/pci:bcm43xx/0000:02:03.0$
sudo cat sprom
014000000300281020430080020002000010001800000000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF9000B096D54FFFFFFFFFFFFFFFFFFFFFFFFFFFFF44309A1193FBA5FEFFFFFFFF3C000000000000003E000D00FFFF00000000000000000185

regards,
Ben

Ben,

That is the one. My code assumed that you were running ssb and b43. You have bcm43xx loaded. The new version is

014000000300281020430080020002000010001800000000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF9000B096D54FFFFFFFFFFFFFFFFFFFFFFFFFFFFF44309A1193FBA5FEFFFFFFFF3C000000000000003E000C00FFFF000000000000000001B1

Try writing this one back to that location using the command

sudo cp new_data $SPROM

The essential difference has to do with Bluetooth coexistence. In the original, there was a string "0D00FFFF" that has been changed to "0C00FFFF" - that small difference should do the trick. Of course it isn't quite this simple as the file needs to have a proper CRC. The last two characters are the checksum that changed as well.

Just in case the new stuff gets garbled, I have attached the file as well.

Larry,
Thanks for the reply, that's wonderful news. Will the patch that's been applied rewrite my SPROM? Or, basically, if I rewrite the SPROM now, will the patch be compatible with it?
Heres my SPROM:
sudo cat /sys/module/bcm43xx/drivers/pci\:bcm43xx/0000\:00\:0d.0/sprom
014000001500371720430080020002000010001800000000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF0F0070667D27FFFFFFFFFFFFFFFFFFFFFFFFFFFF4516A01277FBACFEFFFFFFFF3C000000000000003E000D02FFFF0000000000000000018C

The patch does not rewrite the SPROM. What it does is dynamically set the board flags every time the driver starts. What we are doing is making the change permanent, which achieves the same effect. Yes, the patch will be compatible with the rewritten SPROM.

Your new SPROM contents should be

014000001500371720430080020002000010001800000000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF0F0070667D27FFFFFFFFFFFFFFFFFFFFFFFFFFFF4516A01277FBACFEFFFFFFFF3C000000000000003E000C02FFFF000000000000000001B8

I have also attached the file.

Larry

After a bit of trial and error, I ran this command

SPROM=$(find /sys/devices -name ssb_sprom)

and then

sudo cp nattgew_sprom_new $SPROM

and they completed without errors, and

cat $SPROM

seemed to show what you posted for the revised contents.
Wow, it connects with b43 now! Amazing! And it seems much better that bcm43xx so far. Does this do anything for the status of this bug?
Also, is this other bug related at all to what we are talking about here?
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/257020
I just noticed it in the changelog of the latest linux-libc-dev that update manager sees.

Larry, how about this card?
0b:00.0 Network controller [0280]: Broadcom Corporation BCM4312 802.11b/g [14e4:4315] (rev 01)
 Subsystem: Dell Wireless 1395 WLAN Mini-Card [1028:000b]
I'm running Ndiswrapper right now and I can't find any sprom anywhere in the /sys directory. I'll try it with b43 later if it will work.

The bug reported in 257020 _IS_ the bug here for the BCM4306 and most of the problems in this thread. You will find b43 to be much better than bcm43xx for a couple of reasons. First of all, the softmac used by bcm43xx never was any good - the mac80211, which is used by b43, is much better. Secondly, development on bcm43xx ceased about 18 months ago.

The sprom entry in the /sys tree is provided by ssb and will not be present when ndiswrapper is running.

Note: I am not aware of any BCM4312 cards with an SPROM coding error. Once the firmware is properly installed _AND_ the rfkill switch is properly set to allow the radio to come on, all of them just work.

I would be most interested in the output of 'dmesg | grep b43' for the BCM4312.

Larry

Okay, I'll try the 4312 with b43 when I get a chance and post the dmesg.
I did notice a problem with the cards I put the SPROM fix on, though. They seem to connect fine, but whenever something tries to access the network, it's denied.
I'm attaching part of the syslog from one of those connections. I notice some of the authentication timeouts. It seemed like both of the cards were getting the same IP address, could this be a problem with the network and not the driver? Notice the nptd message at the end when it tries to connect to the server.
After disconnecting and reconnecting, it seems fine again...

One thing I didn't make clear. The revised SPROM should have been applied to only one card. The reason is that the MAC address is also encoded in the SPROM. You now have two cards with the same MAC address - a no-no.

Please send me the MAC address for the second card if you can find it, and I'll encode that in a revised SPROM contents. If you cannot find it any other way, it should still be in the tables of your DHCP server.

Larry

Yes, that's what I thought was going on.
Here's the other card:
00:0F:66:74:0C:76
If I install that updated linux-libc-dev, will that apply the patch that will fix this?
Thanks.

The revised data for the 2nd card are

014000001500371720430080020002000010001800000000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF0F007466760CFFFFFFFFFFFFFFFFFFFFFFFFFFFF4516A01277FBACFEFFFFFFFF3C000000000000003E000C02FFFF000000000000000001BB

The file is attached.

I don't understand the question. My tentative answer is no, as only a kernel change can fix the original problem. If you are asking about the duplicate MAC problem, only this new SPROM contents will handle that.

Larry

Thanks for providing these rewrites for us, it's really nice to have this working again.
I guess I kind of misunderstood there... the package I was looking at was different, not the kernel package that will fix the bug.

That second card is working great now, connecting and staying connected well.
The first one is still being difficult, though. It seems to have the correct SPROM after restarting a few times, and sometimes it's able to connect, but it always drops, and sometimes it will not connect again for few retries.
I'm not sure if the issue is related to anything here, but I'll post the log where it drops its connection and then fails on trying to reconnect. After a break I pasted in the log of a successful connection (that takes way too long).
A couple relevant sections I think:
This is logged when it disconnects.
Aug 15 19:12:37 moab-desktop kernel: [ 3100.085180] wlan0: No ProbeResp from current AP 00:0f:66:57:f3:74 - assume out of range

This is logged while it's trying to reconnect.
Aug 15 19:12:49 moab-desktop kernel: [ 3111.742913] wlan0: Initial auth_alg=0
Aug 15 19:12:49 moab-desktop kernel: [ 3111.742926] wlan0: authenticate with AP 00:0f:66:57:f3:74
Aug 15 19:12:49 moab-desktop kernel: [ 3111.941417] wlan0: authenticate with AP 00:0f:66:57:f3:74
Aug 15 19:12:49 moab-desktop kernel: [ 3112.141164] wlan0: authenticate with AP 00:0f:66:57:f3:74
Aug 15 19:12:49 moab-desktop kernel: [ 3112.340895] wlan0: authentication with AP 00:0f:66:57:f3:74 timed out
Aug 15 19:12:50 moab-desktop kernel: [ 3113.081578] wlan0: authentication frame received from 00:0f:66:57:f3:74, but not in authenticate state - ignored
Aug 15 19:12:50 moab-desktop kernel: [ 3113.101573] wlan0: authentication frame received from 00:0f:66:57:f3:74, but not in authenticate state - ignored
Aug 15 19:12:50 moab-desktop kernel: [ 3113.109837] wlan0: authentication frame received from 00:0f:66:57:f3:74, but not in authenticate state - ignored
Aug 15 19:12:51 moab-desktop kernel: [ 3113.577759] wlan0: authentication frame received from 00:0f:66:57:f3:74, but not in authenticate state - ignored
Aug 15 19:12:57 moab-desktop NetworkManager: <info> wlan0: link timed out.

Is the signal weaker on the first card than the second. The logged data looks like what happens when the signal is marginal. Unfortunately, mac80211 is not really good at reconnecting when an interface loses the AP.

As long as it works at all, we have fixed the SPROM programming error. Sorry I cannot give you a fix for this problem.

Larry

No, I'm thinking it's the other way around. And I'm also thinking that it's finally connected correctly... I'm not sure what's going on. But that's good to know.
Yes, I think that's done well. Thanks.

So does this SPROM fix the original reporter's card?

I think it would, but in all the material that he posted in the initial message, the critical information (the subvendor and the subdevice codes) are not there.

Larry

> I think it would, but in all the material that he posted in the initial message, the critical information (the subvendor and the subdevice codes) are not there.

Err...

[quote from the bug report]

02:09.0 Network controller [0280]: Broadcom Corporation BCM4306 802.11b/g Wireless LAN Controller [14e4:4320] (rev 03)
        Subsystem: Linksys Unknown device [1737:0013]
        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: 32
        Interrupt: pin A routed to IRQ 19
        Region 0: Memory at fdffe000 (32-bit, non-prefetchable) [size=8K]

The concerned card is a Linksys WMP-54g

[/quote]

Same informations with a 2.6.26 kernel and b43/ssb (that does work now, I just have the PHY transmission error spam now) :

00:06.0 Network controller [0280]: Broadcom Corporation BCM4306 802.11b/g Wireless LAN Controller [14e4:4320] (rev 03)
        Subsystem: Linksys Device [1737:0013]
        Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
        Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
        Latency: 32
        Interrupt: pin A routed to IRQ 17
        Region 0: Memory at dfffe000 (32-bit, non-prefetchable) [size=8K]
        Kernel driver in use: b43-pci-bridge
        Kernel modules: ssb

cat /sys/devices/pci0000:00/0000:00:06.0/ssb_sprom
014000001300371720430080020002000010001800000000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF0F00F2664A8EFFFFFFFFFFFFFFFFFFFFFFFFFFFF4510A01277FBACFEFFFFFFFF3C000000000000003E000D00FFFF00000000000000000168

Sorry, I missed that part of your posting.

Yes, your interface has the SPROM coding problem. The fix for it was one of the first that made it into mainline.

If you want to modify your SPROM so that you can use the standard kernel, just write the following contents back into your machine:

014000001300371720430080020002000010001800000000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF0F00F2664A8EFFFFFFFFFFFFFFFFFFFFFFFFFFFF4510A01277FBACFEFFFFFFFF3C000000000000003E000C00FFFF0000000000000000015C

I have also attached the file.

Hi Larry,

On Tue, Aug 12, 2008 at 7:28 AM, Larry Finger <email address hidden> wrote:
> Ben,
>
> That is the one. My code assumed that you were running ssb and b43. You
> have bcm43xx loaded. The new version is
>
> 014000000300281020430080020002000010001800000000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF9000B096D54FFFFFFFFFFFFFFFFFFFFFFFFFFFFF44309A1193FBA5FEFFFFFFFF3C000000000000003E000C00FFFF000000000000000001B1
>
> Try writing this one back to that location using the command
>
> sudo cp new_data $SPROM
>
> The essential difference has to do with Bluetooth coexistence. In the
> original, there was a string "0D00FFFF" that has been changed to
> "0C00FFFF" - that small difference should do the trick. Of course it
> isn't quite this simple as the file needs to have a proper CRC. The last
> two characters are the checksum that changed as well.
>

The b43 driver seems to be working now, but only after I restart
NetworkManager. When ubuntu first boots, only the 'Wired Network'
part of the GUI is visible. If I kill NetworkManager and start it,
I'm connected to my AP. On the surface, this seems unrelated to the
problem with b43, but maybe not?

thanks,
Ben

I don't think that is a b43 problem. I don't use Gnome so I'm not sure what is available, but under KDE, the wireless connection has an "Autoconnect" button that needs to be checked when the connection is edited. When that is done, the system will look to the wireless before the wired interface.

Is your wire plugged in?

Larry

On Sat, Aug 16, 2008 at 2:29 PM, Larry Finger <email address hidden> wrote:
> I don't think that is a b43 problem. I don't use Gnome so I'm not sure
> what is available, but under KDE, the wireless connection has an
> "Autoconnect" button that needs to be checked when the connection is
> edited. When that is done, the system will look to the wireless before
> the wired interface.
>
> Is your wire plugged in?
>
> Larry
>

It used to autoconnect when I was using the bcm43xx driver, and once I
kill and start NetworkManager it autoconnects. No, I don't have
wireline connected.

regards,
Ben

Is bcm43xx blacklisted? Are ssb and b43 loaded on boot? You should see that in the dmesg output.

Larry

This is odd... I'm getting one card that works great, but the other card is still giving me the authentication timeouts. I've tried reinstalling and no go. Could be a hardware issue or conflict?

Is there any major difference in their locations, particularly relative to any interference? What channel are you using? What other channels are in use in your neighborhood? Try all the real usable channels, i.e. 1, 6, and 11.

Larry

Actually, they're in about the same spot. One is a floor below the AP and the other is a floor above. The one I'm having trouble with is below and actually indicates a higher signal strength, which is probably right.
I think the other APs around all use 6 or maybe 9, and I'm on 11. Furthermore, this one's in the basement, where you can't detect any AP except the one above it. Same with my 4312 laptop down here. The one upstairs should really be the one suffering from outside interference.
I just did a fresh install, no modifications. I installed b43-fwcutter from deb, cut the firmware for b43 and b43legacy (is that hardware dependent or can I swap those files between computers?) to /lib/firmware, copied in the modified sprom. I restarted and tried to connect with network manager. Still the authenticate timeouts. I tried manual settings and it did the same thing.

The firmware can be copied from computer to computer.

Once the modified SPROM is loaded, you don't ever need to do it again.

I would try channel 1 on your AP. Interference in the 2.4 GHz band doesn't always come from other wifi devices. Any number of household devices can interfere.

You can always check for hardware problems by swapping the cards.

Larry

Besides the MAC address, there are other parameters in the SPROM where Broadcom accounts for the specific amplifiers and radio of a device. When you wrote the SPROM for board A into board B, these were also overwritten. Fortunately, there are not many of these. The list includes the antenna gain, the pa0bx parameters, the max power out, and the idle TSSI target.

I am assuming that you do not have a copy of the original contents of the SPROM for board B. I have saved copies of all the boards that have been rewritten All of them have 0x3C for the maximum power out, and 0x3E for the idle TSSI target, thus I think we can rule out those parameters. I do see only two different sets of parameters for the pa0bx parameters as follows:

Board pa0b0 pa0b1 pa0b2

Your A 0x12A0 0xFB77 0xFEAC
Other 0x 119A 0xFB93 0xFEA5

The following SPROM content has the MAC of your board B and the other pa0bx values. Please try it.

014000001500371720430080020002000010001800000000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF0F0070667D27FFFFFFFFFFFFFFFFFFFFFFFFFFFF45169A1193FBA5FEFFFFFFFF3C000000000000003E000C02FFFF000000000000000001C9

My original contents were posted here, correct? That would be the only copy I have.
By board A I assume you mean the first SPROM I posted, and by board B I assume you mean the second?
Assuming that, board B is working great and board A is the one with issues.
That said, would you like me to try the SPROM you posted on B? I just want to make sure. I'll try it out when I get a chance.

No, don't use that one. It has the MAC address of the second board. If the second board is working fine, and the first SPROM that you sent came from the board that is giving the trouble, I have no idea what to do.

Larry

Hi Larry,

I've the same problem :

05:08.0 Network controller [0280]: Broadcom Corporation BCM4306 802.11b/g Wireless LAN Controller [14e4:4320] (rev 03)
        Subsystem: Linksys Unknown device [1737:0015]
        Flags: bus master, fast devsel, latency 32, IRQ 21
        Memory at d3000000 (32-bit, non-prefetchable) [size=8K]

My SPROM :
014000001500371720430080020002000010001800000000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF120065175B76FFFFFFFFFFFFFFFFFFFFFFFFFFFF4510A01277FBACFEFFFFFFFF3C000000000000003E000D02FFFF0000000000000000018D

Can you give me the new SPROM?

Thanks.

Christophe

Hi Larry and colleagues,

I wonder if we could have an update on this bug.
 - Has the problem been pinned down?
 - Is there a kernel patch accepted or in the pipeline?
 - Do we know yet in which kernel release the problem will be fixed and can we expect to see it in the repos any time soon?
 - For which cards will the problem be solved?
 - Is there a workaround for everyone who has this bug or does it need to be case-by-case?

Many thanks,
Z.

_________________________________________________________________
Find singles in your area with Match.
http://a.ninemsn.com.au/b.aspx?URL=http%3A%2F%2Fmatch%2Enz%2Emsn%2Ecom%2Fchannel%2Findex%2Easpx%3Ftrackingid%3D1043416&_r=WL_EMAL_TAG&_m=EXT

The problem is well known and is due to Broadcom's SPROM miscoding for most, if not all, PCI versions of the BCM4306 and at least one PCI version of the BCM4318. The difficulty is with Bluetooth coexistence, thus we cannot apply the "fix" to _ALL_ cards without testing a representative of each card group. The problem slipped through the bcm43xx team because none of us had the necessary hardware.

The patches for all _KNOWN_ devices with this problem have been accepted into the mainline kernel (2.6.27-rc4), sent to Ubuntu, and merged by them into the code base for both Hardy and Intrepid. I would expect the fix to be in the next kernel version. As I'm not affiliated with Ubuntu, I have no idea when that might be.

The specific cards that are addressed by the patches are as follows (the numbers in parentheses are the vendor, device, subvendor and subvendor codes that show up in the first two lines of the 'lspci -nnv' output for the wireless interface.):

ASUS WL-138G V2 (4314, 4318, 1043, 100F)
DELL DW1350 (4314, 4320, 1028, 0003)
LINKSYS (4314, 4320, 1737, 0013)
LINKSYS (4314, 4320, 1737, 0014)
LINKSYS (4314, 4320, 1737, 0015)

I have been treating the cases individually during the process of card identification, but there is a workaround. To use it, you need to obtain the SPROM utility from the bcm43xx tools at http://linuxwireless.org/en/users/Drivers/b43#relatedtools. To use this tool, you will need packages containing git, make, gcc, and glibc. The specific fix is to clear bit 1 of the low-order board flags. In most of the boards listed above, the current contents are 0x000D, which must be changed to 0x000C. When fixed, the kernel does this dynamically when starting, but a permanent change is equally effective. Caution must be taken to observe the current contents before changing them! If you blindly write 0x000C into the board flags, you may kill your card!

If you have a card with this problem _AND_ numbers different from the above list, I would like to know about it so that future kernels will be fixed.

I hope this answers your questions.

Larry

For Christophe Schneid,

The revised SPROM contents for your device is

014000001500371720430080020002000010001800000000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF120065175B76FFFFFFFFFFFFFFFFFFFFFFFFFFFF4510A01277FBACFEFFFFFFFF3C000000000000003E000C02FFFF000000000000000001B9

Larry

Larry,
It works!!!!
Thanks!
Christophe

Larry,

   I'm dying having to reboot into Windows!

00:0e.0 Network controller [0280]: Broadcom Corporation BCM4306 802.11b/g Wirele
ss LAN Controller [14e4:4320] (rev 03)
        Subsystem: Linksys Unknown device [1737:0015]
        Flags: bus master, fast devsel, latency 32, IRQ 16
        Memory at dd000000 (32-bit, non-prefetchable) [size=8K]

My SPROM:
014000001500371720430080020002000010001800000000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF0F00F366D697FFFFFFFFFFFFFFFFFFFFFFFFFFFF4516A01277FBACFEFFFFFFFF3C000000000000003E000D02FFFF00000000000000000156

Is there a shell script you could post that people could use to generate their own? I feel bad asking you to generate mine. :(

Thanks a million.

-Dave

It cannot be a shell script, but there is an SPROM manipulation program to do this. See the posting 2 or 3 above this one.

Your revised SPROM contents are

014000001500371720430080020002000010001800000000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF0F00F366D697FFFFFFFFFFFFFFFFFFFFFFFFFFFF4516A01277FBACFEFFFFFFFF3C000000000000003E000C02FFFF00000000000000000162

Larry

Larry,

I guess I've a somewhat different card, as I cannot find the 000D on the
SPROM, and the numbers in the card are also somewhat different to the ones
listed as "known affected cards" :

lspci:
0b:03.0 Network controller [0280]: Broadcom Corporation BCM4306 802.11b/g
Wireless LAN Controller [14e4:4320] (rev 03)
       Subsystem: Hewlett-Packard Company Broadcom 802.11b/g WLAN [103c:12fa]

SPROM:
01400000FA123C1020430080020002000010001800000000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF0000FFFFFFFFFFFFFFFFFFFFFFFFFFFF9000A44BFB5DFFFFFFFFFFFFFFFFFFFFFFFFFFFF3130AA14C8FA9FFEFFFFFFFF4C00FFFFFFFFFFFF3E00493A02FF454410FFFFFFFFFF021B

What should be the new SPROM to get the problem fixed?

thanks in advance,
k

To anyone reading this thread. I reemphasize that changing the SPROM is not as simple as using an editor on your data because these data must satisfy an 8-bit CRC.

For efolch:

Your new values are

01400000FA123C1020430080020002000010001800000000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF0000FFFFFFFFFFFFFFFFFFFFFFFFFFFF9000A44BFB5DFFFFFFFFFFFFFFFFFFFFFFFFFFFF3130AA14C8FA9FFEFFFFFFFF4C00FFFFFFFFFFFF3E00483A02FF454410FFFFFFFFFF022F

Please give me feedback on this card. Your set of values is a new one that will require a kernel patch.

Larry

Larry,

It's working now. I rewrote the SPROM, but that alone wasn't enough. I had to reinstall the driver as per http://linuxwireless.org/en/users/Drivers/b43#devicefirmware. Then reboot, and everything was ok.

I didn't go through any intensive testing (enable/disable the wireless via the laptop button, or ifconfig, enable/disable/use of bluetooth -I saw above in the thread that there was something related to bluetooth coexistence that affected this bug-).

I'm willing to help, so let me know if you want any particular set of tests/logs/info.

cheers,
k

The change we made in your SPROM disabled the Bluetooth coexistence function in your firmware. If you use Bluetooth, there will be interference in the 2.4 GHz band.

Because you had to rewrite the firmware files on the disk, I would like you to do the following:

1. Write the original SPROM contents back to the device and verify that the failure returns.

2. If is does not, let me know. If it does, try this SPROM contents

01400000FA123C1020430080020002000010001800000000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF0000FFFFFFFFFFFFFFFFFFFFFFFFFFFF9000A44BFB5DFFFFFFFFFFFFFFFFFFFFFFFFFFFF3130AA14C8FA9FFEFFFFFFFF4C00FFFFFFFFFFFF3E00497A02FF454410FFFFFFFFFF0213

3. If step number 2 also fails, we will have to live with the disabling of Bluetooth coexistence. Rewrite the first set of changed values to the SPROM.

None of these steps should require any change in the firmware.

Larry

Larry,

The behavior is pretty weird. I explain:

1) Wrote the old SPROM back while the card was connected. Everything still worked fine. Through knetworkmanager I disabled/enabled wireless and then it refused to connect again. *BUT* if I do a "ifconfig wlan0 down; ifconfig wlan0 up", then, it connects again.

2) Wrote the new SPROM while the card was connected, and everything was fine. Then exactly same behavior.

3) Wrote the first set back to SPROM and same as above.

I all cases connectivity remains when changing the SPROM until I disable/enable the wireless through KNetworkmanager, when it's lost. From here, in some cases I regain connectivity by disabling/enabling wireless through knetworkmanager, or by using ifconfig (not sure if there's any difference, but that's what happen).

Best thing, I can manage to have the wireless working playing with the interface up/down.
Worst thing, I cannot manage to have the wireless auto-"up and running" right after reboot (which is quite bad for my 4 years old daughter when trying to do onlime gaming :-))

Ideas?

k

I'm not sure of the meaning of the tests. The values in the SPROM are read only when the base driver ssb is loaded. Unless you reboot, or modprobe -r b43, changes are ignored. I think you need to do them again.

As to why it doesn't come up running, that is a matter for other of the Ubuntu mailing lists. Under both openSUSE 10.3 and 11.0, the wireless always starts unless there is a wired connection. It always gets priority.

Larry

I repeated the tests with unloading/reloading the driver via modbprobe, and same thing as before: when the wireless tries to attach to the correspodent SSID for the first time after the driver reload, it doesn't succeed (it stops in "stage 2 of 5 (Device Configure) complete" in the syslog.

If i try to force a reconnect to the same ssid or enable/disable the wireless via knetworkmanager, it always gets stuck at that stage 2 of 5.
But if I do that ifconfig down/up, then the next time I force a reconnect through knetworkmanager, it goes fine.

As for having the wireless running after reboot, I meant that it's actually up by default (as in openSUSE as you said), but it never goes after that "stage 2". I have to get it up manually. Not an Ubuntu issue (I guess). I think I'll end up scripting something with ifconfig/iwconfig.

k

Larry,
I finally installed the firmware (via b43-fwcutter) and tried b43 on my 4312 here. I got nothing. No entry in ifconfig or iwconfig, nothing about wireless in network manager, nothing that I could find in syslog or dmesg when I unloaded and then loaded or rebooted.

What is the output of 'dmesg | grep ssb', 'dmesg | grep b43', and 'lsmod | grep b43'? I also want to see the first two lines of output for your wireless device that come from the command '/sbin/lspci -nnv'.

Larry

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.

I think at least part of my issue with b43 could have been caused by overclocking. I brought the CPU back to its normal state, and the wireless seemed to connect better. Now the problem is that it wouldn't get an IP. It did at first, but then dropped it:
No ProbeResp from current AP 00:0f:66:57:f3:74 - assume out of range
And after that I don't think I was able to connect more than maybe once.
I took it closer to the AP and wired it up and updated to the latest -21 kernel in proposed. Now it's staying connected, but the signal is bouncing around anywhere between 88 and 112 out of 100 signal strength, and its claiming a rate of 1Mb/s.
I can force it to 54M
sudo iwconfig rate 54M
and then iwconfig shows that rate, but network manager still has 1 (and the Driver line is blank).
Also, the network seems a bit slow. I'm getting this on the other card, too.
I'm planning on testing with a fresh install and updating to -21 to see if that alone will get the card working, and how well. I'll also take this one back to where it was to see if it's related to signal strength.
Question: if I rewrite the SPROM as Larry helped me do, when the kernel fix is booted, does that override what I have done or does it just use it (assuming it's right)?

I have said this before, but I guess it bears repeating.

The revised SPROM changes the contents of something called the board_flags_lo permanently. The revised kernel changes it dynamically when the contents of the SPROM are loaded into memory. The net effect is _EXACTLY_ the same!!!!

I'm experiencing similar problems with the b43 driver. It will often connect when I load the b43 module (but not always) but soon afterward it will drop the connection. When the connection drops, dmesg reports the following:

[ 2138.271108] eth1: No ProbeResp from current AP 00:0d:72:ed:6d:f9 - assume out of range

When the connection drops, unloading and reloading the module often re-establishes the connection (again, not always). Note that when the connection is established, the wireless applet reports a strong connection (over 90%). I have attached the output of dmesg when a connection is established.

lspci -nnv:

01:07.0 Network controller [0280]: Broadcom Corporation BCM4306 802.11b/g Wireless LAN Controller [14e4:4320] (rev 03)
 Subsystem: Askey Computer Corp. Unknown device [144f:7077]
 Flags: bus master, fast devsel, latency 32, IRQ 20
 Memory at fdefe000 (32-bit, non-prefetchable) [size=8K]

find /sys/devices -name ssb_sprom | xargs sudo cat:

0140000077704F1420430080020002000010001800000000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF11000BF5D1BCFFFFFFFFFFFFFFFFFFFFFFFFFFFF4630D614D0FA79FEFFFFFFFF3C000000000000003E000802FFFF000000000000000001CB

ssb_sprom -i -P:

SPROM(0x04, Subsystem product ID) = 0x7077
SPROM(0x06, Subsystem vendor ID) = 0x144F
SPROM(0x08, PCI Product ID) = 0x4320
SPROM(0x38, High 16 bits of Boardflags) = 0xFFFF
SPROM(0x72, Low 16 bits of Boardflags) = 0x0208
SPROM(0x48, MAC address for 802.11b/g) = 00:11:f5:0b:bc:d1
SPROM(0x4E, MAC address for ethernet) = ff:ff:ff:ff:ff:ff
SPROM(0x54, MAC address for 802.11a) = ff:ff:ff:ff:ff:ff
SPROM(0x5A, Ethernet phy settings (0)) = 0x1F
SPROM(0x5A, Ethernet phy settings (1)) = 0x1F
SPROM(0x5B, et0mdcport) = ON
SPROM(0x5B, et1mdcport) = ON
SPROM(0x5C, Board revision) = 0x46
SPROM(0x5C, Locale / Country Code) = 0x0
SPROM(0x5C, B/G PHY antenna 0 available) = ON
SPROM(0x5C, B/G PHY antenna 1 available) = OFF
SPROM(0x5C, A PHY antenna 0 available) = ON
SPROM(0x5C, A PHY antenna 1 available) = ON
SPROM(0x74, B/G PHY antenna gain) = 0xFF
SPROM(0x74, A PHY antenna gain) = 0xFF
SPROM(0x5E, pa0b0) = 0x14D6
SPROM(0x60, pa0b1) = 0xFAD0
SPROM(0x62, pa0b2) = 0xFE79
SPROM(0x6A, pa1b0) = 0x0000
SPROM(0x6C, pa1b1) = 0x0000
SPROM(0x6E, pa1b2) = 0x0000
SPROM(0x64, LED 0 behaviour) = 0xFF
SPROM(0x65, LED 1 behaviour) = 0xFF
SPROM(0x66, LED 2 behaviour) = 0xFF
SPROM(0x67, LED 3 behaviour) = 0xFF
SPROM(0x68, B/G PHY max powerout) = 0x3C
SPROM(0x69, A PHY max powerout) = 0x00
SPROM(0x70, B/G PHY idle TSSI target) = 0x3E
SPROM(0x71, A PHY idle TSSI target) = 0x00
SPROM(0x7E, SPROM version) = 0x01

Any help would be much appreciated. I've tried switching to ndiswrapper, but then I get conflicts with ssb, so I'm stuck with unloading and reloading the b43 modules at the moment.

Dean.

Your SPROM contents are irrelevant. If you have the SPROM bug, then your device would _NEVER_ transmit, thus never connect. Obviously, that is not the case.

The performance of BCM4306 devices is the worst of all those driven by b43. I would like to review the reverse engineering, but development of code for versions not supported at all has priority.

Kernel versions later than 2.6.24 do have improvements. Perhaps you might try the linux-image-2.6.27-* package announced earlier in this thread.

Larry

Just registered to let interested parties know that this is in fact fixed in the newest Linux kernel code. I'm a Gentoo user, but have been having exactly this problem with my 4306 card on two different computers. I installed kernel 2.6.27-rc5-r1 from git sources and the problem is gone (no need to fiddle with my SPROM). Huzzah! Also, big thanks to Larry and everyone who helped pin this thing down - this bug report was incredibly helpful to me.

For those with 4311, 4312, 4321,and 4322 adapters, see this thread.
http://ubuntuforums.org/showthread.php?t=880218
It worked for my 4312 (except for Transmission bittorrent).

As per below you requested to know if Intrepid Alpha 5 fixed it. It did not. I have the same problem
(ndiswrapper won't connect to WPA but will connect to an open, unencrypted Wifi) but with rev 2 of bcm4306 hardware as I have documented in bug 276980 with exact steps to re-create on the live
CD. I have verified that it is broken in both Alpha 5 and Alpha 6. (I think I tried the Beta too, but
not certain.) The steps to re-create this bug on the Intrepid live CD also cause it to fail on the Hardy
live CD but not on the Gutsy live CD (with appropriate rmmod module change) so this has been
broken for a year.

Leann Ogasawara wrote on 2008-08-28: (permalink)

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:

...

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.

@Cliff - there is now another option in Intrepid for many Broadcom wireless BCM43xx cards. Unfortunately its not available until after you've performed an installation (as far as I know). Select System->Administration->Hardware Drivers, then activate the Broadcom wl driver.

@Cliff - What is your device? If it is listed in this thread, I missed it. Please post the first two lines of the output of 'lspci -nnv' that describe your BCM43xx device.

If yours if a BCM4306/3, it is possible that you have the SPROM programming error for a device we have not yet seen, or one of those that has not made it into 2.6.27.

Larry

Using 8.10 RC / Kernel: 2.6.27-7
and getting from lshw -C network
product: BCM4306 802.11b/g Wireless LAN Controller
version: 03

  Tim Gardner wrote on 2008-10-10: (permalink)
-> there was only the firmwarecutter thing; until 7.10 I got the wlan running; with 8.4 / 8.10 RC it doesen't

  Larry Finger wrote on 2008-10-10: (permalink)
-> hope, that answers your question

also tried using one of the PLENTY hints on how to with black-and-whitelisting, which didn't help.
now i might have to re-install the system to ensure getting it to the out-of-the-box state (meaning i am not the super-hacker)

Using 8.10 RC / Kernel: 2.6.27-7 Notebook: HP compaq nx9105
and getting from lshw -C network

product: BCM4306 802.11b/g Wireless LAN Controller
version: 03

  Tim Gardner wrote on 2008-10-10: (permalink)
-> there was only the firmwarecutter thing; until 7.10 I got the wlan running; with 8.4 / 8.10 RC it doesen't

  Larry Finger wrote on 2008-10-10: (permalink)
-> hope, that answers your question

also tried using one of the PLENTY hints on how to with black-and-whitelisting, which didn't help.
I might have to re-install the system to ensure getting it to the out-of-the-box state (meaning i am not the super-hacker)

My card correctly connects to the AP, but it is *really* slow (1 Mbps).
I started having speed issues since I updated from Feisty, that is since Ubuntu started using b43legacy on my card, instead of the old (but fast, for me) bcm43xx driver.
It's not clear to me if the fix proposed by Larry (hacking the SPROM) could also solve my speed problem.
My SPROM code also seems quite different from the others posted here so far, so I'm confused.
Thanks in advance!

These are some informations about my card:
02:03.0 Network controller [0280]: Broadcom Corporation BCM4306 802.11b/g Wireless LAN Controller [14e4:4320] (rev 02)
 Subsystem: Compaq Computer Corporation Device [0e11:00e7]
 Flags: bus master, fast devsel, latency 32, IRQ 21
 Memory at d2004000 (32-bit, non-prefetchable) [size=8K]
 Capabilities: <access denied>
 Kernel driver in use: b43-pci-bridge
 Kernel modules: ssb

My SPROM code is:
01400000E700110E2043008002000200F017001800000000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF90004A4B9899FFFFFFFFFFFFFFFFFFFFFFFFFFFF4536B01198FB4FFEFFFFFFFF3C00FFFFFFFFFFFF3E000F00FFFF0000000000000000017E

Output of "lsmod | grep b43":
b43legacy 128156 0
rfkill 17176 3 rfkill_input,b43legacy
mac80211 216820 1 b43legacy
led_class 12164 1 b43legacy
input_polldev 11912 1 b43legacy
ssb 40580 1 b43legacy

Output of "dmesg | grep ssb":
[ 3.732764] ssb: Sonics Silicon Backplane found on PCI device 0000:02:03.0

Output of "dmesg | grep b43":
[ 3.728892] b43-pci-bridge 0000:02:03.0: PCI INT A -> GSI 21 (level, low) -> IRQ 21
[ 16.775727] b43legacy-phy0: Broadcom 4306 WLAN found
[ 16.796035] b43legacy-phy0 debug: Found PHY: Analog 1, Type 2, Revision 1
[ 16.796058] b43legacy-phy0 debug: Found Radio: Manuf 0x17F, Version 0x2050, Revision 2
[ 16.820124] b43legacy-phy0 debug: Radio initialized
[ 22.557095] input: b43legacy-phy0 as /devices/virtual/input/input9
[ 22.868023] firmware: requesting b43legacy/ucode4.fw
[ 22.926075] firmware: requesting b43legacy/pcm4.fw
[ 22.930499] firmware: requesting b43legacy/b0g0initvals2.fw
[ 23.044033] b43legacy-phy0: Loading firmware version 0x127, patch level 14 (2005-04-18 02:36:27)
[ 23.108561] b43legacy-phy0 debug: Chip initialized
[ 23.108776] b43legacy-phy0 debug: 30-bit DMA initialized
[ 23.110741] Registered led device: b43legacy-phy0:radio
[ 23.110784] b43legacy-phy0 debug: Wireless interface started
[ 23.110789] b43legacy-phy0 debug: Adding Interface type 2
[ 2221.420054] b43legacy-phy0 debug: Removing Interface type 2
[ 2221.468043] b43legacy-phy0 debug: Wireless interface stopped
[ 2221.469467] b43legacy-phy0 debug: DMA-30 0x0260 (RX) max used slots: 1/64
[ 2221.469517] b43legacy-phy0 debug: DMA-30 0x0200 (RX) max used slots: 2/64
[ 2221.469563] b43legacy-phy0 debug: DMA-30 0x02A0 (TX) max used slots: 0/128
[ 2221.476042] b43legacy-phy0 debug: DMA-30 0x0280 (TX) max used slots: 0/128
[ 2221.484035] b43legacy-phy0 debug: DMA-30 0x0260 (TX) max used slots: 0/128
[ 2221.492028] b43legacy-phy0 debug: DMA-30 0x0240 (TX) max used slots: 0/128
[ 2221.500096] b4...

troubles here with 8.10 and b43. in 8.04 I had a very slow transmit speed (1mb) but was working, now only in some cases I cannot use the wireless. I tried an unprotected wifi and worked, wpa at home works, wep network NOT working.
I successfully connect, get IP, but after less than 10 seconds I get this error:

NetworkManager: <debug> [1226389722.062157] periodic_update(): Roamed from BSSID 00:40:F4:F1:78:56 (My1stAP) to (none) ((none))
kernel: [ 333.976064] wlan0: No ProbeResp from current AP 00:40:f4:f1:78:56 - assume out of range

then I need to... attach cable!

lspci:
00:09.0 Network controller [0280]: Broadcom Corporation BCM4318 [AirForce One 54g] 802.11g Wireless LAN Controller [14e4:4318] (rev 02)
 Subsystem: ASUSTeK Computer Inc. Device [1043:120f]

I'm seeing similar problems in 8.10. dmesg -nnv shows:

03:02.0 Network controller [0280]: Broadcom Corporation BCM4306 802.11b/g Wireless LAN Controller [14e4:4320] (rev 03)
        Subsystem: Hewlett-Packard Company Device [103c:12f8]
        Flags: bus master, fast devsel, latency 64, IRQ 21
        Memory at b0204000 (32-bit, non-prefetchable) [size=8K]
        Kernel driver in use: b43-pci-bridge
        Kernel modules: ssb

I'm attaching dmesg on a fresh boot.

The card was working fine prior to upgrading to 8.10 from 7.10. Since then, I have very rarely been able to see any networks with iwlist (worked once), and haven't been able to connect to any networks at all. I tried using the b43legacy module instead of b43, which prevented eth1 from even showing up. I tried using the SPROM fix provided by Larry, changing "SPROM(0x72, Low 16 bits of Boardflags) = 0x3A49" to "SPROM(0x72, Low 16 bits of Boardflags) = 0x3A48", to no avail.

Thanks,
 -Kyle

Correction on my last post, I meant "lspci -nnv", not "dmesg -nnv".

-KD

This bug was fixed in the package linux - 2.6.24-23.48

---------------
linux (2.6.24-23.48) hardy-security; urgency=low

  [Upstream Kernel Changes]

  * ATM: CVE-2008-5079: duplicate listen() on socket corrupts the vcc table
    - CVE-2008-5079
  * libertas: fix buffer overrun
    - CVE-2008-5134
  * Fix inotify watch removal/umount races
    - CVE-2008-5182
  * net: Fix soft lockups/OOM issues w/ unix garbage collector
    - CVE-2008-5300
  * Enforce a minimum SG_IO timeout
    - CVE-2008-5700
  * ib700wdt.c - fix buffer_underflow bug
    - CVE-2008-5702

linux (2.6.24-23.46) hardy-proposed; urgency=low

  [Alessio Igor Bogani]

  * rt: Updated PREEMPT_RT support to rt21
    - LP: #302138

  [Amit Kucheria]

  * SAUCE: Update lpia patches from moblin tree
    - LP: #291457

  [Andy Whitcroft]

  * SAUCE: replace gfs2_bitfit with upstream version to prevent oops
    - LP: #276641

  [Colin Ian King]

  * isdn: Do not validate ISDN net device address prior to interface-up
    - LP: #237306
  * hwmon: (coretemp) Add Penryn CPU to coretemp
    - LP: #235119
  * USB: add support for Motorola ROKR Z6 cellphone in mass storage mode
    - LP: #263217
  * md: fix an occasional deadlock in raid5
    - LP: #208551

  [Stefan Bader]

  * SAUCE: buildenv: Show CVE entries in printchanges
  * SAUCE: buildenv: Send git-ubuntu-log informational message to stderr
  * Xen: dma: avoid unnecessarily SWIOTLB bounce buffering
    - LP: #247148
  * Update openvz patchset to apply to latest stable tree.
    - LP: #301634
  * XEN: Fix FTBS with stable updates
    - LP: #301634

  [Steve Conklin]

  * Add HID quirk for dual USB gamepad
    - LP: #140608

  [Tim Gardner]

  * Enable CONFIG_AX25_DAMA_SLAVE=y
    - LP: #257684
  * SAUCE: Correctly blacklist Thinkpad r40e in ACPI
    - LP: #278794
  * SAUCE: ALPS touchpad for Dell Latitude E6500/E6400
    - LP: #270643

  [Upstream Kernel Changes]

  * Revert "[Bluetooth] Eliminate checks for impossible conditions in IRQ
    handler"
    - LP: #217659
  * KVM: VMX: Clear CR4.VMXE in hardware_disable
    - LP: #268981
  * iov_iter_advance() fix
    - LP: #231746
  * Fix off-by-one error in iov_iter_advance()
    - LP: #231746
  * USB: serial: ch341: New VID/PID for CH341 USB-serial
    - LP: #272485
  * x86: Fix 32-bit x86 MSI-X allocation leakage
    - LP: #273103
  * b43legacy: Fix failure in rate-adjustment mechanism
    - LP: #273143
  * x86: Reserve FIRST_DEVICE_VECTOR in used_vectors bitmap.
    - LP: #276334
  * openvz: merge missed fixes from vanilla 2.6.24 openvz branch
    - LP: #298059
  * openvz: some autofs related fixes
    - LP: #298059
  * openvz: fix ve stop deadlock after nfs connect
    - LP: #298059
  * openvz: fix netlink and rtnl inside container
    - LP: #298059
  * openvz: fix wrong size of ub0_percpu
    - LP: #298059
  * openvz: fix OOPS while stopping VE started before binfmt_misc.ko loaded
    - LP: #298059
  * x86-64: Fix "bytes left to copy" return value for copy_from_user()
  * NET: Fix race in dev_close(). (Bug 9750)
    - LP: #301608
  * IPV6: Fix IPsec datagram fragmentation
    - LP: #301608
  * IPV6: dst_entry leak in ip4ip6_err.
    - LP: #301608
  * IPV4: Remove IP_TOS setting priv...

The 18 month support period for Gutsy Gibbon 7.10 has reached its end of life -
http://www.ubuntu.com/news/ubuntu-7.10-eol . As a result, we are closing the
linux-source-2.6.22 kernel task.

I upgraded a couple of machines to Jaunty with this card, and they both worked after the b43 firmware package was installed.

in my case it was the otherwise correctly working fritzBox router to be restarted.
SADLY i just realized so after changing/swapping the wlan module in my notebook.

so the status (reffering to me) should be: fixed