I have a Broadcom 4312 on the usb bus of a HP Compaq 6715S laptop, and I'm trying to have it recognized regularly.

It is always present on the usb bus (lsusb always reports it). The kernel either wakes it up or it doesn't, and _if_it_does_, it can be seen on the pci bus with lspci. Apparently it needs the functionality of B43_PCI_BRIDGE, and that is sporadic. That's not a visible kernel option but is switched on by something in Sonics Silicon Backplane (SSB)

It is always recognized by (Spit!) Vista, and if I reboot to Fedora, network manager picks it up. I also have slamd64, and I'm trying to make things happen without a boot into (Spit!) vista

How can I switch the beast on from startup reliably? Is there kernel options, boot parameters, anything? Here's my B43 keernel options (I upgraded to 2.6.29.1)

CONFIG_B43=m
CONFIG_B43_PCI_AUTOSELECT=y
CONFIG_B43_PCICORE_AUTOSELECT=y
# CONFIG_B43_PCMCIA is not set
CONFIG_B43_LEDS=y
CONFIG_B43_RFKILL=y
CONFIG_B43_DEBUG=y
# CONFIG_B43_FORCE_PIO is not set
CONFIG_B43LEGACY=m
CONFIG_B43LEGACY_PCI_AUTOSELECT=y
CONFIG_B43LEGACY_PCICORE_AUTOSELECT=y
CONFIG_B43LEGACY_LEDS=y
CONFIG_B43LEGACY_RFKILL=y
# CONFIG_B43LEGACY_DEBUG is not set
CONFIG_B43LEGACY_DMA=y
CONFIG_B43LEGACY_PIO=y
CONFIG_B43LEGACY_DMA_AND_PIO_MODE=y
# CONFIG_B43LEGACY_DMA_MODE is not set
# CONFIG_B43LEGACY_PIO_MODE is not set
CONFIG_SSB_B43_PCI_BRIDGE=y

Since you've got a 4312, you might have better luck with the Broadcom Linux driver. I've never used it on a USB device, but on a PCI device, it does work better/more consistently than b43.

Thanks for reminding me, hangdog42. I picked that up at the beginning but for some stupid reason I got silly errors on the compile. Specifically this line
5. Build the LKM, i.e. wl.ko: make -C /lib/modules/<2.6.xx.xx>/build M=`pwd`

I tried it just now and went down in flames for the lack of bounds.h in the 2.6.29.1 kernel source. No bother, I thought, and symlinked in one from /usr/include (from 2.6.27.7 kernel, or earlier if slamd used earlier kernel headers). To say it doesn't compile is to put it mildly, and this despite a make headers_install and make headers_check being issued in the kernel source. I take it they have changed the headers and the 64 bit source is no longer valid.

I'll try to email broadcom :-(.

Hm. I haven't moved to 2.6.29 yet, but I have seen it cause problems elsewhere (mostly with ATI and Nvidia drivers). This is the first problem I've seen with a wireless driver.

I guess that leaves b43. Just to be sure it isn't something silly, you might want to double check that the firmware got installed and you might have a look in the log files when you plug in the USB device and see if there are any specific complaints.

The firmware did get installed (after a battle with the instructions). This works - half the time, which is a real PITA. Here's what I found

Slamd64-12.2 dmesg:
usb 2-2: New USB device found, idVendor=03f0, idProduct=171d
usb 2-2: New USB device strings: Mfr=1, Product=2, SerialNumber=0
usb 2-2: Product: HP Integrated Module
usb 2-2: Manufacturer: Broadcom Corp
usb 2-2: configuration #1 chosen from 1 choice
Bluetooth: Core ver 2.14
NET: Registered protocol family 31
Bluetooth: HCI device and connection manager initialized
Bluetooth: HCI socket layer initialized
Bluetooth: Generic Bluetooth USB driver ver 0.4
usbcore: registered new interface driver btusb

It had picked up the btusb driver for the bcm 2033 or somesuch :-/. I see a little hackery in modprobe.d coming on to sort that. Here's a log entry from Fedora 9 where apparently we struck lucky


