D-Link USB wireless .11n dongle configured, but no connection

I recently bought a D-Link DIR-655 router capable of 802.11n operation, upgrading from a DIR-624 router only capable of 802.11g operation. While my overall setup uses wired connections, other people in the house prefer wireless, and the upgrade was undertaken more for a hoped for increase in wireless range, rather than the possibility of increased speed, since the router is located to accommodate the wired connections. However, to test the 802.11n operation I bought a D-Link DWA-130 USB dongle for my now 5-year old laptop, which comes with an otherwise satisfactory 100Mbs ethernet port(eth1) and an 802.11g wireless card(eth0). By checking the dmesg | grep firmware output after I plugged in the dongle I determined that the necessary firmware was rtl8192sfw.bin, which I found on the web, and downloaded into the directory /lib/RTL8192SU. A subsequent reboot and then YaST > Network Devices > Network Settings showed the device as wlan0, but not configured. I changed the Network Setup Method to ifup (since I can see no way to do a device configuration in Network Manager), and configured the device, and at the same time deleted the configuration for the existing 802.11g wireless card(eth0). I then rebooted, went back into YaST to confirm the wlan0 device was configured and the 802.11g device (eth0) was not, changed the Network Setup Method back to Network Manager, rebooted again. Making sure that the router was set to only transmit/receive using 802.11n I then typed iwlist scan. To my surprise, the output showed first that the supposedly unconfigured eth0 device seemed to be still active, for it found my home network, and claimed that the protocol used was 802.11g. On the other hand, the newly configured wlan0 device produced the message: “Interface doesn’t support scanning: Network is down”.

First, should I expect iwlist scan to work for a device that shows as unconfigured? And even if it should work, shouldn’t it show 802.11n as the protocol, assuming that the router is in fact telling the truth? Is there any independent means to determine if the router is only using 802.11n as it claims?

Second, the overall goal is to make the wireless network in the house 802,11n only, and since the dongle is backward compatible with 802.11g, I would expect to permanently unconfigure the eth0 device and use the dongle, both here and on the road. I do not need two wireless connections on my laptop.

Any suggestions on where I should go from here would be appreciated. The laptop is running SuSE 11.2 as of about a month ago. Some relevant(I hope) command line output:

siracusa:~ # uname -a
Linux siracusa 2.6.31.12-0.2-desktop #1 SMP PREEMPT 2010-03-16 21:25:39 +0100 i686 i686 i386 GNU/Linux

USB Information

siracusa:~ # lsusb
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 002: ID 2001:3301 D-Link Corp. [hex]
Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 005 Device 002: ID 062a:0001 Creative Labs Notebook Optical Mouse

siracusa:~ # iwlist scan
lo Interface doesn’t support scanning.

wlan0 Interface doesn’t support scanning : Network is down

eth0 Scan completed :
Cell 01 - Address: 00:22:B0:B0:B6:AF
ESSID:“lrk_associates”
Protocol:IEEE 802.11g
Mode:Master
Frequency:2.412 GHz (Channel 1)
Encryption key:on
Bit Rates:1 Mb/s; 2 Mb/s; 5.5 Mb/s; 6 Mb/s; 9 Mb/s
11 Mb/s; 12 Mb/s; 18 Mb/s; 24 Mb/s; 36 Mb/s
48 Mb/s; 54 Mb/s
Quality=94/100 Signal level=-33 dBm
IE: IEEE 802.11i/WPA2 Version 1
Group Cipher : CCMP
Pairwise Ciphers (1) : CCMP
Authentication Suites (1) : PSK
Extra: Last beacon: 160ms ago

eth1 Interface doesn’t support scanning.

I also have the relevant parts of YaST > Hardware > Hardware Information (Save to file), but I won’t further lengthen this post with them unless they are thought relevant

Try setting it up using the traditional method (ifup) and then checking with iwscan.
It looks like you are picking up a network (ESSID:“lrk_associates”)
Make sure you have the correct encryption settings, etc.
It’s probably easier to start using an no encryption on an open network and to change once it is configured.

I have shut off encryption at the router, converted back to ifup network management and disabled encryption at the computer, rebooted, and run iwlist scan again. There is no change in the output, except that the scan on the supposedly unconfigured eth0 card now shows the lack of encryption. It still picks up my home network “lrk_associates” and shows it operating using 802.11g.

If I unplug the dongle, rerun iwlist scan again, the only change is that the wlan0 entry:

wlan0 Interface doesn’t support scanning : Network is down

disappears. Plugging the dongle back in simply returns this wlan0 entry to the iwlist scan output.

Am I missing the point about what “configured” means? While I realize that the hardware (eth0,eth1,wlan0) will always be recognized if it is plugged in, my understanding of “configuration” is essentially that the operating system is told to associate a particular driver/module with the particular piece of hardware, and so it can issue commands to, or receive output from the device. If this is the case, then how is iwlist scan operating eth0?

