Description of problem:
NetworkManager will not connect to a hidden wireless network (no encryption)
with the rt73usb driver. NM tries to set ap_scan=1, but ap_scan=2 may be
appropriate for this driver.
This could be in the vein of bug 373841 for F8, although rt73usb is mentioned
there as being ok.
Version-Release number of selected component (if applicable):
I disabled NetworkManager and used this simple wpa_supplicant.conf to connect to
the hidden wireless network "wahoo":
Varying ap_scan and scan_ssid leads to the following:
ap_scan=2, scan_ssid=1: associates, stable connection
ap_scan=2, scan_ssid=0: associates, then drops after a few seconds
ap_scan=1, scan_ssid=1: no association
ap_scan=1, scan_ssid=0: no association
The contents of /var/log/messages during a NM connection attempt has the
following lines (full log attached):
May 30 19:36:18 laptop NetworkManager: <info> Config: added 'scan_ssid' value '1'
May 30 19:36:18 laptop NetworkManager: <info> Config: set interface ap_scanto 1
Is NM overriding the ap_scan value from wpa_supplicant.conf?
Steps to Reproduce:
No wireless association.
Created attachment 307258 [details]
/var/log/messages during NM association
rt73usb should be using mac80211, and mac80211 drivers should be working fine
with ap_scan=1 + scan_ssid=1. If they are not, then the driver needs to be
fixed... This is the in-kernel rt73usb driver, right? Not the old rt2x00
driver from rt2x00.sf.net?
That's correct, I'm using the rt73usb that ships with the F9 kernel.
Does this mean that I should file a report upstream? (I'm not exactly sure
where upstream is in this case.)
Yes, if this is still a problem, we can transfer this report over to the kernel
since that's where the issue likely lies. But can you try the latest F9 kernel
update to see if that fixes the issue? It should be 184.108.40.206-76.fc9.
Still no luck with kernel-220.127.116.11-76.fc9.
John; issue is that rt73usb apparently doesn't like probe-scanning here; not
sure if there's an easy way to figure out if the device is actually sending out
the probe-request frames and receiving (and honoring) the probe-response frames.
But the fact that plain wpa_supplicant doesn't work with ap_scan=1 +
scan_ssid=1 is the clue here since I know other mac80211 drivers handle that
Does this issue remain with current kernels? I think I was just using this driver a few days ago and I don't recall a problem...
Closed due to lack of response...please reopen if the problem remains with current kernels.