Apr 10 22:22:11 harriet kernel: b43-phy0: Broadcom 4311 WLAN found
Apr 10 22:22:11 harriet kernel: Driver 'sr' needs updating - please use bus_type methods
Apr 10 22:22:11 harriet kernel: sr0: scsi3-mmc drive: 24x/24x writer dvd-ram cd/rw xa/form2 cdda tray
Apr 10 22:22:11 harriet kernel: Uniform CD-ROM driver Revision: 3.20
Apr 10 22:22:11 harriet kernel: Broadcom 43xx driver loaded [ Features: PMLR, Firmware-ID: FW13 ]


And Later in the same boot. . .
Apr 10 22:22:11 harriet kernel: input: b43-phy0 as /devices/virtual/input/input8
Apr 10 22:22:11 harriet kernel: firmware: requesting b43/ucode13.fw
Apr 10 22:22:11 harriet kernel: firmware: requesting b43/b0g0initvals13.fw
Apr 10 22:22:11 harriet kernel: b43-phy0: Loading firmware version 351.126 (2006-07-29 05:54:02)
Apr 10 22:22:11 harriet kernel: b43-phy0 warning: You are using an old firmware image. Support for old firmware will be removed in July 2008.
Apr 10 22:22:11 harriet kernel: b43-phy0 warning: You must go to http://linuxwireless.org/en/users/Dr...devicefirmware and download the latest firmware (version 4).
Apr 10 22:22:11 harriet kernel: Registered led device: b43-phy0::tx
Apr 10 22:22:11 harriet kernel: Registered led device: b43-phy0::rx
Apr 10 22:22:11 harriet kernel: Registered led device: b43-phy0::radio
Apr 10 22:22:11 harriet kernel: ADDRCONF(NETDEV_UP): wlan0: link is not ready
Apr 10 22:22:11 harriet kernel: Clocksource tsc unstable (delta = -67216290 ns)
Apr 10 22:22:11 harriet kernel: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
Apr 10 22:22:11 harriet kernel: ADDRCONF(NETDEV_UP): eth0: link is not ready