On 04/28/2010 10:36 AM, lrkeefe wrote:
>
> I have shut off encryption at the router, converted back to ifup network
> management and disabled encryption at the computer, rebooted, and run
> iwlist scan again. There is no change in the output, except that the
> scan on the supposedly unconfigured eth0 card now shows the lack of
> encryption. It still picks up my home network “lrk_associates” and
> shows it operating using 802.11g.
>
> If I unplug the dongle, rerun iwlist scan again, the only change is
> that the wlan0 entry:
>
> wlan0 Interface doesn’t support scanning : Network is down
>
> disappears. Plugging the dongle back in simply returns this wlan0
> entry to the iwlist scan output.
>
> Am I missing the point about what “configured” means? While I realize
> that the hardware (eth0,eth1,wlan0) will always be recognized if it is
> plugged in, my understanding of “configuration” is essentially that the
> operating system is told to associate a particular driver/module with
> the particular piece of hardware, and so it can issue commands to, or
> receive output from the device. If this is the case, then how is iwlist
> scan operating eth0?

The operating system recognizes the hardware and loads the driver based
on the PCI or USB IDs that are hardwired into the device. This action is
not configuration.

Configured means the details of how the device connects to the outside
world. The OS cannot do this part on its own. As you are using ifup, the
configuration is controlled by files /etc/sysconfig/network/ifcfg-XXXXX,
where XXXXX is eth0, eth1, wlan0.

Please post the output of the command ‘lsusb’ when both your wireless
devices are plugged in.

You also have what I consider a naming problem. Normally, eth0 and eth1
are used for wired devices and wlan0, wlan1 are used for wireless. These
names are controlled by udevd based on a set of rules. Please post the
output of ‘cat /etc/udev/rules.d/50-persistent-network.rules’.

The outputs requested:

siracusa:/etc/sysconfig/network # lsusb
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 004: ID 2001:3301 D-Link Corp. [hex]
Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 005 Device 002: ID 062a:0001 Creative Labs Notebook Optical Mouse

siracusa:/etc/sysconfig/network # cat /etc/udev/rules.d/50-persistent-network.rules
cat: /etc/udev/rules.d/50-persistent-network.rules: No such file or directory

Remember that the dongle is the only network device plugged into USB, eth0 is built-in hardware. The state of the machine at this point is that eth0 remains unconfigured, and consistent with what you said about using ifup, a ls of the /etc/sysconfig/network directory only shows files for wlan0 and eth1.

I am guessing that the absence of a naming rules file is a problem?

Let me say also that I am using ifup only because I could not see any way to get the dongle configured in the first place. I prefer the Network Manager setup otherwise, and have used it under SuSE 10.3 until the recent upgrade

On 04/28/2010 12:56 PM, lrkeefe wrote:
>
> The outputs requested:
>
> siracusa:/etc/sysconfig/network # lsusb
> Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
> Bus 001 Device 004: ID 2001:3301 D-Link Corp. [hex]
> Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
> Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
> Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
> Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
> Bus 005 Device 002: ID 062a:0001 Creative Labs Notebook Optical Mouse
>
> siracusa:/etc/sysconfig/network # cat
> /etc/udev/rules.d/50-persistent-network.rules
> cat: /etc/udev/rules.d/50-persistent-network.rules: No such file or
> directory
>
> Remember that the dongle is the only network device plugged into USB,
> eth0 is built-in hardware. The state of the machine at this point is
> that eth0 remains unconfigured, and consistent with what you said about
> using ifup, a ls of the /etc/sysconfig/network directory only shows
> files for wlan0 and eth1.
>
> I am guessing that the absence of a naming rules file is a problem?

My bad. That is what I get for trying to do things from memory. The
correct file is /etc/udev/rules.d/70-persistent-net.rules.

You can get rid of wlan0 by blacklisting its driver. In a quick review
of this thread, I did not see any ID for it. You should add a line

blacklist <driver-name> to the end of
/etc/modprobe.d/50-blacklist.conf. Of course, replace <driver-name> with
the name of the module used for that device. If you do not know the
name, include the output of ‘lsmod’.

OK, the contents of 70-persistent-net.rules is

This file was automatically generated by the /lib/udev/write_net_rules

program,run by the persistent-net-generator.rules rules file.

You can modify it,as long as you keep each rule on a single

line,and change only the value of the NAME= key.

PCI device 0x8086:0x4220 (ipw2200)

PCI device 0x14e4:0x170c (b44)

This file was automatically generated by the /lib/udev/write_net_rules

program,run by the persistent-net-generator.rules rules file.

You can modify it,as long as you keep each rule on a single

line,and change only the value of the NAME= key.

PCI device 0x8086:0x4220 (ipw2200)

PCI device 0x14e4:0x170c (b44)

USB device 0x2001:0x3301 (usb)

SUBSYSTEM==“net”, ACTION==“add”, DRIVERS=="?", ATTR{address}==“00:12:f0:2a:b6:bb”, ATTR{type}==“1”, KERNEL=="eth", NAME=“eth
0”
SUBSYSTEM==“net”, ACTION==“add”, DRIVERS=="?", ATTR{address}==“00:11:43:74:8b:35”, ATTR{type}==“1”, KERNEL=="eth", NAME=“eth
1”
SUBSYSTEM==“net”, ACTION==“add”, DRIVERS=="?", ATTR{address}==“00:e0:4c:81:92:00”, ATTR{type}==“1”, KERNEL=="wlan", NAME=“wl
an0”

