# bcm43xx, wpa_supplicant, udev... [SOLVED]

## ValenceParadigm

Well I finally got everything recompiled on the laptop - 20 days later.

Now some wireless would be nice....

The problem I'm having is primarily around the detection and configuration of the built-in Broadcom device.

The machine is a Canadian Compaq laptop (M2000) with the built-in PCI-E Broadcom 4306 (rev 03) (14e4:4320) and accompanying wired PCI network adapter (8139too).

This is where udev goes a little dense:   It can never make up it's mind which should be eth0 or eth1, thereby screwing things up for wpa_supplicant, beause the supplicant needs to be spoon-fed every piece of information:  Which interface, where's the driver, where's the config file....  Otherwise it just falls appart in a pile of errors.

After about 8 hours of poking around and trying everything on the net, I've discovered a few things:

Something really doesn't like having "net.ethX" in a runlevel.  Yet, somehow, the machine finds the config files all by itself.  Must be a new Gentoo thing since 2006.  Anyone?

You also cannot give information to wpa_supplicant from /etc/conf.d/net anymore.  IE: wpa_supplicant_eth0="-Dwext"  It doesn't like that.  It gacks up some 'SIOCSIFFLAGS' errors which are documented 'oh-so-well'.  

udev can't have a "70-persistent-net.rules" file or else it will hang for upwards of a minute on boot while it contemplates life on Uranus.  Not sure who keeps putting it there but it's an exercise in probability to guess when it's going to show up.  I know it's back when my machine sits there during boot at "Letting udev process events ..." 

All of these contradict what I've read here in the forums.  Could it be because I'm running udev .103?  I'd love to see Bug #147006 but I get nothing back from 'bugs.gentoo.org' just that the server stops responding.  Thank you domain filters!

I also found some mention somwhere of a bcm43xx_d* driver based on another driver tool that I can't for the life of me remeber - nor find.   What's the deal with that?  Native WPA sounds good to me..

-=VP=-

----------

## wizard69

Hi

have you read this thread

https://forums.gentoo.org/viewtopic-t-409194.html

I was having exactly the same problems with udev selecting a different device everytime i booted. My solution was to drop all references to your old device eth*  delete the init scripts and remove all reference in your WPA setup and /etc/conf.d/net. Then create a udev rule mine looks like this.

create this file  /etc/udev/rules.d/10-local.rules

```

KERNEL=="eth*", SYSFS{address}=="your mac address", NAME="wlan"

```

Type in you mac address and choose a name for you wlan device my device is called wlan. I had to reboot to make this rule work. This is my output of iwconfig. Create your new init scripts pointing to the new device configure wpa_supplicant and /etc/conf.d/net with your new device name. That should get you going and udev will not change you devices anymore. You only get 11 Mb/s with the kernel driver but that doesn't bother me hopefuly that will change in the near future.

```

iwconfig

lo        no wireless extensions.

lan       no wireless extensions.

wlan      IEEE 802.11b/g  ESSID:"linux"  Nickname:"Broadcom 4306"

          Mode:Managed  Frequency=2.462 GHz  Access Point: 00:0F:66:D3:05:A8

          Bit Rate=11 Mb/s   Tx-Power=15 dBm

          RTS thr:off   Fragment thr:off

          Encryption key:2814-A6C7-ECED-C579-535C-A894-90A4-C4F3   Security mode:open

          Link Quality=100/100  Signal level=3/3  Noise level=185/100

          Rx invalid nwid:0  Rx invalid crypt:236  Rx invalid frag:0

          Tx excessive retries:0  Invalid misc:0   Missed beacon:0

```

----------

## ValenceParadigm

 *wizard69 wrote:*   

> 
> 
> have you read this thread
> 
> https://forums.gentoo.org/viewtopic-t-409194.html
> ...

 

Yes -- and it was helpful.  However, it doesn't address the minute long hang.   I did, however, stumble accross that myself last night:

For me, BOTH devices have to be defined in the 70-persistent-net.rules file.  Otherwise, udev will still try to put them in the same spot and one will get deflected to eth0_re(config) or something like that.  That's what the minute-long hang was all about.     

 *wizard69 wrote:*   

