# B43 + BCM4318 + WPA_Supplicant problem

## elbartoqwertyuiop

I installed the B43 driver for my BCM4318 card according to the guide on https://forums.gentoo.org/viewtopic-t-692917-highlight-b43.html and things seemed fine.  The Wi-Fi led was on and I was able to scan for wireless access points using WPA_Supplicant.

However, whenever I attempt to connect to ANY access point with wpa_gui, wlan0 timed out, as seen here:

```
wlan0: authenticate with AP 00:17:3f:68:bd:9e

wlan0: authenticate with AP 00:17:3f:68:bd:9e

wlan0: authenticate with AP 00:17:3f:68:bd:9e

wlan0: authentication with AP 00:17:3f:68:bd:9e timed out

wlan0: Initial auth_alg=0

wlan0: authenticate with AP 00:17:3f:68:bd:9e

wlan0: authenticate with AP 00:17:3f:68:bd:9e

wlan0: authenticate with AP 00:17:3f:68:bd:9e

wlan0: authentication with AP 00:17:3f:68:bd:9e timed out

wlan0: Initial auth_alg=0

wlan0: authenticate with AP 00:17:3f:68:bd:9e

wlan0: authenticate with AP 00:17:3f:68:bd:9e

wlan0: authenticate with AP 00:17:3f:68:bd:9e

wlan0: authentication with AP 00:17:3f:68:bd:9e timed out

```

Also, whenever I press Fn + F2 to shut down the Wi-Fi, the wireless LED stays on even though the computer tells me the card was turned off.  I assumed that I didn't compile the kernel correctly but the problem persisted even after following the the directions here: http://gentoo-wiki.com/Broadcom_43xx.

My current kernel is 2.6.24-gentoo-r8 but I assumed that would not be an issue since B43 and NetworkManager works perfectly on my Ubuntu installation with the 2.6.24-19-generic kernel.

I've read on other topics that Ndiswrapper or 2.6.25 kernels work better, but most of them are a few months old.

Any help is appreciated.

----------

## pappy_mcfae

The b43 module is slow, with a max data throughput of 1.5 megs. It also has issues with wpa_supplicant. Some lucky users get error messages, but workable wireless. Others get error messages, and not much else. While I admit that it has gotten more stable, as in won't die just because it wants to. It sometimes even reconnects without trouble.

But it doesn't hold a candle to ndiswrapper. Using ndiswrapper, I get steady state throughputs of 2.3 MB/s. Ndiswrapper never gives wpa_supplicant trouble. You can configure and tweak your adapter settings. By tweaking these settings, I have been able to peak at 2.9 MB/s.

The downside is that ndiswrapper is pretty unpopular with the kernel devs. The last family of kernels that supported it well was the .22 family. Up to 2.6.25-gentoo-r3, ndiswrapper support was ok. After that, it has started to suck once again.

So, if you can deal with an "older" kernel version, ndiswrapper is THE way to go, IMHO.

Blessed be!

Pappy

----------

## coolsnowmen

What firmware version are you currently using?

If you don't want to use ndiswrapper, try the latest b43 before giving up.  

I have a BCM4306 802.11b/g, latest kernel (26), and latest firmware (4.150.10.5.2)

wpa_supplicant 0.5.10, but admittedly, I almost never use the gui, I use the conf file for the 3 APs I ever connect to.

You should also know the ubuntu works hard to make the wireless experience better.  Problem is, a lot of that doesn't make it back up.

----------

## dennisn

More often than not, I also get those errors (with my BCM4318).

with linux kernel 2.6.26.3,

and "b43-phy0: Loading firmware version 410.2160 (2007-05-26)"

Other times it /is/ able to authenticate, then associate, and then immediately afterwards:

```
ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready

wlan0: No ProbeResp from current AP 00:11:95:be:b5:a9 - assume out of range
```

But then, immediately after this it authenticates and associates another TWO times (all three with the same AP). After this it somehow manages to reach the dhcpcd stage, at which point it times out while broadcasting for a lease. BUT, after this failed attempt, if I manually "dcpcd wlan0", it obtains a lease and the link works.

This triple repetition (which you also appear to get) seems suspicious. Why would it try to authenticate three times??

The fact that I can manually obtain a dhcp lease moments afterwards may suggest a timing issue.