The drivers/modules associated with the various devices are:

eth0: ipw2200
eth1: b44
wlan0: r8192s_usb

Why would I be blacklisting the one for wlan0? If you are referring to my ultimate goal to only use the dongle for wireless communication, then shouldn’t I blacklist the driver for eth0, namely ipw2200?

On 04/28/2010 04:06 PM, lrkeefe wrote:
>
> OK, the contents of 70-persistent-net.rules is
>
> # This file was automatically generated by the
> /lib/udev/write_net_rules
> # program,run by the persistent-net-generator.rules rules file.
> #
> # You can modify it,as long as you keep each rule on a single
> # line,and change only the value of the NAME= key.
> # PCI device 0x8086:0x4220 (ipw2200)
> # PCI device 0x14e4:0x170c (b44)
> # This file was automatically generated by the
> /lib/udev/write_net_rules
> # program,run by the persistent-net-generator.rules rules file.
> #
> # You can modify it,as long as you keep each rule on a single
> # line,and change only the value of the NAME= key.
> # PCI device 0x8086:0x4220 (ipw2200)
> # PCI device 0x14e4:0x170c (b44)
> # USB device 0x2001:0x3301 (usb)
> SUBSYSTEM==“net”, ACTION==“add”, DRIVERS=="?",
> ATTR{address}==“00:12:f0:2a:b6:bb”, ATTR{type}==“1”, KERNEL=="eth
",
> NAME=“eth
> 0”

Change “eth0” to “wlan1”.

> SUBSYSTEM==“net”, ACTION==“add”, DRIVERS=="?",
> ATTR{address}==“00:11:43:74:8b:35”, ATTR{type}==“1”, KERNEL=="eth
",
> NAME=“eth
> 1”

Change “eth1” to “eth0”.

> SUBSYSTEM==“net”, ACTION==“add”, DRIVERS=="?",
> ATTR{address}==“00:e0:4c:81:92:00”, ATTR{type}==“1”, KERNEL=="wlan
",
> NAME=“wl
> an0”

OK as is.

> The drivers/modules associated with the various devices are:
>
> eth0: ipw2200
> eth1: b44
> wlan0: r8192s_usb
>
> Why would I be blacklisting the one for wlan0? If you are referring to
> my ultimate goal to only use the dongle for wireless communication, then
> shouldn’t I blacklist the driver for eth0, namely ipw2200?

Yes - I got confused and thought that wlan0 was the extra one.

With the changes in the udev rules outlined above, you will have the
following names:

eth0: b44
wlan0: r8192s_usb
wlan1: ipw2200

If you the blacklist ipw2200, wlan1 will disappear.

We will first setup the connection with ifup. Using YaST => Network
Devices => Network Settings, set the b44 device to be activated “On
Cable Connection” and the r8192 to be activated “At boot time”. Also set
the ESSID and any encryption on the appropriate page. Now with “sudo
/sbin/ifup wlan0”, the connection should be made. At the least, you
should be able to scan with the device.

The real stickler in this whole matter is that this driver is from
staging, where the quality is unknown. The driver for RTL8187SE, also
from staging, is extremely stable - it will go for days without dropping
the connection, but other staging drivers are really bad.

If you cannot make a connection now, please disconnect the wired
connection run the commands below, and post the output.

sudo /usr/sbin/iwlist wlan0 scan
/usr/sbin/iwconfig
/sbin/ifconfig

Stranger and stranger! The blacklist initially works, but an invocation of YaST seems to circumvent it. No wlan0 connection is made. The relevant command line outputs are:

Start with a check of the rules files. rules-new is the new assignments, and I copy rules_new to rules

siracusa:/etc/udev/rules.d # ls -l 70net
-rw-r–r-- 1 root root 1068 Apr 28 20:00 70-persistent-net.rules
-rw-r–r-- 1 root root 1068 Apr 28 19:58 70-persistent-net.rules_new
-rw-r–r-- 1 root root 1066 Apr 28 07:36 70-persistent-net.rules_orig

Now reboot, and check the rules files again, no change

siracusa:/etc/udev/rules.d # ls -l 70net
-rw-r–r-- 1 root root 1068 Apr 28 20:00 70-persistent-net.rules
-rw-r–r-- 1 root root 1068 Apr 28 19:58 70-persistent-net.rules_new
-rw-r–r-- 1 root root 1066 Apr 28 07:36 70-persistent-net.rules_orig

Check to see if the blacklist worked, it apparently did

siracusa:/etc/udev/rules.d # lsmod | grep ipw
siracusa:/etc/udev/rules.d #

siracusa:/etc/sysconfig/network # ls
config if-down.d ifcfg-eth0 ifcfg-wlan0 ifroute-lo scripts
dhcp if-up.d ifcfg-lo ifcfg.template providers

Now invoke YaST > Network Devices > Network Settings, it shows in the top
window of the Overview tab:

802.11n WLAN Adapter DHCP
BCM4401-B0 100Bae-TX DHCP
Pro/Wireless 2200BG[Calexico2]Network Connection Not configured

Get out of YaST by Cancel, not OK

Confirm that the router is set to 802.11n only

But wait! 70-persistent-net.rules has been modified