And still Later
Apr 10 22:22:13 harriet kernel: warning: `dbus-daemon' uses deprecated v2 capabilities in a way that may be insecure.
Apr 10 22:22:13 harriet kernel: fuse init (API version 7.9)
Apr 10 22:22:13 harriet pcscd: pcscdaemon.c:507:main() pcsc-lite 1.4.4 daemon ready.
Apr 10 22:22:14 harriet acpid: starting up
Apr 10 22:22:16 harriet acpid: client connected from 2436[68:68]
Apr 10 22:22:18 harriet ntpd[2511]: ntpd 4.2.4p4@1.1520-o Mon Apr 7 17:32:53 UTC 2008 (1)
Apr 10 22:22:18 harriet ntpd[2512]: precision = 1.000 usec
Apr 10 22:22:18 harriet ntpd[2512]: Listening on interface #0 wildcard, 0.0.0.0#123 Disabled
Apr 10 22:22:18 harriet ntpd[2512]: Listening on interface #1 wildcard, ::#123 Disabled
Apr 10 22:22:18 harriet ntpd[2512]: Listening on interface #2 lo, ::1#123 Enabled
Apr 10 22:22:18 harriet ntpd[2512]: Listening on interface #3 wlan0, fe80::221:ff:fe62:c317#123 Enabled
Apr 10 22:22:18 harriet ntpd[2512]: Listening on interface #4 lo, 127.0.0.1#123 Enabled
Apr 10 22:22:18 harriet ntpd[2512]: Listening on interface #5 wlan0, 192.168.1.102#123 Enabled


Allow me to note in passing that Selinux does nag a lot, and The kernel likewise. I have spared you as much of that as I can. Hal seems to love creating imaginary directories

So, to summarise - I need to

1. Blacklist btusb
2. Insert 'alias wlan0 b43' somewhere it will be read
3. Grab the latest firmware from where the log is nagging me to, and install it.

Anything else?


b43_pci_bridge is one of those drivers that's too small to be a module, so they just throw it into the SSB backplane. You cannot select it in the kernel unless you have a very specific configuration; Everything else selects it for you and hides it from your eyes :-/.

That looks like a good start. I wonder why slamd is deciding it is a bluetooth device? That seems a bit on the odd side. I suspect that btusb and b43 are fighting over the card, so blacklisting btusb is probably a good thing to try. After booting, you might have a look at lsmod and make sure that both b43 and ssb are loading.

btusb is now blacklisted. It no longer loads.
ssb is loading no problem. I have 'alias wlan0 b43' in /etc/modprobe.d/wlan0 but despite that b43 is not loading, despite a 'sbin/modprobe wlan0' being executed. I feel an email to a maintainer might be in order.

AFAICT, the problem is: The kernel config in Sonics Silicon Backplane seems to be sadly lacking in 2.6.29.1. B43_PCI_BRIDGE=y is selected somehow in SSB automagically - I never see it as an option. I had better success with an earlier kernel where I could select that as a module. Nobody seems to think that a 4312 would ever go on the usb bus - they want to have it on pci, or mebbe pcmcia. This box has it on usb. The only way to talk to it reliably is to call b43_pci_bridge as the driver Which autoselects b43, of course. With b43_pci_bridge inbuilt, how do you wake up the functionality? I should file a bug. Where do I do that these days. I know it's a Royal PITA, but the kernel should be grabbing this.

Fedora happens this way: The kernel misses it, but NetwortManager finds it and starts it up somehow if I come in from (spit!) vista. but If I come in from slamd, it's very iffy.

Further, when b43 loads, it finds the thing, but does nothing with it. It isn't initialised. I did try a kernel build with b43_pci_bridge=m which I got by hacking the config, but that didn't help.

I'd love any ideas. I dread joining the lmkl and having to weed through those guys sounding off in gobbledygook at length in my inbox. I'd sooner use a bugzilla if there is one.

I hope that is a typo. I don't think that modprobe is going to associate wlan0 with b43. If it isn't a typo, try modprobe b43.

The official site is here, and on the developers tag there is a link to the mailing list. That might be an appropriate place to start.

I suspect you're right about USB screwing things up. It does for other chipsets, so I don't know why the 4312 should be any different. I can say I'm out of my depth here, so the mailing list may be your best bet.

modprobe wlan0 was a typo, but if the line

alias wlan0 b43

is available in modprobe.d, it works.

We are doing better today. I have filed bug #13200, and await abuse from kernel guys. I have Fedora online with WiFi (today, the kernel is finding wlan0). This is actually about recycling a room in the house here. Slamd64 is doing strange things. Take this chunk from /etc/rc.d/rc.inet1

# This is a bit hackish, but should do the job right...
echo "Nickname" $NICKNAME
if [ ! -n "$NICKNAME" ] ; then
NICKNAME=`/bin/hostname`
fi

echo "Nickname" $NICKNAME
if [ -n "$ESSID" -o -n "$MODE" ] ; then
echo "$0: $IWCOMMAND nick $NICKNAME" | $LOGGER
$IWCOMMAND nick $NICKNAME
echo "Nickname" $NICKNAME
fi

The echo commends are mine. The log showsApr 29 11:36:33 harriet kernel:

/Start syslog chunk
input: b43-phy0 as /devices/virtual/input/input6
Apr 29 11:36:33 harriet kernel: b43 ssb0:0: firmware: requesting b43/ucode13.fw
Apr 29 11:36:33 harriet kernel: b43 ssb0:0: firmware: requesting b43/b0g0initvals13.fw
Apr 29 11:36:33 harriet kernel: b43-phy0: Loading firmware version 351.126 (2006-07-29 05:54:02)
Apr 29 11:36:33 harriet kernel: Registered led device: b43-phy0::tx
Apr 29 11:36:33 harriet kernel: Registered led device: b43-phy0::rx
Apr 29 11:36:33 harriet kernel: Registered led device: b43-phy0::radio
Apr 29 11:36:33 harriet kernel: b43-phy0: Radio turned on by software
Apr 29 11:36:36 harriet logger: /etc/rc.d/rc.M: /sbin/iwconfig wlan0 mode Managed
Apr 29 11:36:37 harriet kernel: input: b43-phy0 as /devices/virtual/input/input7
Apr 29 11:36:37 harriet kernel: b43-phy0: Loading firmware version 351.126 (2006-07-29 05:54:02)
Apr 29 11:36:37 harriet kernel: Registered led device: b43-phy0::tx
Apr 29 11:36:37 harriet kernel: Registered led device: b43-phy0::rx
Apr 29 11:36:37 harriet kernel: Registered led device: b43-phy0::radio
Apr 29 11:36:40 harriet logger: /etc/rc.d/rc.M: /sbin/iwconfig wlan0 nick harriet
Apr 29 11:36:40 harriet logger: /etc/rc.d/rc.M: /sbin/iwconfig wlan0 key ************
Apr 29 11:36:40 harriet logger: /etc/rc.d/rc.M: /sbin/iwconfig wlan0 key restricted
Apr 29 11:36:40 harriet logger: /etc/rc.d/rc.M: /sbin/iwconfig wlan0 power saving
Apr 29 11:36:40 harriet logger: /etc/rc.d/rc.M: /sbin/iwconfig wlan0 essid "dlink-dec"
Apr 29 11:36:40 harriet logger: /etc/rc.d/rc.M: /sbin/iwconfig wlan0 essid "dlink-dec"
Apr 29 11:36:40 harriet logger: /etc/rc.d/rc.inet1: /sbin/dhcpcd -d -t 30 -h harriet -R -N wlan0
Apr 29 11:36:40 harriet dhcpcd[2907]: MAC address = 00:21:00:62:c3:17

/End syslog chunk

But onscreen I get errors about "Set Nickname 8B1C" and Set Power Management "8B2C". These are not coming from the /etc directory or from the init scripts. Fedora throws the 8B2C error as well.

One thing I did was to set /etc/modprobe.d/wlan0 to read
install wlan0 modprobe b43; modprobe btusb; modprobe broadcom

We struggle on. Thanks Hangdog42

This is probably just a random brain discharge, but have you tried booting in single user mode to see if these errors are still cropping up? If they don't, that might give a clue where they are coming from. From the syslog bit you posted, things actually look good (other than the ssid being set twice).

Ithink it's a hardware thing, these funny numbers. Both OSes have these strange errors like brain farts coming up in them any time I approach this with iwconfig.

[declan@harriet ~]$ iwconfig wlan0 essid
Error for wireless request "Set ESSID" (8B1A) :
too few arguments.
[declan@harriet ~]$ iwconfig wlan0 key
Error for wireless request "Set Encode" (8B2A) :
too few arguments.
[declan@harriet ~]$ iwconfig wlan0 mode
Error for wireless request "Set Mode" (8B06) :
too few arguments.
[declan@harriet ~]$ iwconfig wlan0 channel
Error for wireless request "Set Frequency" (8B04) :
too few arguments.
[declan@harriet ~]$ iwconfig wlan0 nwid
Error for wireless request "Set NWID" (8B02) :
too few arguments.
[declan@harriet ~]$ iwconfig wlan0 txpower
Error for wireless request "Set Tx Power" (8B26) :

is this kosher? The 'too few arguments' was on purpose as I am online.(I'm a noob at wireless stuff). That's modules falling over each other perhaps?

Current status is:

Slamd64 is not getting online. It seems to find the card, and I did spend hours debugging that script section (adding echo commends). The init scripts are a mess, to put it at it's mildest. /etc/rc.d/rc.inet1 sets up wlan0 and then calls /etc/rc.d/rc.wireless which unsets and repeats that process and reads rc.wireless.conf into the record as well :-/. I get everything right, except is is like the monkeys - It hears nothing, it transmits nothing, and


Fedora: is finding wlan0, cannot automagically connect despite carefully configured init scripts. Network Manager in gnome gets on line with this addition to dmesg. (This is association 1, followed by disassociation 1 when I dropped out of X and finally association 2) I should mention I have tried nsuccessfully to connect with cli in Fedora as well (init runlevel three).

lo: Disabled Privacy Extensions
input: b43-phy0 as /class/input/input7
b43 ssb0:0: firmware: requesting b43/ucode13.fw
b43 ssb0:0: firmware: requesting b43/b0g0initvals13.fw
b43-phy0: Loading firmware version 351.126 (2006-07-29 05:54:02)
b43-phy0 warning: You are using an old firmware image. Support for old firmware will be removed in July 2008.
b43-phy0 warning: You must go to http://linuxwireless.org/en/users/Dr...devicefirmware and download the latest firmware (version 4).
b43-phy0 debug: Chip initialized
b43-phy0 debug: 64-bit DMA initialized
Registered led device: b43-phy0::tx
Registered led device: b43-phy0::rx
Registered led device: b43-phy0::radio
b43-phy0 debug: Wireless interface started
b43-phy0 debug: Adding Interface type 2
b43-phy0: Radio turned on by software
ADDRCONF(NETDEV_UP): wlan0: link is not ready
b43-phy0 debug: Using hardware based encryption for keyidx: 0, mac: ff:ff:ff:ff:ff:ff
type=1400 audit(1241011446.918:3): avc: denied { sys_tty_config } for pid=1770 comm="consoletype" capability=26 scontext=system_u:system_r:consoletype_t:s0 tcontext=system_u:system_r:consoletype_t:s0 tclass=capability
type=1400 audit(1241011446.984:4): avc: denied { getattr } for pid=1774 comm="grep" path="/etc/sysconfig/network-scripts/ifcfg-WiFi~" dev=sda6 ino=108430 scontext=system_u:system_r:dhcpc_t:s0 tcontext=system_ubject_r:file_t:s0 tclass=file
type=1400 audit(1241011446.984:5): avc: denied { read } for pid=1774 comm="grep" name="ifcfg-WiFi~" dev=sda6 ino=108430 scontext=system_u:system_r:dhcpc_t:s0 tcontext=system_ubject_r:file_t:s0 tclass=file
wlan0: authenticate with AP 00:0f:cc:ad:9b:38
wlan0: authenticated
wlan0: associate with AP 00:0f:cc:ad:9b:38
wlan0: RX AssocResp from 00:0f:cc:ad:9b:38 (capab=0x451 status=0 aid=1)
wlan0: associated
b43-phy0 debug: RX: Packet dropped
ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
b43-phy0 debug: RX: Packet dropped

[SNIP OF ABOUT 300 REPEATS OF ABOVE LINE]

b43-phy0 debug: RX: Packet dropped
b43-phy0 debug: RX: Packet dropped
b43-phy0 debug: RX: Packet dropped
b43-phy0 debug: RX: Packet dropped
wlan0: no IPv6 routers present
b43-phy0 debug: RX: Packet dropped
wlan0: deauthenticating by local choice (reason=3)
b43-phy0 debug: Disabling hardware based encryption for keyidx: 0, mac: ff:ff:ff:ff:ff:ff
b43-phy0 debug: Removing Interface type 2
b43-phy0 debug: Wireless interface stopped
b43-phy0 debug: DMA-64 rx_ring: Used slots 1/64, Failed frames 0/0 = 0.0%, Average tries 0.00
b43-phy0 debug: DMA-64 tx_ring_AC_BK: Used slots 0/128, Failed frames 0/0 = 0.0%, Average tries 0.00
b43-phy0 debug: DMA-64 tx_ring_AC_BE: Used slots 2/128, Failed frames 0/18 = 0.0%, Average tries 1.00
b43-phy0 debug: DMA-64 tx_ring_AC_VI: Used slots 0/128, Failed frames 0/0 = 0.0%, Average tries 0.00
b43-phy0 debug: DMA-64 tx_ring_AC_VO: Used slots 2/128, Failed frames 0/14 = 0.0%, Average tries 1.00
b43-phy0 debug: DMA-64 tx_ring_mcast: Used slots 0/128, Failed frames 0/0 = 0.0%, Average tries 0.00
tg3 0000:10:00.0: PME# disabled
tg3 0000:10:00.0: irq 27 for MSI/MSI-X
ADDRCONF(NETDEV_UP): eth0: link is not ready
warning: `dbus-daemon' uses deprecated v2 capabilities in a way that may be insecure.
input: b43-phy0 as /class/input/input8
b43-phy0: Loading firmware version 351.126 (2006-07-29 05:54:02)
b43-phy0 warning: You are using an old firmware image. Support for old firmware will be removed in July 2008.
b43-phy0 warning: You must go to http://linuxwireless.org/en/users/Dr...devicefirmware and download the latest firmware (version 4).
b43-phy0 debug: Chip initialized
b43-phy0 debug: 64-bit DMA initialized
Registered led device: b43-phy0::tx
Registered led device: b43-phy0::rx
Registered led device: b43-phy0::radio
b43-phy0 debug: Wireless interface started
b43-phy0 debug: Adding Interface type 2
b43-phy0 debug: Using hardware based encryption for keyidx: 0, mac: ff:ff:ff:ff:ff:ff
ADDRCONF(NETDEV_UP): wlan0: link is not ready
b43-phy0 debug: Disabling hardware based encryption for keyidx: 0, mac: ff:ff:ff:ff:ff:ff
Bluetooth: Core ver 2.14
NET: Registered protocol family 31
Bluetooth: HCI device and connection manager initialized
Bluetooth: HCI socket layer initialized
Bluetooth: L2CAP ver 2.11
Bluetooth: L2CAP socket layer initialized
Bluetooth: RFCOMM socket layer initialized
Bluetooth: RFCOMM TTY layer initialized
Bluetooth: RFCOMM ver 1.10
Bluetooth: BNEP (Ethernet Emulation) ver 1.3
Bluetooth: BNEP filters: protocol multicast
Bridge firewalling registered
wlan0: authenticate with AP 00:22:b0:90:0b:4b
wlan0: authenticated
wlan0: associate with AP 00:22:b0:90:0b:4b
wlan0: RX AssocResp from 00:22:b0:90:0b:4b (capab=0x421 status=0 aid=2)
wlan0: associated
ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
wlan0: disassociating by local choice (reason=3)
wlan0: no IPv6 routers present
[drm] Initialized drm 1.1.0 20060810
[SNIP DRM STUFF]
[drm] writeback test succeeded in 1 usecs
fuse init (API version 7.11)
SELinux: initialized (dev fuse, type fuse), uses genfs_contexts
wlan0: authenticate with AP 00:22:b0:90:0b:4b
wlan0: authenticate with AP 00:22:b0:90:0b:4b
wlan0: authenticated
wlan0: associate with AP 00:22:b0:90:0b:4b
wlan0: RX ReassocResp from 00:22:b0:90:0b:4b (capab=0x421 status=0 aid=2)
wlan0: associated
wlan0: direct probe to AP 00:22:b0:90:0b:4b try 1
wlan0 direct probe responded
wlan0: authenticate with AP 00:22:b0:90:0b:4b
wlan0: authenticated
wlan0: associate with AP 00:22:b0:90:0b:4b
wlan0: RX AssocResp from 00:22:b0:90:0b:4b (capab=0x421 status=0 aid=2)
wlan0: associated
wlan0: disassociating by local choice (reason=3)
wlan0: authenticate with AP 00:22:b0:90:0b:4b
wlan0: authenticate with AP 00:22:b0:90:0b:4b
wlan0: authenticated
wlan0: associate with AP 00:22:b0:90:0b:4b
wlan0: RX ReassocResp from 00:22:b0:90:0b:4b (capab=0x421 status=0 aid=2)
wlan0: associated
tomboy[2844]: segfault at 405aa730 ip 00000000405aa730 sp 00007fff030ec248 error 14
[drm] Num pipes: 1
wlan0: disassociating by local choice (reason=3)
wlan0: direct probe to AP 00:22:b0:90:0b:4b try 1
wlan0 direct probe responded
wlan0: authenticate with AP 00:22:b0:90:0b:4b
wlan0: authenticated
wlan0: associate with AP 00:22:b0:90:0b:4b
wlan0: RX AssocResp from 00:22:b0:90:0b:4b (capab=0x421 status=0 aid=2)
wlan0: associated
wlan0: disassociating by local choice (reason=3)
wlan0: authenticate with AP 00:22:b0:90:0b:4b
wlan0: authenticated
wlan0: associate with AP 00:22:b0:90:0b:4b
wlan0: RX ReassocResp from 00:22:b0:90:0b:4b (capab=0x421 status=0 aid=2)
wlan0: associated
wlan0: disassociating by local choice (reason=3)
[drm] Setting GART location based on new memory map

