US Robotics MaxG PCMCIA wireless card? (solved!)

[RobertB]

I got a U.S. Robotics MaxG wireless networking PC Card, cheap from woot.com, a few months ago. I hadn't gotten around to trying it out, since the USR driver page gave only a link to ndiswrapper at sourceforge, but didn't include the .inf file that ndiswrapper needs for a start point. I figured the Linux community would get around to putting it all together in due time.

Well, it's a new year, and all the searches I've done for this card on Linux share a common thread: frustration. Nobody seems to have figured it out. There were several posts on a Ubuntu board, but most went unanswered and the one promising thread ended a year ago with a card being donated to the ndiswrapper project but to no avail (and I still can't find the referenced "doesn't work with ndiswrapper yet" message on the ndiswrapper site).

Anyone here have any information, or perhaps a pointer in a direction I should go?

[BlackAdder]

There look to be several US Robotics PCMCIA 802.11g cards. Can you tell us which model you have? Alternatively (or as well) could you post the result of an lspci command with the card plugged in? Presumably the network wizard does not show a wireless interface, implying that Puppy has not recognized the wireless chip set and matched it to a support module.
The Vendor ID and Product ID (the two four digit numbers separated by a colon) listed by lspci is a way of finding out who made the wireless chip set and what driver should be used. Lspci lists all the pci devices it finds, so there is likely to be a longish list. Finding out which chip set does not guarantee success, but at least is a start.

[setecio]

This might also help identify the chipset

http://linux-wless.passys.nl/query_part ... S+Robotics

[RobertB]

There look to be several US Robotics PCMCIA 802.11g cards. Can you tell us which model you have? Alternatively (or as well) could you post the result of an lspci command with the card plugged in? Presumably the network wizard does not show a wireless interface, implying that Puppy has not recognized the wireless chip set and matched it to a support module.
The Vendor ID and Product ID (the two four digit numbers separated by a colon) listed by lspci is a way of finding out who made the wireless chip set and what driver should be used. Lspci lists all the pci devices it finds, so there is likely to be a longish list. Finding out which chip set does not guarantee success, but at least is a start.

It's definitely this one:

Code: Select all

01:00.0 Class 0280: 14e4:4318 (rev 02)

Not only is that the only entry that goes away when I pull out the card, but it's listed in The Linux PCI ID Repository. In fact, there are a bunch of Google hits for 14e4:4318 -- unfortunately, many seemed to point towards failed attempts.

But this linux user's blog entry, mostly about ndiswrapper on Fedora, described having a .inf file for a card with PCI ID 14e4:4318 called LSBCMNDS.inf -- unfortunately, his card was from Linksys, so that .inf file wouldn't help me (even if I could find it somewhere).

The PCI ID shows that the chip comes from Broadcom. It looks pretty clear that the 4318 means that it's the BCM4318E, but without the .inf file -- which USRobotics doesn't seem to want to supply -- I can't do much.

I did see a "bcm43xx" entry in the Puppy Network Wizard. The description, though, says "pci: Broadcom BCM43xx wireless driver". I tried it anyway, hoping that "pci" was either a misprint or it would also work with pcmcia. No luck; I got a box saying "Loading cm43xx failed; try a different driver."

That was strange, though... loading another driver at random gave the "loaded successfully, but it may not actually work" message. I tried several random drivers in the Puppy Network Wizard list, and all said "loaded successfully". Even the other two Broadcom drivers were "loaded successfully", but not the one that looks like it most closely matches my PC card.

I'm a programmer, so I do a lot of debugging, and that sure seems like an indication that I'm really, really close. Is there some little thing I've overlooked, or is there some proprietary USRobotics addition that causes the card to choke just when it's about to wake up?

Other specs I neglected to include:

Puppy version: 2.17
Built-in eth0 works fine (driver eepro100)
My other card (a Linksys) works fine with driver r8180

Hmmm... Do I perhaps need to uninstall something related to the r8180 driver to make this one work?

[gamfa]

How do you know the Linksys driver won't work? I have seen card manufacturers use all types of chipsets. Sometimes there are different chips on the same model. The only difference will be the version number of the card. Download the Linksys for your model and version of the card and try it.

[RobertB]

How do you know the Linksys driver won't work? I have seen card manufacturers use all types of chipsets. Sometimes there are different chips on the same model. The only difference will be the version number of the card. Download the Linksys for your model and version of the card and try it.

Well, since the guy I linked to had success with my PCI ID and v3 of the Linksys drivers for the WPC54G, I'll give it a shot and let y'all know... it can't make it work any worse! Though I think I'll run from CD just in case -- I don't want to break my existing eth0 configuration with my old card. Yay for a distro that lets me test like that!

[BlackAdder]

Try this with ndiswrapper. The archive contains the .inf file and associated .sys file.
Have you checked whether the Linux driver BCM43XX works with that card? The driver is in Puppy 2.15CE, and probably in most other recent Puppies.

[RobertB]

Have you checked whether the Linux driver BCM43XX works with that card? The driver is in Puppy 2.15CE, and probably in most other recent Puppies.

Yes, as I noted above, I saw that and tried it and got an anomalous error message. When I run from CD, I'm going to try the bcm43xx driver and see if it works on a fresh system.

[RobertB]

Well, that was unexpected! Boot from CD (Puppy 2.17) and use the BCM43XX driver -- works! Oddly, it shows up as eth1, not wlan0. However, when I go to configure, it sees that it's a wireless interface.

I'm not near a known wireless network, though, so I'll have to try that later and report back.

Edit: It works! I'm using it now. It seems better at scanning than my older card -- it pulls up everything nearby all at once, where I usually have to hit "Scan" over and over to find even the strongest signal. No idea yet, of course, whether I'll be able to use it with Kismet or other non-integrated utilities.

And there's still the little problem of its incompatibility with my other card. But I would have to call that a minor glitch. I think I'll mark this one "solved", and answer the question: Yes, Puppy succeeds where other distros fail, even for a Linux newbie like me.

[Dougal]

That was strange, though... loading another driver at random gave the "loaded successfully, but it may not actually work" message. I tried several random drivers in the Puppy Network Wizard list, and all said "loaded successfully". Even the other two Broadcom drivers were "loaded successfully", but not the one that looks like it most closely matches my PC card.

All that message means is that the module was actually loaded into the kernel, not being rejected -- it does not mean you have the HW to match it (you can load successfully about half the SCSI modules even if you don't have any SCSI devices...).