siracusa:/etc/udev/rules.d # ls -l 70net
-rw-r–r-- 1 root root 1235 Apr 28 20:11 70-persistent-net.rules
-rw-r–r-- 1 root root 1068 Apr 28 19:58 70-persistent-net.rules_new
-rw-r–r-- 1 root root 1066 Apr 28 07:36 70-persistent-net.rules_orig

and contains a new entry for the built-in wireless as eth1:

PCI device 0x8086:0x4220 (ipw2200)

SUBSYSTEM==“net”, ACTION==“add”, DRIVERS=="?", ATTR{address}==“00:12:f0:2a:b6:bb”, ATTR{type}==“1”, KERNEL=="eth", NAME=“eth1”

and the ipw2200 kernel modules have been loaded, despite the blacklist

siracusa:/etc/udev/rules.d # lsmod | grep ipw
ipw2200 193900 0
libipw 46384 1 ipw2200

but no new configuration file has appeared

siracusa:/etc/sysconfig/network # ls
config if-down.d ifcfg-eth0 ifcfg-wlan0 ifroute-lo scripts
dhcp if-up.d ifcfg-lo ifcfg.template providers

Now try to connect on wlan0

siracusa:/etc/udev/rules.d # ifup wlan0
wlan0 name: 802.11n WLAN Adapter
wlan0 warning: using NO encryption
command ‘iwconfig wlan0 key off’ returned
Error for wireless request “Set Encode” (8B2A) :
SET failed on device wlan0 ; Network is down.
RTNETLINK answers: Resource temporarily unavailable
Starting DHCP4 client on wlan0.
wlan0 DHCP4 client NOT running
RTNETLINK answers: Resource temporarily unavailable
Cannot enable interface wlan0.
interface wlan0 is not up

So disconnect the wired connection and run

siracusa:/etc/udev/rules.d # iwlist wlan0 scan
wlan0 Interface doesn’t support scanning : Network is down

siracusa:/etc/udev/rules.d # iwconfig
lo no wireless extensions.

wlan0 802.11b/g Mode:Managed Access Point: Invalid
Bit Rate=0 kb/s
Retry min limit:7 RTS thr:off Fragment thr:off
Encryption key:off
Power Management:off
Link Quality=0/100 Signal level=0 dBm Noise level=0 dBm
Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0
Tx excessive retries:0 Invalid misc:0 Missed beacon:0

eth0 no wireless extensions.

eth1 unassociated ESSID:off/any
Mode:Managed Channel=0 Access Point: Not-Associated
Bit Rate:0 kb/s Tx-Power=20 dBm Sensitivity=8/0
Retry limit:7 RTS thr:off Fragment thr:off
Encryption key:off
Power Management:off
Link Quality:0 Signal level:0 Noise level:0
Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0
Tx excessive retries:0 Invalid misc:0 Missed beacon:0

siracusa:/etc/udev/rules.d # ifconfig
eth0 Link encap:Ethernet HWaddr 00:11:43:74:8B:35
UP BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:973 errors:0 dropped:0 overruns:0 frame:0
TX packets:884 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:579259 (565.6 Kb) TX bytes:186790 (182.4 Kb)
Interrupt:18

eth1 Link encap:Ethernet HWaddr 00:12:F0:2A:B6:BB
inet6 addr: fe80::212:f0ff:fe2a:b6bb/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:6 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 b) TX bytes:432 (432.0 b)
Interrupt:17 Base address:0xc000 Memory:dfcfd000-dfcfdfff

lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:88 errors:0 dropped:0 overruns:0 frame:0
TX packets:88 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:5808 (5.6 Kb) TX bytes:5808 (5.6 Kb)

On 04/28/2010 11:06 PM, lrkeefe wrote:
>
> Stranger and stranger! The blacklist initially works, but an invocation
> of YaST seems to circumvent it. No wlan0 connection is made. The
> relevant command line outputs are:
>
> Start with a check of the rules files. rules-new is the new
> assignments, and I copy rules_new to rules
>
> siracusa:/etc/udev/rules.d # ls -l 70net
> -rw-r–r-- 1 root root 1068 Apr 28 20:00 70-persistent-net.rules
> -rw-r–r-- 1 root root 1068 Apr 28 19:58 70-persistent-net.rules_new
> -rw-r–r-- 1 root root 1066 Apr 28 07:36 70-persistent-net.rules_orig
>
> Now reboot, and check the rules files again, no change
>
> siracusa:/etc/udev/rules.d # ls -l 70net
> -rw-r–r-- 1 root root 1068 Apr 28 20:00 70-persistent-net.rules
> -rw-r–r-- 1 root root 1068 Apr 28 19:58 70-persistent-net.rules_new
> -rw-r–r-- 1 root root 1066 Apr 28 07:36 70-persistent-net.rules_orig
>
> Check to see if the blacklist worked, it apparently did
>
> siracusa:/etc/udev/rules.d # lsmod | grep ipw
> siracusa:/etc/udev/rules.d #
>
> siracusa:/etc/sysconfig/network # ls
> config if-down.d ifcfg-eth0 ifcfg-wlan0 ifroute-lo scripts
> dhcp if-up.d ifcfg-lo ifcfg.template providers
>
>
> Now invoke YaST > Network Devices > Network Settings, it shows in the
> top
> window of the Overview tab:
>
> 802.11n WLAN Adapter DHCP
> BCM4401-B0 100Bae-TX DHCP
> Pro/Wireless 2200BG[Calexico2]Network Connection Not configured