[SNIP IRRELEVANT DRM STUFF]

[drm] writeback test succeeded in 1 usecs
SELinux: initialized (dev fuse, type fuse), uses genfs_contexts
wlan0: authenticate with AP 00:22:b0:90:0b:4b
wlan0: authenticate with AP 00:22:b0:90:0b:4b
wlan0: authenticated
wlan0: associate with AP 00:22:b0:90:0b:4b
wlan0: RX ReassocResp from 00:22:b0:90:0b:4b (capab=0x421 status=0 aid=2)
wlan0: associated
[declan@harriet ~]$

Actually, the complaint is valid, you're not supplying the value for the command to use. For example, setting the ssid should be:

iwconfig wlan0 essid YourSSIDGoesHere

Similarly to set a WEP key you would use:

iwconfig wlano key YourWEPKeyInHex


As for the rest of it, your guess is better than mine. Your still getting the warning about the old firmware, and it is clearly having trouble keeping a connection with the access point.

If it is flaky hardware, you should be having trouble in Vista as well as Linux. If it is stable in Vista, then it probably has a lot to do with how Linux handles USB wireless cards. You know as a last resort, you might try ndiswrapper and the Windows drivers. I've seen occasions where that combo works better on USB wireless than the native Linux drivers do.

I am explaining myself poorly.