On an unrelated note, I also get lots of "b43-phy0 ERROR: PHY transmission error" in my messages log during wlan0 activity. It doesn't seem to affect anything noticeably, but it may indicate a buggy kernel driver :\. Although, in general, b43 works great over here. (Except for this temporary initialization.) It usually seems to work better than my old ndiswrapper setup.

----------

## dennisn

Hacking..

```
failup() {

   [[ ${IFACE} == "wlan0" ]] && dhcpcd wlan0

}
```

..into my /etc/conf.d/net file seems to get the link up, even though the interface (net.wlan0) is officially "not started". For whatever reason, dhcpcd seems to work on this second attempt (after the initial attempt fails.)

----------

## dennisn

No--the above hack only works if it manages to associate to an AP--which it /still/ doesn't always do for me during bootup. Retrying to /etc/init.d/net.wlan0 start eventually (usually) works.  :Sad: .

----------

## dennisn

```
preup() {

   [[ ${IFACE} == "wlan0" ]] && iwconfig wlan0 essid off

   return 0

}
```

This (placed in /etc/conf.d/net) seems to work relatively well for me. Setting the essid to "off", which the iwconfig man page describes as "disabling ESSID checking", seems to help. Yes?

----------

## dennisn

No. That preup() doesn't help. It magically started working before, after several retries.

----------

## dennisn

rompenstein also has this card and problem over at https://forums.gentoo.org/viewtopic-p-5224785.html

In the meantime, I have hacked together a quick for-loop that keeps trying to restart net.wlan0. However, even at 30 iterations, sometimes it /still/ doesn't manage to start!

I have noticed, however, that a small break between restarts tends to increase the chances of authentication  :Razz: . It could be a timing or syncing or something error  :Wink: .

----------

## ZeuZ_NG

 *pappy_mcfae wrote:*   

> The b43 module is slow, with a max data throughput of 1.5 megs. It also has issues with wpa_supplicant. Some lucky users get error messages, but workable wireless. Others get error messages, and not much else. While I admit that it has gotten more stable, as in won't die just because it wants to. It sometimes even reconnects without trouble.
> 
> But it doesn't hold a candle to ndiswrapper. Using ndiswrapper, I get steady state throughputs of 2.3 MB/s. Ndiswrapper never gives wpa_supplicant trouble. You can configure and tweak your adapter settings. By tweaking these settings, I have been able to peak at 2.9 MB/s.
> 
> The downside is that ndiswrapper is pretty unpopular with the kernel devs. The last family of kernels that supported it well was the .22 family. Up to 2.6.25-gentoo-r3, ndiswrapper support was ok. After that, it has started to suck once again.
> ...

 

Well, I havent that problems nor had ever had them with my Broadcom that stacks with b43 (revision 02).

And ndiswrapper sucked hard when I tried it back with 2.6.17, so never even bothered to test it again.

The last similar thing I used is "project evil"(ndisgen +ndis) for trying to get it up and running on my laptop running fBSD, and no matter what firmware you might use, it breaks with 7.0-STABLE/RELEASE and such. Last compatible version with it is 5.X and it has been stuck since that moment afaik at least for freeBSD.

What do you get about your card with lspci ? what revision do you have? what firmware are you using? have you tried dealing the configuration files for wpa_supplicant with something like wicd or wifiradar? I don't think that the error would be the configuration files as it wouldn't associate at all to the Access Point in question, but yet, to clear out and test, nothing is lost.

Can you associate to a non-encrypted network? does it bring you the same problems? if so, we could discard the encryption layer to be failing, and go deeper into trying to determine what's failing with that hardware and your kernel, perhaps switching to an older kernel like 2.6.24 (gosh, I feel like I've repeated it tons of times, but that's what I had to do with my Pavilion dv2000 in order to make it work flawlessly.)

----------

## dennisn

I have a suspicion that the problem might not be (only) with the driver, but with one of the wrappers that call it to do the authentication/association.

For example, it seems to work successfully, every time, when I manually:

  iwconfig wlan0 essid MYESSID

  dhcpcd wlan0

The logs show only *one* authentication and association.

So, what could /etc/init.d/net.wlan0 be doing wrong?

----------

## ZeuZ_NG

 *dennisn wrote:*   