Delete that last connection and exit normally.

> Get out of YaST by Cancel, not OK
>
> Confirm that the router is set to 802.11n only
>
> But wait! 70-persistent-net.rules has been modified
>
> siracusa:/etc/udev/rules.d # ls -l 70net
> -rw-r–r-- 1 root root 1235 Apr 28 20:11 70-persistent-net.rules
> -rw-r–r-- 1 root root 1068 Apr 28 19:58 70-persistent-net.rules_new
> -rw-r–r-- 1 root root 1066 Apr 28 07:36 70-persistent-net.rules_orig
>
> and contains a new entry for the built-in wireless as eth1:
>
> # PCI device 0x8086:0x4220 (ipw2200)
> SUBSYSTEM==“net”, ACTION==“add”, DRIVERS=="?",
> ATTR{address}==“00:12:f0:2a:b6:bb”, ATTR{type}==“1”, KERNEL=="eth
",
> NAME=“eth1”
>
> and the ipw2200 kernel modules have been loaded, despite the blacklist

Yes. Because you allowed YaST to keep the definition for the ipw2200, it
loaded the module.

> siracusa:/etc/udev/rules.d # lsmod | grep ipw
> ipw2200 193900 0
> libipw 46384 1 ipw2200
>
> but no new configuration file has appeared

It won’t unless you create it by configuring the interface!
>
> siracusa:/etc/sysconfig/network # ls
> config if-down.d ifcfg-eth0 ifcfg-wlan0 ifroute-lo scripts
> dhcp if-up.d ifcfg-lo ifcfg.template providers
>
> Now try to connect on wlan0
>
> siracusa:/etc/udev/rules.d # ifup wlan0
> wlan0 name: 802.11n WLAN Adapter
> wlan0 warning: using NO encryption
> command ‘iwconfig wlan0 key off’ returned
> Error for wireless request “Set Encode” (8B2A) :
> SET failed on device wlan0 ; Network is down.
> RTNETLINK answers: Resource temporarily unavailable
> Starting DHCP4 client on wlan0.
> wlan0 DHCP4 client NOT running
> RTNETLINK answers: Resource temporarily unavailable
> Cannot enable interface wlan0.
> interface wlan0 is not up

I think you put the firmware in the wrong place. It usually belongs in
/lib/firmware or in a subdirectory of it, thus it should be in
/lib/firmware/RTL8192SU/rtl8192sfw.bin. I verified that by looking at
the driver source. To confirm this, look at the output of

dmesg | grep firmware

You will probably see a message “request firmware fail!”. That is a
direct copy from the driver source. As a general rule, whenever anything
is wrong, always look at the output of dmesg. To control the rate that
the stuff scrolls, pipe it to less, i.e. ‘dmesg | less’. Whenever you
type a space, you will get a new page. The up/down arrow keys move
through the text, q exits, home takes you to the top, and end to the bottom.

The rest of your stuff is irrelevant. Whatever is wrong is keeping wlan0
from coming up.

You can ignore the udev rules problem. It will not affect anything. The
ipw2200 driver is really old, thus it does not conform to current kernel
practices. At least, now your wired connection is eth0.

Sorry about the irrelevant output. Two points:

  1. My first post was in error in that I showed the firmware installed in /lib/RTL8192SU. It is, in fact, correctly installed as /lib/firmware/RTL8192SU/rtl8192sfw.bin. The dmesg | grep firmware output right after boot shows that it is being correctly located and there is no failure.

  2. When I am in the Overview tab of YaST > Network Devices > Network Settings, the Delete button is grayed out when the ipw2200 internal wireless device is selected. Is there some other way to delete this item? In the past, when this device was configured, the use of the Delete button did not delete the entry, it just marked it as Not Configured. Once in the Not Configured state, the Delete button is inoperative.

So if we assume the rules issue is irrelevant (but see below) and the firmware is in the correct place, I copied the correct rules file again, re-booted, and immediately executed ifup wlan0. The output is the same as before:

siracusa:/etc/udev/rules.d # ifup wlan0
wlan0 name: 802.11n WLAN Adapter
wlan0 warning: using NO encryption
command ‘iwconfig wlan0 key off’ returned
Error for wireless request “Set Encode” (8B2A) :
SET failed on device wlan0 ; Network is down.
RTNETLINK answers: Resource temporarily unavailable
Starting DHCP4 client on wlan0.
wlan0 DHCP4 client NOT running
RTNETLINK answers: Resource temporarily unavailable
Cannot enable interface wlan0.
interface wlan0 is not up

and similarly for the other commands you suggested in the previous post.