The init scripts have several iwconfig statements and I see those strange numbers and errors roll up the screen. If I execute

iwconfig wlan0 essid MyESSID it throws the error
Error for wireless request "Set ESSID" (8B1A)

but sets the essid correctly. They are spurious reports from the wifi card. I have more or less given up here after going to
http://www.linuxwireless.org/en/users/Drivers/b43 and reading the FAQ. In the caveats section, it says:

"If you have an USB device with Broadcom chip, please try the RNDIS driver. The b43/b43legacy driver will never support this device. "

The 4312 is listed here as unsupported (hmmmph!), and elsewhere as partly functional. Between kernels 2.6.25 and now this has been changing heavily. The b43_pci_bridge tweak is actually in the ssb code, and that loads it, but I can't get that as a module. I am on Wi_Fi currently (hurray!) and lspci returns
30:00.0 Network controller: Broadcom Corporation BCM4312 802.11a/b/g (rev 02)
Subsystem: Hewlett-Packard Company Broadcom 802.11a/b/g WLAN
[snip]
Kernel driver in use: b43-pci-bridge
Kernel modules: ssb

So 'alias wlan0 ssb' might just be correct, although I prefer an install line, perhaps
install b43 /sbin/modprobe -i ssb; /sbin/modprobe -i b43; /sbin/morprobe -i btusb