> I have a suspicion that the problem might not be (only) with the driver, but with one of the wrappers that call it to do the authentication/association.
> 
> For example, it seems to work successfully, every time, when I manually:
> 
>   iwconfig wlan0 essid MYESSID
> ...

 

Well, it's actually correct for it to be that way.

You could replace net.wlan0 with a script of your own that works well enough.

That would be a (perhaps dirty) solution.

----------

## dennisn

Passing "-K" to dhcpcd seems to have fixed it!

In /etc/conf.d/net, 

```
dhcpcd_wlan0="-t 10 -K"
```

 *Quote:*   

> 
> 
> -K, --nolink
> 
>              Don't receive link messages for carrier status.  You should only
> ...

 

Confirmation?

----------

## minor_prophets

for what its worth.  I tried the b43 driver in the 2.6.25 kernel and couldn't get it to work (all that well).  I may give it another shot, but for now.  I'm staying in the 2.6.24 range.

I use bcm43xx module and it works reasonably well.  I really don't see much over 24Mb/s.  Which is overall, not too bad.    :Rolling Eyes: 

If this helps.  This is what I'm working with.  Did you try the bcm43xx driver in a 2.6.24 kernel on fBSD7?  Interested to hear the answer.

```
0b:00.0 Network controller: Broadcom Corporation BCM94311MCG wlan mini-PCI (rev 01)

        Subsystem: Dell Device 0007

        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: 0, Cache Line Size: 64 bytes

        Interrupt: pin A routed to IRQ 16

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

        Capabilities: [40] Power Management version 2

                Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=375mA PME(D0-,D1-,D2-,D3hot-,D3cold-)

                Status: D0 PME-Enable- DSel=0 DScale=2 PME-

        Capabilities: [58] Message Signalled Interrupts: Mask- 64bit- Queue=0/0 Enable-

                Address: 00000000  Data: 0000

        Capabilities: [d0] Express (v1) Legacy Endpoint, MSI 00

                DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s <4us, L1 unlimited

                        ExtTag+ AttnBtn- AttnInd- PwrInd- RBE- FLReset-

                DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported-

                        RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop-

                        MaxPayload 128 bytes, MaxReadReq 128 bytes

                DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr- TransPend-

                LnkCap: Port #0, Speed 2.5GT/s, Width x1, ASPM L0s, Latency L0 <4us, L1 <64us

                        ClockPM- Suprise- LLActRep- BwNot-

                LnkCtl: ASPM L0s Enabled; RCB 64 bytes Disabled- Retrain- CommClk+

                        ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-

                LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-

        Capabilities: [100] Advanced Error Reporting <?>

        Capabilities: [13c] Virtual Channel <?>

        Kernel driver in use: bcm43xx

        Kernel modules: bcm43xx

```

dennisn, Broadcomm drop us the bomb

----------

## ZeuZ_NG

There aint possibilities to use directly a Linux driver on fBSD (appart from a project that aims to use webcams), and, fBSD has no support at all for Broadcom Wireless (this chipset in particular)

The one that HAS support for it is OpenBSD with BWI driver.

----------

## minor_prophets

ZueZ_NG,

Thanks for the info.  Looks like I'll have to stick with a pcmcia atheros chipset(older laptop) if I want to load fBSD on it and have wireless.

----------

## ZeuZ_NG

 *minor_prophets wrote:*   

> ZueZ_NG,
> 
> Thanks for the info.  Looks like I'll have to stick with a pcmcia atheros chipset(older laptop) if I want to load fBSD on it and have wireless.

 

As a matter of facts, if you're going to go for a *BSD, go for something Ralink based as madwifi and hal is not currently behaving well/stable enough in RELENG nor in HEAD

----------

## minor_prophets

Glad to know that a bid ahead of time.  Would the same hold true for Gentoo BSD??

 :Question: 

----------

## ZeuZ_NG

 *minor_prophets wrote:*   

> Glad to know that a bid ahead of time.  Would the same hold true for Gentoo BSD??
> 
> 

 

There is no difference from the freeBSD core vanilla to the one you can use in gentoo (appart from the patches)

Also, you might be intrested in trying 6.2 or one from the 5 series since they were the last to correctly support ndis ("project evil")

----------