With regards to the rules file, there may or may not still be an issue, if you continue to think there were naming conflicts in my original setup. The problem is this: any invocation of YaST > Network Devices > Network Settings causes the rules file to be rewritten twice. The simple act of getting to the Network Settings window causes the first rewrite, which is preserved if you Exit by Cancel. This is the file with the extra entry for the internal wireless as eth1, mentioned before in my verbose post. However, if you exit Network Settings with OK, the rules file is rewritten again, and this time the result corresponds to the original naming conventions, namely the internal wireless as eth0, the internal ethernet card as eth1, and the dongle as wlan0. So is this still an issue?

On 04/29/2010 01:46 PM, lrkeefe wrote:
>
> Sorry about the irrelevant output. Two points:
>
> 1. My first post was in error in that I showed the firmware installed
> in /lib/RTL8192SU. It is, in fact, correctly installed as
> /lib/firmware/RTL8192SU/rtl8192sfw.bin. The dmesg | grep firmware
> output right after boot shows that it is being correctly located and
> there is no failure.
>
> 2. When I am in the Overview tab of YaST > Network Devices > Network
> Settings, the Delete button is grayed out when the ipw2200 internal
> wireless device is selected. Is there some other way to delete this
> item? In the past, when this device was configured, the use of the
> Delete button did not delete the entry, it just marked it as Not
> Configured. Once in the Not Configured state, the Delete button is
> inoperative.

OK. You can ignore it.

> So if we assume the rules issue is irrelevant (but see below) and the
> firmware is in the correct place, I copied the correct rules file again,
> re-booted, and immediately executed ifup wlan0. The output is the same
> as before:
>
> siracusa:/etc/udev/rules.d # ifup wlan0
> wlan0 name: 802.11n WLAN Adapter
> wlan0 warning: using NO encryption
> command ‘iwconfig wlan0 key off’ returned
> Error for wireless request “Set Encode” (8B2A) :
> SET failed on device wlan0 ; Network is down.
> RTNETLINK answers: Resource temporarily unavailable
> Starting DHCP4 client on wlan0.
> wlan0 DHCP4 client NOT running
> RTNETLINK answers: Resource temporarily unavailable
> Cannot enable interface wlan0.
> interface wlan0 is not up

Had you done an ifup prior to the scan? If so, then there is still
something wrong. Check dmesg to see what it is.

> and similarly for the other commands you suggested in the previous
> post.
>
> With regards to the rules file, there may or may not still be an issue,
> if you continue to think there were naming conflicts in my original
> setup. The problem is this: any invocation of YaST > Network Devices >
> Network Settings causes the rules file to be rewritten twice. The
> simple act of getting to the Network Settings window causes the first
> rewrite, which is preserved if you Exit by Cancel. This is the file
> with the extra entry for the internal wireless as eth1, mentioned before
> in my verbose post. However, if you exit Network Settings with OK, the
> rules file is rewritten again, and this time the result corresponds to
> the original naming conventions, namely the internal wireless as eth0,
> the internal ethernet card as eth1, and the dongle as wlan0. So is this
> still an issue?

In the previous post, I said to ignore this. I does not matter.

If nothing shows up in dmesg, then I would conclude that the driver does
not work. You might try compat-wireless to get the latest version.

So now we finally reach the point where I get to confess having done something stupid or careless. It seems grep does not ignore case by default, and so my dmesg | grep firmware sequence did not capture all the relevant information. The firmware load is a failure, but I have no idea what the errors mean. The appropriate dmesg lines (repeated several times) are

27.572809] rtl819xU: —>FirmwareDownload92S()
27.572816]
27.572829] usb 1-5: firmware: requesting RTL8192SU/rtl8192sfw.bin
27.588658] rtl819xU:signature:8192, version:902b, size:30, imemsize:7408, sram size:9688
27.588662]
27.588720] rtl819xU:—>FirmwareDownloadCode()
27.588721]
27.588767] rtl819xU:—>FirmwareCheckReady(): LoadStaus(1),
27.873173] rtl819xU:FW_STATUS_LOAD_IMEM FAIL CPU, Status=44
27.873177]
27.873182] rtl819xU:FirmwareDownloadCode() fail !
27.873183]
27.873411] rtl819xU:Firmware Download Fail!!4544
27.873413]
27.888300] rtl819xU: —>FirmwareDownload92S()
27.888305]
27.888310] rtl819xU:—>FirmwareDownloadCode()
27.888312]
27.888363] rtl819xU:—>FirmwareCheckReady(): LoadStaus(1),
28.166313] rtl819xU:FW_STATUS_LOAD_IMEM FAIL CPU, Status=44
28.166320]
28.166328] rtl819xU:FirmwareDownloadCode() fail !
28.166333]
28.166555] rtl819xU:Firmware Download Fail!!4544
28.166560]
28.166568] rtl819xU:ERR!!! _rtl8192_up(): initialization is failed!

