Red Hat Bugzilla – Bug 828824
USB Wi-Fi dongle not working as access point
Last modified: 2012-07-19 05:05:42 EDT
Description of problem:
In fedora 16 this was mostly working (with occasional need to stop everything
and plug it back in and restart). On fedora 17 I can't get it to work at all.
My phone believes that it has a Wi-Fi connection, and does indeed talk to the
DHCP server to get assigned an address, but after that, no network traffic
flows. I can't ever talk directly to the gateway, must less route traffic to
the internet at large. Here's the relevant dmesg info from plugging in the
dongle and starting hostapd and dhcpd:
[ 472.348027] usb 1-4: new high-speed USB device number 4 using ehci_hcd
[ 472.635893] usb 1-4: New USB device found, idVendor=050d, idProduct=705a
[ 472.635900] usb 1-4: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[ 472.635905] usb 1-4: Product: Belkin 54g USB Network Adapter
[ 472.635909] usb 1-4: Manufacturer: Belkin
[ 472.763474] cfg80211: Calling CRDA to update world regulatory domain
[ 472.833891] cfg80211: World regulatory domain updated:
[ 472.833895] cfg80211: (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp)
[ 472.833899] cfg80211: (2402000 KHz - 2472000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
[ 472.833902] cfg80211: (2457000 KHz - 2482000 KHz @ 20000 KHz), (300 mBi, 2000 mBm)
[ 472.833905] cfg80211: (2474000 KHz - 2494000 KHz @ 20000 KHz), (300 mBi, 2000 mBm)
[ 472.833908] cfg80211: (5170000 KHz - 5250000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
[ 472.833912] cfg80211: (5735000 KHz - 5835000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
[ 472.898039] usb 1-4: reset high-speed USB device number 4 using ehci_hcd
[ 473.363182] ieee80211 phy0: Selected rate control algorithm 'minstrel_ht'
[ 473.363632] Registered led device: rt73usb-phy0::radio
[ 473.363679] Registered led device: rt73usb-phy0::assoc
[ 473.363719] Registered led device: rt73usb-phy0::quality
[ 473.364364] usbcore: registered new interface driver rt73usb
[ 473.445811] cfg80211: Calling CRDA for country: US
[ 473.449064] cfg80211: Regulatory domain changed to country: US
[ 473.449068] cfg80211: (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp)
[ 473.449072] cfg80211: (2402000 KHz - 2472000 KHz @ 40000 KHz), (300 mBi, 2700 mBm)
[ 473.449075] cfg80211: (5170000 KHz - 5250000 KHz @ 40000 KHz), (300 mBi, 1700 mBm)
[ 473.449079] cfg80211: (5250000 KHz - 5330000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
[ 473.449082] cfg80211: (5490000 KHz - 5600000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
[ 473.449085] cfg80211: (5650000 KHz - 5710000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
[ 473.449088] cfg80211: (5735000 KHz - 5835000 KHz @ 40000 KHz), (300 mBi, 3000 mBm)
[ 480.415725] ADDRCONF(NETDEV_UP): wlan0: link is not ready
[ 481.526136] nf_conntrack version 0.5.0 (16384 buckets, 65536 max)
[ 493.730012] wlan0: no IPv6 routers present
[ 676.146785] usb 1-4: USB disconnect, device number 4
[ 682.520027] usb 1-4: new high-speed USB device number 5 using ehci_hcd
[ 682.807948] usb 1-4: New USB device found, idVendor=050d, idProduct=705a
[ 682.807954] usb 1-4: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[ 682.807959] usb 1-4: Product: Belkin 54g USB Network Adapter
[ 682.807964] usb 1-4: Manufacturer: Belkin
[ 682.911039] usb 1-4: reset high-speed USB device number 5 using ehci_hcd
[ 683.357456] ieee80211 phy1: Selected rate control algorithm 'minstrel_ht'
[ 683.357880] Registered led device: rt73usb-phy1::radio
[ 683.357932] Registered led device: rt73usb-phy1::assoc
[ 683.357986] Registered led device: rt73usb-phy1::quality
[ 689.028629] ADDRCONF(NETDEV_UP): wlan0: link is not ready
[ 702.242026] wlan0: no IPv6 routers present
[ 718.610953] wlan0: moving STA 00:11:94:bd:4e:f5 to state 1
[ 718.610959] wlan0: moving STA 00:11:94:bd:4e:f5 to state 2
[ 718.642145] wlan0: moving STA 00:11:94:bd:4e:f5 to state 3
Version-Release number of selected component (if applicable):
Always acts the same - I apparently get a connection, DHCP assigns me an
IP, but nothing talks after that.
Steps to Reproduce:
1. see above
No network communication.
Talking on network.
This same dongle has worked then not worked then worked again in different
kernel releases. See bug 820211 and bug 716988. I suppose it is possible there
is some magic bean I neglected to properly plant in my fedora 17 installation
partition, but I can't think of any steps I left out setting up f17 (and I
keep pretty extensive notes telling me what I did last time).
Can you provide steps to reproduce (including relevant parts of hostap config) so I could investigate that locally ?
I just tried a few different kernels:
kernel-3.3.4-5.fc17.x86_64 - also does not work
On fedora 16 partition:
kernel-3.3.7-1.fc16.x86_64 - yet another failure
kernel-3.3.6-3.fc16.x86_64 - this one seemed to work
And it was working so well not too long ago :-).
Created attachment 589542 [details]
This is the shell script that starts everything. Note that I normally don't
start iptables at all, so the starting of iptabes in here is just to get the
NAT routing going.
Created attachment 589545 [details]
This is the hostapd.conf file with the passphrase changed.
Created attachment 589546 [details]
These are the NAT routing rules I get when I start iptables.
Created attachment 589547 [details]
Here is the DHCP server config.
Created attachment 589549 [details]
And finally, here is the /etc/sysconfig/dhcpd file with the argument
to DHCPD so it will only serve info over wlan0.
Hey! It isn't 100% failure. On about the 10th try, it actually connected and
is working. My phone can now get out to websites around the internet. So apparently instead of failing 10% of the time, it went to failing 90% of the time. I guess I just need to retry often enough and it will eventually work.
Created attachment 594182 [details]
Proposed patch for this problem - patch makes things work on my setup. Test kernel with patch is here:
please test it.
3.4.4-1.bz828824.fc17.x86_64 is looking good so far. I got a clean connection
the first time I tried after the initial boot, then disconnected everything
and tried connecting again, and the 2nd one worked perfectly as well. It has
been so random, I can't be absolute positive it is fixed, but it sure looks
better with the small sample size I have at the moment :-). Thanks!
And the next day, it continues to work perfectly first time, every time. I'm
beginning to believe this is indeed fixed for sure. The last time it connected
this many times in a row with no problems is a distant memory (maybe around f12
Created attachment 595753 [details]
Tom, previous patch is a bit buggy, it could possibly cause kernel crash. Please test this one
Just booted 3.4.4-3.bz828824_v2.fc17.x86_64 and the dongled connected
perfectly the first time I tried. Seems to work so far.
This morning I tried to connect again, and it took two attempts to work. Don't know if that means anything or not - two is still much better than it was.
Josh, please apply patch from comment 12 as fix for this bug, I just posted it upstream today http://marc.info/?l=linux-wireless&m=134140046608506&w=2
Thanks Stanislaw! In Fedora git for F16/F17/rawhide.
kernel-3.4.4-5.fc17 has been submitted as an update for Fedora 17.
kernel-3.4.4-4.fc16 has been submitted as an update for Fedora 16.
* should fix your issue,
* was pushed to the Fedora 16 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing kernel-3.4.4-4.fc16'
as soon as you are able to, then reboot.
Please go to the following url:
then log in and leave karma (feedback).
kernel-3.4.4-5.fc17 has been pushed to the Fedora 17 stable repository. If problems still persist, please make note of it in this bug report.
kernel-3.4.4-4.fc16 has been pushed to the Fedora 16 stable repository. If problems still persist, please make note of it in this bug report.
I have been seeing packet loss using a rt2800usb device in managed mode since the first 3.4.4 kernels were distributed. This packet loss becomes total after a few minutes of pinging the network. The total package loss occurs without any change in the iwconfig output and without any postings to the syslogs.
I used the 3.3.7-1.rc17 kernel as a stop gap for a month before reverting to an ath5k device. There are no problems in either of these cases.
Loading the rt2x00lib module into the 3.4.4-5.fc17 kernel using modprobe seems to make no difference providing the rt2800usb device is unplugged. However, the package loss returns when the rt2800lib module is loaded using modprobe (this also loads the crc_ccitt module). This recurrance of the packet loss occurs even when the rt2800usb device is unplugged and the ath5k device and interface are the only ones in use.
Since Stanislaw has made patches to these kernel modules and the symptoms resemble the ones reported under this bug, it seems sensible to raise the issue here.
Felix, please open separate bug report for this problem and provide needed information (steps to reproduce, hw info, etc ...).