Bug 831730 - Cannot get IP address using rtl8192cus wireless adapter.
Cannot get IP address using rtl8192cus wireless adapter.
Status: CLOSED INSUFFICIENT_DATA
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
17
i686 Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: John Greene
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-06-13 12:23 EDT by mumart
Modified: 2013-05-28 10:37 EDT (History)
8 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-05-28 10:37:02 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Trial patch for problem (2.29 KB, patch)
2012-06-14 21:42 EDT, Larry Finger
no flags Details | Diff

  None (edit)
Description mumart 2012-06-13 12:23:16 EDT
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
Comment 1 mumart 2012-06-14 10:34:57 EDT
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.
Comment 2 Larry Finger 2012-06-14 21:42:59 EDT
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.
Comment 3 mumart 2012-06-15 19:49:18 EDT
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).
Comment 4 Justin M. Forbes 2012-09-11 11:49:37 EDT
Is this still happening with 3.5.3 kernels in updates?
Comment 5 Larry Finger 2012-09-11 16:42:58 EDT
Regarding Comment #3, the driver also depends on "EXPERIMENTAL". That dependence should be removed.
Comment 6 mumart 2012-09-14 06:29:32 EDT
I did eventually figure out the CONFIG_EXPERIMENTAL dependency, thanks.

Unfortunately the problem remains with kernel 3.5.3-1.fc17.i686.
Comment 7 John Greene 2013-04-17 09:22:46 EDT
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.
Comment 8 mumart 2013-05-03 04:20:48 EDT
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.
Comment 9 John Greene 2013-05-03 09:19:54 EDT
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
Comment 10 John Greene 2013-05-03 09:34:45 EDT
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..
Comment 11 John Greene 2013-05-09 11:08:53 EDT
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..
Comment 12 Josh Boyer 2013-05-28 10:37:02 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.