On 04/29/2010 05:16 PM, lrkeefe wrote:
>
> So now we finally reach the point where I get to confess having done
> something stupid or careless. It seems grep does not ignore case by
> default, and so my dmesg | grep firmware sequence did not capture all
> the relevant information. The firmware load is a failure, but I have no
> idea what the errors mean. The appropriate dmesg lines (repeated
> several times) are
>
> 27.572809] rtl819xU: —>FirmwareDownload92S()
> 27.572816]
> 27.572829] usb 1-5: firmware: requesting RTL8192SU/rtl8192sfw.bin
> 27.588658] rtl819xU:signature:8192, version:902b, size:30,
> imemsize:7408, sram size:9688
> 27.588662]
> 27.588720] rtl819xU:—>FirmwareDownloadCode()
> 27.588721]
> 27.588767] rtl819xU:—>FirmwareCheckReady(): LoadStaus(1),
> 27.873173] rtl819xU:FW_STATUS_LOAD_IMEM FAIL CPU, Status=44
> 27.873177]
> 27.873182] rtl819xU:FirmwareDownloadCode() fail !
> 27.873183]
> 27.873411] rtl819xU:Firmware Download Fail!!4544
> 27.873413]
> 27.888300] rtl819xU: —>FirmwareDownload92S()
> 27.888305]
> 27.888310] rtl819xU:—>FirmwareDownloadCode()
> 27.888312]
> 27.888363] rtl819xU:—>FirmwareCheckReady(): LoadStaus(1),
> 28.166313] rtl819xU:FW_STATUS_LOAD_IMEM FAIL CPU, Status=44
> 28.166320]
> 28.166328] rtl819xU:FirmwareDownloadCode() fail !
> 28.166333]
> 28.166555] rtl819xU:Firmware Download Fail!!4544
> 28.166560]
> 28.166568] rtl819xU:ERR!!! _rtl8192_up(): initialization is failed!

Repeat after me: Linux is case sensitive. Linux cares about case. When
using Linux, be careful about case.

The only part of Linux that is not case sensitive is less. If you enter
‘dmesg | less’ and then search by typing “/firmware”, it will find the
word without regard to case. Go figure.

You can also use the -i switch for grep to turn off case sensitivity.

In their infinite wisdom ;-), Realtek has two drivers that respond to
the 2001:3301 USB Id - r8192s_usb and r8192u_usb. I believe you are
using r8192s_usb. Use ‘lsmod | grep 8192’ to find out. Then do the
following:

sudo /sbin/modprobe -rv r8192s_usb
sudo /sbin/modprobe -v r8192u_usb

If I got it wrong, flip the names. You will now be trying the other.

The code seems to indicate that this device uses 3 firmware files in
/lib/firmware/RTL8192U/: boot.img, main.img, and data.img. I do not know
where to find these files.

Again check dmesg output for firmware messages.

Remember the warning in dmesg about using staging drivers. FYI, the
price was something I could afford, and I just bought one of these
DWA-130 USB devices on E-bay. Perhaps we can get the driver situation
squared away. One of my daughters has an 11n router and I will visit her
in roughly 10 days.

Yes, I am using r8192s_usb, but once I remove this module with the first modprobe, the second modprobe produces:

siracusa:/etc/udev/rules.d # modprobe -v r8192u_usb
FATAL: Module r8192u_usb not found.

so it looks like there aren’t many options unless I can track down the other module. Suggestions for sources? I gather from a Google on the name that it is supposed to be part of the staging directory, but somehow seems to be missing in this case. rpmfind doesn’t seem to have any versions.

With regards to the *.img files that are sought, is the rtl8192sfw.bin file some sort of a small archive, and these are each supposed to be components?

You must be a glutton for punishment if you bought one of these dongles given the difficulties I am having. I did try it out under Windows and it does work, although the transfer rates with 802.11n operation right next to the router have never gotten over 60 MBps. But I guess that means the router is only operating on 802.11n, since isn’t 54 MBps the max for 802.11g? One of the curiousities of the particular one I have is that the listed MAC address on the exterior label does not match that found by YaST (and Windows for that matter).

On 04/29/2010 10:46 PM, lrkeefe wrote:
>
> Yes, I am using r8192s_usb, but once I remove this module with the first
> modprobe, the second modprobe produces:
>
> siracusa:/etc/udev/rules.d # modprobe -v r8192u_usb
> FATAL: Module r8192u_usb not found.

I see now that r8192u_usb is not part os 2.6.31.12-0-2.

> so it looks like there aren’t many options unless I can track down the
> other module. Suggestions for sources? I gather from a Google on the
> name that it is supposed to be part of the staging directory, but
> somehow seems to be missing in this case. rpmfind doesn’t seem to have
> any versions.

The only other option would be to get the 2.6.34-rc5 kernel from
Factory. You should download the RPM rather than using YaST to install
the new kernel. If you then do

sudo rpm -iv <RPM Name>

the system will install the new kernel in addition to the old one. You
will get new items in the GRUB menu. This kernel has both the r8192s_usb
and r8192u_usb variants.

> With regards to the *.img files that are sought, is the rtl8192sfw.bin
> file some sort of a small archive, and these are each supposed to be
> components?

The firmware loading mechanism is not that smart.

> You must be a glutton for punishment if you bought one of these dongles
> given the difficulties I am having. I did try it out under Windows and
> it does work, although the transfer rates with 802.11n operation right
> next to the router have never gotten over 60 MBps. But I guess that
> means the router is only operating on 802.11n, since isn’t 54 MBps the
> max for 802.11g? One of the curiousities of the particular one I have
> is that the listed MAC address on the exterior label does not match that
> found by YaST (and Windows for that matter).

