Bug 828824 - USB Wi-Fi dongle not working as access point
USB Wi-Fi dongle not working as access point
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
17
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Stanislaw Gruszka
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-06-05 08:38 EDT by Tom Horsley
Modified: 2012-07-19 05:05 EDT (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-07-07 17:54:36 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)
/usr/local/bin/start-ap (205 bytes, text/plain)
2012-06-05 10:46 EDT, Tom Horsley
no flags Details
/etc/hostapd.conf (738 bytes, text/plain)
2012-06-05 10:47 EDT, Tom Horsley
no flags Details
/etc/sysconfig/iptables (444 bytes, text/plain)
2012-06-05 10:48 EDT, Tom Horsley
no flags Details
/etc/dhcp/dhcpd.conf (407 bytes, text/plain)
2012-06-05 10:49 EDT, Tom Horsley
no flags Details
/etc/sysconfig/dhcpd (44 bytes, text/plain)
2012-06-05 10:51 EDT, Tom Horsley
no flags Details
0001-rt2x00usb-do-not-check-STATUS_PENDING-bit-on-rx.patch (1.61 KB, text/plain)
2012-06-25 09:15 EDT, Stanislaw Gruszka
no flags Details
0001-rt2x00usb-fix-indexes-ordering-on-RX-queue-kick.patch (1.61 KB, text/plain)
2012-07-02 10:50 EDT, Stanislaw Gruszka
no flags Details

  None (edit)
Description Tom Horsley 2012-06-05 08:38:20 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):
kernel-3.3.7-1.fc17.x86_64


How reproducible:
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
  
Actual results:
No network communication.

Expected results:
Talking on network.

Additional info:
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).
Comment 1 Stanislaw Gruszka 2012-06-05 10:18:13 EDT
Can you provide steps to reproduce (including relevant parts of hostap config) so I could investigate that locally ?
Comment 2 Tom Horsley 2012-06-05 10:38:00 EDT
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 :-).
Comment 3 Tom Horsley 2012-06-05 10:46:14 EDT
Created attachment 589542 [details]
/usr/local/bin/start-ap

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.
Comment 4 Tom Horsley 2012-06-05 10:47:17 EDT
Created attachment 589545 [details]
/etc/hostapd.conf

This is the hostapd.conf file with the passphrase changed.
Comment 5 Tom Horsley 2012-06-05 10:48:13 EDT
Created attachment 589546 [details]
/etc/sysconfig/iptables

These are the NAT routing rules I get when I start iptables.
Comment 6 Tom Horsley 2012-06-05 10:49:09 EDT
Created attachment 589547 [details]
/etc/dhcp/dhcpd.conf

Here is the DHCP server config.
Comment 7 Tom Horsley 2012-06-05 10:51:24 EDT
Created attachment 589549 [details]
/etc/sysconfig/dhcpd

And finally, here is the /etc/sysconfig/dhcpd file with the argument
to DHCPD so it will only serve info over wlan0.
Comment 8 Tom Horsley 2012-06-05 13:34:49 EDT
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.
Comment 9 Stanislaw Gruszka 2012-06-25 09:15:06 EDT
Created attachment 594182 [details]
0001-rt2x00usb-do-not-check-STATUS_PENDING-bit-on-rx.patch

Proposed patch for this problem - patch makes things work on my setup. Test kernel with patch is here:

http://koji.fedoraproject.org/koji/taskinfo?taskID=4193085

please test it.
Comment 10 Tom Horsley 2012-06-25 12:43:23 EDT
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!
Comment 11 Tom Horsley 2012-06-26 07:19:06 EDT
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
or f13?).
Comment 12 Stanislaw Gruszka 2012-07-02 10:50:40 EDT
Created attachment 595753 [details]
0001-rt2x00usb-fix-indexes-ordering-on-RX-queue-kick.patch

Tom, previous patch is a bit buggy, it could possibly cause kernel crash. Please test this one
http://koji.fedoraproject.org/koji/taskinfo?taskID=4212293
Comment 13 Tom Horsley 2012-07-02 15:15:37 EDT
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.
Comment 14 Tom Horsley 2012-07-03 07:21:02 EDT
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.
Comment 15 Stanislaw Gruszka 2012-07-04 07:27:41 EDT
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
Comment 16 Josh Boyer 2012-07-04 11:35:05 EDT
Thanks Stanislaw!  In Fedora git for F16/F17/rawhide.
Comment 17 Fedora Update System 2012-07-05 17:56:01 EDT
kernel-3.4.4-5.fc17 has been submitted as an update for Fedora 17.
https://admin.fedoraproject.org/updates/kernel-3.4.4-5.fc17
Comment 18 Fedora Update System 2012-07-05 19:50:18 EDT
kernel-3.4.4-4.fc16 has been submitted as an update for Fedora 16.
https://admin.fedoraproject.org/updates/kernel-3.4.4-4.fc16
Comment 19 Fedora Update System 2012-07-06 17:23:47 EDT
Package kernel-3.4.4-4.fc16:
* 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:
https://admin.fedoraproject.org/updates/FEDORA-2012-10319/kernel-3.4.4-4.fc16
then log in and leave karma (feedback).
Comment 20 Fedora Update System 2012-07-07 17:54:36 EDT
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.
Comment 21 Fedora Update System 2012-07-08 16:51:29 EDT
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.
Comment 22 Felix Bellaby 2012-07-18 20:03:12 EDT
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.
Comment 23 Stanislaw Gruszka 2012-07-19 05:05:42 EDT
Felix, please open separate bug report for this problem and provide needed information (steps to reproduce, hw info, etc ...).

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