I am going after PolicyKit (a missing dependency for compiling NetworkManager in Slamd64) and let the kernel mature. I would love to be able to sit this up on cli, but WiFi under X will have to do.

Thanks very much for your time and effort on this, Hangdog42

Just a final note to say where I have got to.

B43_Pci_Bridge (built into ssb.ko) is actually the driver for a 4312 on the usb bus. Who ever thinks of adding Sonics Silicon_Backplane into a kernel? Anyhow, then the kernel finds and configures things. I have an install line for b43 installing ssb, b43, & btusb in /etc/modprobe.d

I can get alive in Slamd64 (Not sure if all this is necessary) by
iwconfig wlan0 <my settings> - all done in init scripts.
ifconfig wlan0 up
iwconfig wlan0 ap <my access point number>
dhcpcd wlan0

Fedora does it automagically with NetworkManager, but that is dependency hell to compile. e.g.Polkit needs eggdbus (which has changed name). Go figure.Distros that supply gnome are fine, but Slamd has xfce (which I use) and kde.

I still get spurious errors because b43 is convinced that it is somehow on the pcmcia bus.

I know Slackware ships with wicd as NetworkManager replacement. To be honest, wicd is tons better and I'd be surprised if slamd didn't already have it.

Thanks for posting your findings. I'm sure someone else in this pickle will find it useful.