I am unable to connect a USB wireless adapter (MicroNEXT MN-WD552B). A typical attempt to bring up the interface is shown below. Everything looks fine until I try to get an IP address. Using tcpdump I can see the DHCP packets getting out to the interface, and issuing the same set of commands using a non-rtl8192 adapter works fine on the same machine: # iwconfig wlan0 essid AP key <KEY> # ifconfig wlan0 up # iwconfig wlan0 wlan0 IEEE 802.11bgn ESSID:"AP" Mode:Managed Frequency:2.427 GHz Access Point: 00:11:F5:C1:26:45 Bit Rate=18 Mb/s Tx-Power=20 dBm Retry long limit:7 RTS thr=2347 B Fragment thr:off Encryption key:<KEY> Power Management:off Link Quality=70/70 Signal level=-36 dBm Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0 Tx excessive retries:0 Invalid misc:0 Missed beacon:0 # dhclient -v wlan0 Internet Systems Consortium DHCP Client 4.2.4rc1 Copyright 2004-2012 Internet Systems Consortium. All rights reserved. For info, please visit https://www.isc.org/software/dhcp/ Listening on LPF/wlan0/48:02:2a:92:f6:4b Sending on LPF/wlan0/48:02:2a:92:f6:4b Sending on Socket/fallback DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 8 (xid=0x2ccea697) DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 9 (xid=0x2ccea697) DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 8 (xid=0x2ccea697) DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 10 (xid=0x2ccea697) DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 10 (xid=0x2ccea697) DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 12 (xid=0x2ccea697) DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 4 (xid=0x2ccea697) No DHCPOFFERS received. No working leases in persistent database - sleeping. # dmesg [ 1281.736063] usb 1-2: new high-speed USB device number 4 using ehci_hcd [ 1281.787305] hub 1-0:1.0: unable to enumerate USB device on port 2 [ 1285.088151] usb 1-3: new high-speed USB device number 5 using ehci_hcd [ 1285.203822] usb 1-3: New USB device found, idVendor=0bda, idProduct=8176 [ 1285.203828] usb 1-3: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [ 1285.203834] usb 1-3: Product: 802.11n WLAN Adapter [ 1285.203838] usb 1-3: Manufacturer: Realtek [ 1285.203842] usb 1-3: SerialNumber: 00e04c000001 [ 1285.204682] rtl8192cu: Chip version 0x10 [ 1285.281579] rtl8192cu: MAC address: 48:02:2a:92:f6:4b [ 1285.281589] rtl8192cu: Board Type 0 [ 1285.281809] rtlwifi: rx_max_size 15360, rx_urb_num 8, in_ep 1 [ 1285.281934] rtl8192cu: Loading firmware rtlwifi/rtl8192cufw.bin [ 1285.303508] ieee80211 phy5: Selected rate control algorithm 'rtl_rc' [ 1285.304436] rtlwifi: wireless switch is on [ 1452.816793] rtl8192cu: MAC auto ON okay! [ 1452.860408] rtl8192cu: Tx queue select: 0x05 [ 1453.232013] ADDRCONF(NETDEV_UP): wlan0: link is not ready [ 1454.018231] wlan0: authenticate with 00:11:f5:c1:26:45 [ 1454.042711] wlan0: send auth to 00:11:f5:c1:26:45 (try 1/3) [ 1454.045891] wlan0: authenticated [ 1454.058036] wlan0: associate with 00:11:f5:c1:26:45 (try 1/3) [ 1454.061114] wlan0: RX AssocResp from 00:11:f5:c1:26:45 (capab=0x411 status=0 aid=1) [ 1454.061122] wlan0: associated [ 1454.062612] ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready [ 1464.770036] wlan0: no IPv6 routers present
Running tcpdump from another machine on the wireless network shows that no DHCP packets being are being broadcast from the rtl8192cus (I can see broadcasts from other devices). I have also tried avoiding broadcasts with "dhclient -v -s 192.168.1.1 wlan0" with no success. The same problem also occurs if I disable WEP on my router, and the device works fine in Windows.
Created attachment 591958 [details] Trial patch for problem It is possible for one section of the buffer assignment for USB reads to be racy. This proposed patch will avoid that difficulty. Please try it.
Applied to 3.4.0-1.fc17, but unfortunately the problem remains. PS: I tried to speed up the build by starting from an allnoconfig and enabling only the rtl8192cu module, but the module was not selectable even though all the dependencies listed in menuconfig were satisfied (NETDEVICES,WLAN,MAC80211,USB).
Is this still happening with 3.5.3 kernels in updates?
Regarding Comment #3, the driver also depends on "EXPERIMENTAL". That dependence should be removed.
I did eventually figure out the CONFIG_EXPERIMENTAL dependency, thanks. Unfortunately the problem remains with kernel 3.5.3-1.fc17.i686.
Is this issue still a problem? Can you try a 3.8 kernel? A lot of work in that area since 3.5 time frame that may help you.
Still does not work with kernel 3.8.8 on Fedora 17. There are some interesting looking patches for this driver in 3.9, however. I'll give it another try when the update comes through.
Yes, keep us posted. There are some recent fixes. Does this occur with just this AP or is it on a number of different ones? Can you post /var/log/wpa_supplicant.log? You might need to add the following to the supplicant startup cmd: -d or -dd increases debug output to logs if you could post the output of this also for the AP in question: iwlist wlan0 scanning This will help understand the security involved also. Thanks! -t timestamps
Oh couple more things. I'm working this device some now, will keep you posted on it. And the errand paste (-t timestamps) above will add timestamps to wpa_supplicant log, but isn't really necessary..
Did a quick look of stuff beyond 3.9 and I see a fair number of updates to this family and may be of help. Suggest you try 3.8.11 on this..Please post your results..
This bug is being closed with INSUFFICIENT_DATA as there has not been a response in 2 weeks. If you are still experiencing this issue, please reopen and attach the relevant data from the latest kernel you are running and any data that might have been requested previously.