# [GAVE UP]gentoo-sources-2.6.24: 2 wifi cards, no success

## Havin_it

Hello,

I've had worsening problems with my wireless setup ever since ndiswrapper-1.48, and now with the arrival of gentoo-sources-2.6.24 I'm well and truly stuffed.

My primary card, which has been reliable for 2+ years, is this:

```

pengi linux # lspci -n|grep 14e4

03:00.0 0280: 14e4:4320 (rev 03)

...more detail...

03:00.0 Network controller: Broadcom Corporation BCM4306 802.11b/g Wireless LAN Controller (rev 03)

        Subsystem: Belkin Belkin F5D7010 54g Wireless Network card

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

        Interrupt: pin A routed to IRQ 16

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

        Kernel driver in use: bcm43xx

        Kernel modules: bcm43xx

```

...aka Belkin F5D7010 Wireless Notebook Network Adaptor.

My access point at home uses WPA-PSK, though I also use other (WEP/open) APs and Ad-hoc cells.

Since ndiswrapper-1.48 it began to fail, first failing to associate with Ad-hoc nodes, then (from 1.49 onwards) failing to associate with anything. I asked for help on the ndiswrapper forums, but still have had no reply.

I was able to use the bcm43xx driver, though not with ad-hoc. I waited patiently for the release of gentoo-sources-2.6.24, with the new b43/b43legacy drivers which would, I was told by the devs, support ad-hoc.

I installed the new kernel 2 nights ago, downloaded and "cut" the recommended firmware for both b43 and b43legacy, enabled both drivers as modules, and got complete failure. The interface did come up with the automatically-selected b43 (as did another interface called wmaster0 (?)), but association never happened. When I tried enabling only b43legacy, starting net.wlan0 failed (unable to find the interface).  I even tried going back to bcm43xx, but this also got a "no interface" error.

As a last-ditch, I tried my Netgear WPN111 USB card (I keep this to provide an ad-hoc connection with another machine) with ndiswrapper, but once again this gave me no interface. Ndiswrapper did tell me that the driver and hardware were correctly present, but there was no sign of life from the dongle.

Right now the only working solution for me is the Belkin card with 2.6.23 kernel and bcm43xx -- an unsustainable position.

I have debug turned up high in wpa_supplicant, and ndiswrapper built with USE=debug. I don't want to start posting loads of output that nobody might read, especially when I have to alternate between a working kernel and the one I have to debug, but will post whatever you ask if it helps.

Please help -- I would rather not have to buy a new wifi card when I have two that are supposed to be well-supported by Linux.Last edited by Havin_it on Thu Feb 07, 2008 5:43 pm; edited 1 time in total

----------

## Raftysworld

I'm having the exact same problem with the exact same driver and card.

 :Sad: 

----------

## urcindalo

Have you taken a look here: Native Airport Extreme Drivers (part 2)? The info is not PPC specific.

----------

## Havin_it

 *urcindalo wrote:*   

> Have you taken a look here: Native Airport Extreme Drivers (part 2)? The info is not PPC specific.

 

Yes, been there, posted my woes there to begin with, but I think I got overlooked  :Sad: 

I followed the front-page instructions faithfully from the outset, but no joy.

Overnight, I had some success with ndiswrapper on the Belkin card. I went on #ndiswrapper and got advice to disable all softmac, mac80211 and SSB support in my kernel.  The result of this was I got more like the pre-2.6.24 behaviour: everything OK up to GROUP_HANDSHAKE, then nothing more.

However, I fell asleep in this state, and when I woke up a couple of hours later I was connected!  I can't see anything in the (copious) dmesg output that points to when/how this happened, but I guess it's encouraging... kinda.

I tried again this morning, left it running away for 30min or so, but it did not connect. Something I did notice is that status doesn't hang constantly on GROUP_HANDSHAKE: every couple of minutes it flips back to ASSOCIATING for a moment.

I do wonder if it might be a problem with wpa_supplicant, rather then the driver(s). Maybe it's my configuration? Here's the relevant bits from /etc/conf.d/net:

```

modules=( "wpa_supplicant" )

wpa_supplicant_wlan0="-Dwext -dd"

dhcp_wlan0="nodns"

preferred_aps=( "reagent" "dongled" "footlightsbar" "jollyjudge" )

associate_order="preferredonly"

scan_mode_wlan0="Ad-Hoc"

# home network

channel_reagent="6"

config_reagent=( "192.168.2.4 netmask 255.255.255.0" )

routes_reagent=( "default via 192.168.2.1" )

dns_servers_reagent=( "192.168.2.1" )

mode_reagent="managed"

# ad-hoc connection

mode_dongled="ad-hoc"

config_dongled=( "192.168.1.15 netmask 255.255.255.0" )

routes_dongled=( "default via 192.168.1.1" ) 

dns_servers_dongled=( "192.168.1.1" )

```

And here's wpa_supplicant.conf:

```

ctrl_interface=/var/run/wpa_supplicant

ap_scan=2

fast_reauth=1

network={

        ssid="reagent"

        scan_ssid=1

        proto=WPA

        key_mgmt=WPA-PSK

        pairwise=TKIP

        group=TKIP

        psk=<SNIP>

        priority=10

}

network={

        ssid="dongled"

        mode=1

        key_mgmt=NONE

        wep_key0=<SNIP>

        wep_tx_keyidx=0

        priority=1

}

```

Any clangers in here?

----------

## Havin_it