> 
> 
> create this file  /etc/udev/rules.d/10-local.rules
> 
> ```
> ...

 

I'll have to try it that way.  For now I seem to have the module loading under controll.

The biggest issue I'm having at the moment is getting bcm43xx to load its firmware right.  I'm getting load errors in dmesg on the firmware at boot time.  When reloaded, the load errors go away.

The order of things is VERY important:

1.  You must load the bcm43xx module

2.  You must set adapter0 'up' with 

```
ifconfig ethX up
```

3.  Load wpa_supplicant or whatever.

Now one thing I've noticed, and am still working at, is that there seems to be a real problem between SoftMAC and wpa_supplicant.

In fact, I think wpa_supplicant 0.5.5 is broken outright because it won't work with ndiswrapper properly either.  I tried a kernel without bcm43xx compiled (because I can't turn module loading off with udev) to see if I could get things running with ndiswrapper.  Ndiswrapper worked fine, just wpa_supplicant couldn't function at all.  So I decided to go back to working on bcm43xx.

Here's a question:   Does anybody know if ieee80211_crypt_tkip replaces or is required to work with wpa_supplicant?  It would be nice to not have to deal with wpa_supllicant at all. 

-+VP=-

----------

## wizard69

I am using net-wireless/wpa_supplicant-0.5.5 and i don't have any problems with it. 

 *Quote:*   

> Here's a question: Does anybody know if ieee80211_crypt_tkip replaces or is required to work with wpa_supplicant? It would be nice to not have to deal with wpa_supllicant at all. 

 

I am not 100% sure but i think it's required if you want to use WPA tkip which i am using. If you need some more help or need a wpa_supplicant conf i can post it for you.

----------

## ValenceParadigm

 *wizard69 wrote:*   

> I am using net-wireless/wpa_supplicant-0.5.5 and i don't have any problems with it.

 

Then there's a very, very, good chance something is quite wrong with my setup.   Things were working great with 2005.1, but the forced upgrade just made meat of my system.

Incedentally, are you using a PPC or x86 laptop?  I've heard great things about bcm43xx from people with older 4306 chipsets, but from 431x up I've not seen results.

 *wizard69 wrote:*   

> 
> 
> I am not 100% sure but i think it's required if you want to use WPA tkip which i am using. If you need some more help or need a wpa_supplicant conf i can post it for you.

 

Actually, my conf file works - I've gotten pretty good at sculpting those.

What I realy could use is a list of kernel modules & inclusions that you require to have things like SoftMAC not try to authenticate over and over again.   

What's happening to me is I can get wpa_supplicant started, but as soon as I try to connect to my AP, I get to the handshake and something kills the connection.  A quick look in dmesg has a stream of the mesage over and over again:  "Already authenticated..."

The funny part is, the first three times when it worked flawlessly, SoftMAC never even showed up in dmesg.

-= VP =-

----------

## ValenceParadigm

Okay...  So most of the solution is quite simple:

The killer, most important, thing for anybody who's upgraded their udev past 096 (IE: You've updated from Gentoo 2005.1 image):

UDEV 096+ and hotplug are having a turf-war, and this brings us to the infamous BUG #147006

(https://bugs.gentoo.org/show_bug.cgi?id=147006)

In case you have trouble getting to bugs like I have, here's the important bit:

 *Quote:*   

> Since udev-096, it appears there's a conflict between hotplug and udev when
> 
> loading firmware.  If you have hotplug installed, udev screws up when loading
> 
> the firmware.  I can reliably reproduce this with bcm43xx.  Removing
> ...

 

The other thing is DO NOT USE "Debugging" in your ieee80211 selections:

```
[*] Networking support

     Networking options  --->

     <*>   Generic IEEE 802.11 Networking Stack

Say NO -->[ ]     Enable full debugging output

     <*>     IEEE 802.11 WEP encryption (802.1x)

     <*>     IEEE 802.11i CCMP support

     <*>     IEEE 802.11i TKIP encryption                                 

     <M>     Software MAC add-on to the IEEE 802.11 networking stack

Say NO -->[ ]       Enable full debugging output
```

When I did I could never get connected past the handshake and I'm pretty sure this was part of all of the 'SIOCSIFFLAGS' I was seeing in dmesg when running wpa_supplicant.

I have yet to make a successful automatic connection to a wpa-encrypted wireless network, but that's coming soon!

-=VP=-

----------

## ValenceParadigm

WOOT!   "WOOT!" I say!!

Everything is pretty much right as rain!

After a breif tiff with wpa_supplicant.conf putting "disabled=1" in all of my "network={...}"s I now have automatic wilreless network configuration a-la before the upgrade.

...Rapture!

The remaining things to consider and configure were;

1. The aforementioned wpa_suppliant.conf oddity - undoubtedly a throw-off from some other disaster earlier.

2. Making sure /etc/conf.d/net was appropreately configured with:

```
modules=( "wpa_supplicant" )

wpa_supplicant_'interface*'="-Dwext"

config_'interface*'=( "dhcp" )
```

3.  Making sure "/etc/init.d/net.'interface*' -> /etc/init.d/net.lo" exists, but is not named in any runlevels.

It was THAT simple!

-=VP=-

----------

