working from notes on b43 - Linux Wireless
I determined that the WLAN was
PCI-ID Supported? Chip ID Modes PHY version Alternative
14e4:4318 yes BCM4318 b/g G (r7)
and then
1 sudo zypper install b43-fwcutter
2 sudo /usr/sbin/install_bcm43xx_firmware
which got me to the point where Yast would recognize the wireless as existing. As the command
/usr/sbin/iwlist scan |grep ESSID produced:
ESSID:“NETGEAR84”
ESSID:“linksys_fuzzybut”
ESSID:“HPJ310a.F6D156”
ESSID:“dlink”
ESSID:“HOME-2C48”
ESSID:""
ESSID:“NETGEAR71”
ESSID:""
ESSID:“downloadonehumongousvirus”
ESSID:“linksys-jaime”
ESSID:“2WIRE256”
ESSID:“Scaramanga”
ESSID:“2WIRE585”
ESSID:“BooYah”
ESSID:“MadGuru2”
***************************************************************
But a couple of issues remain:
Is there graphical software which will allow the connection to be completed? Or is it all command line? Betting there is just one stupid thing that I’ve missed necessary to get this working.
does the firmware have to be downloaded each time the computer is booted? It appears this may be so as a glitch lost power and the wireless firmware disappeared when rebooted. Are there notes on how to do this automagically on boot? Apparently the wireless is now up as the 4th LED which I had not seen before is now showing.
Anyway pointers to URL’s and comments would be appreciated to get this wireless up and running…
thanks
J.
On 06/17/2013 03:16 AM, jefferies wrote:
>
> This is a throwaway DELL B120 that I’m trying to resurrect. So initially
> I wasn’t sure what was installed but Yast reported:
>
> 28: PCI 203.0: 0280 Network controller
> [Created at pci.319]
> Unique ID: QOEa.GzN3dC+wUS1
> Parent ID: 6NW+.UesMqiV7iOA
> SysFS ID: /devices/pci0000:00/0000:00:1e.0/0000:02:03.0
> SysFS BusID: 0000:02:03.0
> Hardware Class: network
> Model: “Dell Wireless 1370 WLAN Mini-PCI Card”
> Vendor: pci 0x14e4 “Broadcom”
> Device: pci 0x4318 “BCM4318 [AirForce One 54g] 802.11g Wireless LAN
> Controller”
> SubVendor: pci 0x1028 “Dell”
> SubDevice: pci 0x0005 “Wireless 1370 WLAN Mini-PCI Card”
> Revision: 0x02
> Driver: “b43-pci-bridge”
> Driver Modules: “ssb”
> Memory Range: 0xdfbfe000-0xdfbfffff (rw,non-prefetchable)
> IRQ: 17 (no events)
> Module Alias: “pci:v000014E4d00004318sv00001028sd00000005bc02sc80i00”
> Driver Info #0:
> Driver Status: ssb is active
> Driver Activation Cmd: “modprobe ssb”
> Config Status: cfg=no, avail=yes, need=no, active=unknown
> Attached to: #24 (PCI bridge)
> *********************************************************
> working from notes on ‘b43 - Linux Wireless’
> (http://wireless.kernel.org/en/users/Drivers/b43)
> I determined that the WLAN was
> PCI-ID Supported? Chip ID Modes PHY version Alternative
> 14e4:4318 yes BCM4318 b/g G (r7)
> and then
> 1 sudo zypper install b43-fwcutter
> 2 sudo /usr/sbin/install_bcm43xx_firmware
>
> which got me to the point where Yast would recognize the wireless as
> existing. As the command
>
> /usr/sbin/iwlist scan |grep ESSID produced:
> ESSID:“NETGEAR84”
> ESSID:“linksys_fuzzybut”
> ESSID:“HPJ310a.F6D156”
> ESSID:“dlink”
> ESSID:“HOME-2C48”
> ESSID:""
> ESSID:“NETGEAR71”
> ESSID:""
> ESSID:“downloadonehumongousvirus”
> ESSID:“linksys-jaime”
> ESSID:“2WIRE256”
> ESSID:“Scaramanga”
> ESSID:“2WIRE585”
> ESSID:“BooYah”
> ESSID:“MadGuru2”
> ***************************************************************
> But a couple of issues remain:
> 1. Is there graphical software which will allow the connection to be
> completed? Or is it all command line? Betting there is just one stupid
> thing that I’ve missed necessary to get this working.
> 2. does the firmware have to be downloaded each time the computer is
> booted? It appears this may be so as a glitch lost power and the
> wireless firmware disappeared when rebooted. Are there notes on how to
> do this automagically on boot? Apparently the wireless is now up as the
> 4th LED which I had not seen before is now showing.
>
> Anyway pointers to URL’s and comments would be appreciated to get this
> wireless up and running…
> thanks
The GUI is called NetworkManager; however, without two critical pieces of
information, it is impossible go any further. What is your openSUSE version, and
which desktop are you using?
The firmware does not disappear when you reboot. If you do not believe me,
check the contents of /lib/firmware/b43/ before and after you reboot. Those
files are the firmware. The script that downloads and installs the firmware
finishes by reloading the driver. You have messed around with the abominable
Broadcom wl driver, and it has blacklisted b43 and ssb. That blacklisting is
preventing b43 from loading upon reboot, and the firmware installation script
overrides the blacklisting. Find the lines that blacklist ssb and b43 in
/etc/modprobe.d/ and delete them.
Ouch, Sorry 'bout that. There are battery (on order, arriving today) issues that caused the machine to take a dive just as I finished my initial post at 1AM. So I re-input the post and left out important details. Linux installation is Suse 12.3 Manager is KDE You are correct that the firmware is still on the hard disk. What I meant to say is that it does not stay resident in the hardware but apparently needs to be reloaded. Which is what I take you mean by the “blacklisting”. So I will explore with the script files later today as you’ve suggested. “NetworkManager” is available. Took a few searches to get it down. But I’ve yet to fully adapt to its way of making connections which is why my query about gui front ends. Also the laptop will be eventually given to someone less familiar with command line than myself. So… But thanks for the suggestions and I will continue my explorations. J. P.S. why is the website software munging my carefully formatted posting. Is there some switch not turned on?
> Ouch, Sorry 'bout that. There are battery (on order, arriving today)
> issues that caused the machine to take a dive just as I finished my
> initial post at 1AM. So I re-input the post and left out important
> details. Linux installation is Suse 12.3 Manager is KDE You are
> correct that the firmware is still on the hard disk. What I meant to say
> is that it does not stay resident in the hardware but apparently needs
> to be reloaded. Which is what I take you mean by the “blacklisting”. So
> I will explore with the script files later today as you’ve suggested.
> “NetworkManager” is available. Took a few searches to get it down. But
> I’ve yet to fully adapt to its way of making connections which is why my
> query about gui front ends. Also the laptop will be eventually given to
> someone less familiar with command line than myself. So… But thanks
> for the suggestions and I will continue my explorations. J. P.S. why
> is the website software munging my carefully formatted posting. Is there
> some switch not turned on?
Firmware never stays resident in the hardware through a power failure as it is
stored in volatile ram on the device. As a result, a driver may not assume that
it is present, and must reload firmware on driver start. BTW, firmware is the
program that is running on the CPU built into the device. The driver is the
software that runs on the host processor.
No, blacklisting is the process that keeps the driver from being loaded
automatically by the kernel when it finds a device while scanning the bus. That
is very different.
Any computer code should be posted inside “code” tags that you can find in the
Advanced edit section.
I’ll let someone else explain how to get your wireless device under the control
of NM, how to get the NM applet into the system area, and how to manage wireless
connections, or you can do a bit of searching. You will learn a lot.
Although I appreciate your help I must call you on “never”. I’ve written firmware and device drivers for thirty some years and most firmware is loaded into core, prom, eprom, eeprom, flash or some other “permanent or semi-permanent” memory. I believe the distinction that your are intending to make is that firmware is a static program “usually” loaded into specific memory locations and not subject to relocation. Though I’ve done that from time to time. Apparently this particular device’s programming loads into volatile memory and is subject to being lost during power loss. Which is what confused me at first. I thought the process of downloading the firmware was actually flashing it or some other process to permanently load it. I’ve not delved into Broadcom chips recently and never into their wireless offerings (dated though this one must be).
So if I remove it from the “blacklist” the kernel or some process it calls will know how to load the devices programming/firmware.
Sorry you lost me on this comment.
Well thank you for your initial help. I’ll continue my search if the kitten presently trying to take over my mouse will permit.
On 06/17/2013 07:26 PM, jefferies wrote:
>
> Ah, we have overloaded key words:
> lwfinger;2565500 Wrote:
>> On 06/17/2013 11:16 AM
>> Firmware never stays resident in the hardware through a power failure
>> as it is
>> stored in volatile ram on the device. As a result, a driver may not
>> assume that
>> it is present, and must reload firmware on driver start. BTW, firmware
>> is the
>> program that is running on the CPU built into the device. The driver is
>> the
>> software that runs on the host processor.
> Although I appreciate your help I must call you on “never”. I’ve
> written firmware and device drivers for thirty some years and most
> firmware is loaded into core, prom, eprom, eeprom, flash or some other
> “permanent or semi-permanent” memory. I believe the distinction that
> your are intending to make is that firmware is a static program
> “usually” loaded into specific memory locations and not subject to
> relocation. Though I’ve done that from time to time. Apparently this
> particular device’s programming loads into volatile memory and is
> subject to being lost during power loss. Which is what confused me at
> first. I thought the process of downloading the firmware was actually
> flashing it or some other process to permanently load it. I’ve not
> delved into Broadcom chips recently and never into their wireless
> offerings (dated though this one must be).
The only wireless devices that place their firmware in any sort of ROM are those
that implement only 802.11g. Of my ~40 wireless devices, only 3 are in that
category. For 802.11n devices, the firmware is distributed as a binary file, and
loaded into the device’s on-board RAM. This way, it is relatively easy to update
the firmware as coding errors are fixed.
>> No, blacklisting is the process that keeps the driver from being loaded
>> automatically by the kernel when it finds a device while scanning the
>> bus. That
>> is very different.
> So if I remove it from the “blacklist” the kernel or some process it
> calls will know how to load the devices programming/firmware.
Yes. The kernel knows how to load the driver, and the driver will load the
firmware into the device’s CPU.
>> Any computer code should be posted inside “code” tags that you can find
>> in the
>> Advanced edit section.
> Sorry you lost me on this comment.
If you post computer output in the raw mode, its formatting is changed, special
sequences are converted into smilies, etc. The code tags, which are an advanced
edit function, keep that from happening. Look for the Advanced link.