With 802.11g, the fastest transfer would be ~ 0.5 the bit rate or 26
Mb/s. If you are getting 60, then 11n is certainly active.

My plan is to add an 802.11n dual-band router so that I can add 5 GHz
capability to my system, which is one of the reasons for getting the 11n
device. My wireless device collection is getting fairly large as I
already have 2 Broadcom Cardbus, 2 Broadcom PCI, 3 Broadcom mini-PCIe, 1
Realtek mini-PCIe, 2 Realtek USB, and 1 Dell DW1450 USB. All of the
above are 802.11 b/g except for one 802.11b and 1 802.11a/b/g. There are
mainline drivers for all but one of the Broadcom mini-PCIe and the
Realtek mini-PCIe devices, and both of those are being developed. Adding
a mainline driver for the rtl8192 USB device would be useful for the
community.

Ok, I am willing to be a little bit of a guinea pig. When you say “Factory” as a kernel source, where precisely do you mean? kernel.org? I see 2.6.34-rc5-git10 and 2.6.34-rc6 there, but don’t seem to be in a place to download an rpm.

On 04/30/2010 11:56 AM, lrkeefe wrote:
>
> Ok, I am willing to be a little bit of a guinea pig. When you say
> “Factory” as a kernel source, where precisely do you mean? kernel.org?
> I see 2.6.34-rc5-git10 and 2.6.34-rc6 there, but don’t seem to be in a
> place to download an rpm.

The kernel.org things are the sources - you would have to build from
scratch. There are never any rpm’s there.

The factory kernel is available from

http://download.opensuse.org/factory/repo/oss/suse/i586/kernel-default-2.6.34-6.1.i586.rpm

or

http://download.opensuse.org/factory/repo/oss/suse/x86_64/kernel-default-2.6.34-6.1.x86_64.rpm

depending on your architecture.

Side note:

The driver itself could be backported easily from 2.6.34-rc6 to 2.6.31.

make -C /lib/modules/$(uname -r)/build SUBDIRS=$(pwd) modules
make: Entering directory `/usr/src/linux-2.6.31.12-0.2-obj/x86_64/desktop'
make -C ../../../linux-2.6.31.12-0.2 O=/usr/src/linux-2.6.31.12-0.2-obj/x86_64/desktop/. modules
  CC [M]  /tmp/linux-2.6-d476f60/r8192U_core.o
  CC [M]  /tmp/linux-2.6-d476f60/r8180_93cx6.o
  CC [M]  /tmp/linux-2.6-d476f60/r8192U_wx.o
  CC [M]  /tmp/linux-2.6-d476f60/r8190_rtl8256.o
  CC [M]  /tmp/linux-2.6-d476f60/r819xU_phy.o
  CC [M]  /tmp/linux-2.6-d476f60/r819xU_firmware.o
  CC [M]  /tmp/linux-2.6-d476f60/r819xU_cmdpkt.o
  CC [M]  /tmp/linux-2.6-d476f60/r8192U_dm.o
  CC [M]  /tmp/linux-2.6-d476f60/r819xU_firmware_img.o
  CC [M]  /tmp/linux-2.6-d476f60/ieee80211/ieee80211_crypt.o
  CC [M]  /tmp/linux-2.6-d476f60/ieee80211/ieee80211_crypt_tkip.o
  CC [M]  /tmp/linux-2.6-d476f60/ieee80211/ieee80211_crypt_ccmp.o
  CC [M]  /tmp/linux-2.6-d476f60/ieee80211/ieee80211_crypt_wep.o
  CC [M]  /tmp/linux-2.6-d476f60/ieee80211/ieee80211_rx.o
  CC [M]  /tmp/linux-2.6-d476f60/ieee80211/ieee80211_softmac.o
  CC [M]  /tmp/linux-2.6-d476f60/ieee80211/ieee80211_tx.o
  CC [M]  /tmp/linux-2.6-d476f60/ieee80211/ieee80211_wx.o
  CC [M]  /tmp/linux-2.6-d476f60/ieee80211/ieee80211_module.o
  CC [M]  /tmp/linux-2.6-d476f60/ieee80211/ieee80211_softmac_wx.o
  CC [M]  /tmp/linux-2.6-d476f60/ieee80211/rtl819x_HTProc.o
  CC [M]  /tmp/linux-2.6-d476f60/ieee80211/rtl819x_TSProc.o
  CC [M]  /tmp/linux-2.6-d476f60/ieee80211/rtl819x_BAProc.o
  CC [M]  /tmp/linux-2.6-d476f60/ieee80211/dot11d.o
  LD [M]  /tmp/linux-2.6-d476f60/r8192u_usb.o
  Building modules, stage 2.
  MODPOST 1 modules
  CC      /tmp/linux-2.6-d476f60/r8192u_usb.mod.o
  LD [M]  /tmp/linux-2.6-d476f60/r8192u_usb.ko
make: Leaving directory `/usr/src/linux-2.6.31.12-0.2-obj/x86_64/desktop'

Not even patching is needed, except in the Makefile one has to set “obj-m += r8192u_usb.o” instead of “-obj-$(CONFIG_RTL8192U) += r8192u_usb.o”.