Since you appear to have followed all the correct steps and ndiswrapper -l shows the hardware, you might check to see what happens when you load the driver. Dmesg should show something like: ndiswrapper version 1.2 loaded (preempt=no,smp=no) ndiswrapper: driver bcmwl5 (Broadcom,02/11/2005, 3.100.64.0) loaded ACPI: PCI Interrupt 0000:02:02.0[A] -> GSI 22 (level, low) -> IRQ 217 ndiswrapper: using irq 217 wlan0: ndiswrapper ethernet device 00:14:a5:4d:9e:40 using driver bcmwl5, configuration file 14E4:4319.5.conf wlan0: encryption modes supported: WEP, WPA with TKIP, WPA with AES/CCMP -- Jerry Feldman Boston Linux and Unix user group http://www.blu.org PGP key id:C5061EA9 PGP Key fingerprint:053C 73EC 3AC1 5C44 3E14 9245 FB00 3ED5 C506 1EA9

On Monday 24 April 2006 11:32 am, Paul Howie wrote:

/var/log/message had an error about the driver not being 32-bit. The dlink drivers seem to be the cause of the probelm, I've found some from the original chipset manufacturer that don't throw any errors on modprobe.

I've still not got the device showing in iwconfig but I'm hopeful that playing around in yast will resolve that. Possibly not. I found that when I loaded the 32-bit driver, "ndiswrapper -l" showed that it was loaded and that the hardware was detected, but after a modprobe, dmesg showed the errors.

-- Jerry Feldman Boston Linux and Unix user group http://www.blu.org PGP key id:C5061EA9 PGP Key fingerprint:053C 73EC 3AC1 5C44 3E14 9245 FB00 3ED5 C506 1EA9

The device is detected ok (bus 1 device 3):

# lsusb Bus 001 Device 004: ID 047d:101f Kensington Bus 001 Device 003: ID 07d1:3c03 D-Link System Bus 001 Device 001: ID 0000:0000 Unfortunately, I do not have the same device. My device is a Broadcom 4319 Airforce chip on the mother board. In your case, you have a device that is detected at PCIID 07d1:3c03. From the previous posts, ndiswrapper is able to validate the driver and detect the hardware, but you stated that the driver is the wrong driver for

On Monday 24 April 2006 12:20 pm, Paul Howie wrote: the architecture. On my system, AMD-64 with a 64-bit SuSE 10.0, with the 32-bit driver "ndiswrapper -l" reported hardware present, but when the driver was loaded (by modprobe) the driver actually faulted. When I initially tried the 64-bit driver, ndiswrapper -l reported: gaf@gaflap:~> ndiswrapper -l Installed ndis drivers: bcmwl5 driver present In my specific case, I ran: ndiswrapper -d 14e4:4319 bcmwl5 Then ndiswrapper -l reports bcmwl5 driver present, hardware present As soon as I did this and loaded the module (modprobe ndiswrapper), dmesg indicated a successful load of the driver and wlan0 appeared. You may be reporting it as eth1. You might also try "ndiswrapper -hotplug" since your device is a USB device. -- Jerry Feldman Boston Linux and Unix user group http://www.blu.org PGP key id:C5061EA9 PGP Key fingerprint:053C 73EC 3AC1 5C44 3E14 9245 FB00 3ED5 C506 1EA9

I also found that there is a native linux driver available for the device.  I've compiled it and used insmod to load it but that doesn't seem to be working either... I'm probably missing something simple. I'll probably wait until suse 10.1 is out since I'm already planning to upgrade.  Hopefully things will go more smoothly for that. A native driver is much preferable to a Windows driver. Make sure that you remove ndiswrapper, and the ndiswrapper driver. I found

On Monday 24 April 2006 3:11 pm, Paul Howie wrote: that shortly after I got it working that it was trying to load the driver at the incorrect PCIID (that I mistyped) and then the correct one. In this case, it was working, but there were some bootup messages. ndiswrapper -e should remove that driver, and then make sure the ndiswrapper module is not loaded. Also note that some vendors tend to change chips in mid-stream. Belkin uses Broadcom, but ndiswrapper does not work for all the Belkin wireless devices that use the Broadcom chip. In any case, before you give up, make sure your system is completely clean, and then install the native driver. -- Jerry Feldman Boston Linux and Unix user group http://www.blu.org PGP key id:C5061EA9 PGP Key fingerprint:053C 73EC 3AC1 5C44 3E14 9245 FB00 3ED5 C506 1EA9

On 24/04/06, Carl Hartung wrote:

Have you tried the boot parameter "acpi=noirq"? Someone else yesterday had a usb network adapter refusing to configure/connect and adding this boot parameter solved the problem (it was contending with his usb mouse.)

Also, try unplugging the adapter, waiting a few seconds and plugging it back in ;-) I'm wondering if the module might respond to a 'new usb hardware found' event...

I'll give that a try and let you know if I have any luck. The strange thing is that the hardware is listed in the output of both lsusb and ndiswrapper -l. It seems to be detecting and installing just fine, but not bringing up the wlan0 (or eth1 or whatever) interface. I've learned a lot about ndiswraper and even found a native linux driver for the chipset so at this point I'm quite prepared to cut my losses and wait for 10.1 since I'll just have to do it all again then anyway. Thanks for the help. -- Paul