Hm, more progress. I swapped back to bcm43xx and it worked immediately. I suspect it was disabling SSB support in the kernel that helped, as it did for ndiswrapper (though that obviously has further problems) because when enabled, ssb would glom onto the device. (This is what it's supposed to do for b43*, I think).

Of course, this means I'll still be unable to use an ad-hoc connection, so this issue isn't resolved for me until I can get back to success with ndiswrapper or make b43* work. But at least I don't have to stick with an old kernel   :Rolling Eyes: 

One thing that bugs me about wpa_supplicant is how little documentation there seems to be, either online or in the package. Most of the directives you find in a typical user's wpa_supplicant.conf posted online (many of which I've used) are not mentioned in the manpage, and there doesn't seem to be any documentation on their site that covers this in full. Oh, and there's no dedicated forum and their bugzilla seems to be permanently "on hiatus". Just how the dickens is Joseph User supposed to configure this program the way the devs intended?

Do they by any chance have an IRC channel?

EDIT: OK, I take back the bit about documentation. Found this in their viewcvs:

http://hostap.epitest.fi/cgi-bin/viewcvs.cgi/hostap/wpa_supplicant/wpa_supplicant.conf?content-type=text%2Fplain&revision=HEAD

This might help me a bit...

----------

## Havin_it

Couple of further items.  I got on the #b43-users channel, it was pretty quiet but someone asked me whether I could still scan when using b43. My answer didn't get any feedback at the time but here it is: "yes."

Well, when I have my normal setting in wpa_supplicant.conf (ap_scan=2), yes I can scan. If I change to ap_scan=1, I can't -- and also, the wpa status stops at SCANNING (before it stopped at ASSOCIATING). With ap_scan=0 I get no status at all.

Also, in each case, the last message reported by wpa_gui is "- received signal 15". Is this any help?

One further thing: iwpriv. Is there anything I can usefully do with this, that might have some effect? FWIW, when using bcm43xx the iwpriv wlan0 output looks like this:

```
wlan0     Available private ioctls :

          set_interfmode   (8BE0) : set   1 int   & get   0

          get_interfmode   (8BE1) : set   0       & get  80 char

          set_shortpreamb  (8BE2) : set   1 int   & get   0

          get_shortpreamb  (8BE3) : set   0       & get  80 char

          set_swencrypt    (8BE4) : set   1 int   & get   0

          get_swencrypt    (8BE5) : set   0       & get  80 char

          write_sprom      (8BE6) : set 512 char  & get   0

          read_sprom       (8BE7) : set   0       & get 512 char

```

Anything useful there?

----------

## coolsnowmen

 *Havin_it wrote:*   

> SSB support in my kernel

 

is SSB the

Sonics Silicon Backplane?

----------

## Havin_it

 *coolsnowmen wrote:*   

> 
> 
> is SSB the
> 
> Sonics Silicon Backplane?

 

Yes. Enabling b43* automatically selects it, but if you're using any other driver (bcm43xx or ndiswrapper) you need to disable it, as it seems to be the kernel's first choice for attaching to the PCI device your card is on.

----------

## slackline

 *Havin_it wrote:*   

>  *coolsnowmen wrote:*   
> 
> is SSB the
> 
> Sonics Silicon Backplane? 
> ...

 

How did you disable it?  Simply edit the .config by hand?  Under menuconfig its not possible to toggle these options, presumably because they have been automatically toggled to =y when selecting b43* support.

----------

## Havin_it

You just disable both b43 and b43legacy, then you can disable ssb.  It's force-selected by both of these (not by anything else that I know of), but as long as they aren't enabled, ssb is under your control.

PS - I never recommend editing .config by hand, those dependency chains like this one are there for a reason  :Razz: 

PPS - I've basically given up on this question and have a new device arriving in a few days. I've had virtually no response to various pleas for help both here and on #ndiswrapper and #bcm-users, and I can't devote any more time to that apparently fruitless pursuit, I need to get on with actually using my computer.

That said, a big thanks to those who have made suggestions, and if you have any others to share before the week is out I'll certainly try them.  I'll close once my new card is up and running.

----------

## Havin_it

Posting this via my new Netgear WPN511 card   :Very Happy: 

I'm becoming aware of other folks who are in the same position as me, Broadcom-wise, with this new kernel. I'll probably be giving that card away shortly, so I can't offer much further debugging help apart from what I've already posted, I'm afraid. Props to the b43 and mac80211 teams for what they're trying to achieve, but after this fiasco I can't help but think that they are ultimately trying to fit a lot of square pegs into a round hole, and I sincerely hope that something like madwifi (which I got up and running quicker than the equivalent configuration tasks on Windows with the same card) won't be cold-shouldered to the point where it stops working, the way ndiswrapper for bcm cards apparently has been.

That said, I will spend a bit of time (not a lot!) sometime soon to see if the new mac80211 (fully libre) version of the atheros driver works reliably. It certainly won't be of much interest until they get Ad-hoc and master modes working, but I am still (despite above rant) in tune with the goal of a simpler, "do-it-all" wireless framework, so I will try at least.

----------

## sirgt

 *Havin_it wrote:*   

> You just disable both b43 and b43legacy, then you can disable ssb.  It's force-selected by both of these (not by anything else that I know of), but as long as they aren't enabled, ssb is under your control.
> 
> 

 

Maybe a little late for this but I'm assuming that this problems are because support for BCM43XX, Broadcom 43xx and Broadcom 43xx-legacy is experimental right?

I have the same problem and what I do is

* rmmod ndiswrapper

* rmmod ssb

* modprobe ndiswrapper

* [/list]/etc/init.d/net.eth1 restart 

and everything goes up  :Very Happy: 

----------

