Bug 449189

Summary: rt73usb needs ap_scan=2 to connect to hidden essid, NetworkManager sets ap_scan=1
Product: [Fedora] Fedora Reporter: AJ Bostian <a.bostian>
Component: kernelAssignee: John W. Linville <linville>
Status: CLOSED CURRENTRELEASE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: low Docs Contact:
Priority: low    
Version: 9CC: bnocera, dcbw, ivdoorn, wtogami
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2008-12-11 18:48:26 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Attachments:
Description Flags
/var/log/messages during NM association none

Description AJ Bostian 2008-05-31 00:21:02 UTC
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):
NetworkManager-0.7.0-0.9.3-svn3623.fc9
kernel-2.6.25.3-18.fc9


How reproducible:
I disabled NetworkManager and used this simple wpa_supplicant.conf to connect to
the hidden wireless network "wahoo":

ctrl_interface=/var/run/wpa_supplicant
ctrl_interface_group=wheel
ap_scan=2

network={
    ssid="wahoo"
    scan_ssid=1
    key_mgmt=NONE
    auth_alg=OPEN
}

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:
1.
2.
3.
  
Actual results:
No wireless association.

Expected results:
Wireless association.

Additional info:

Comment 1 AJ Bostian 2008-05-31 00:21:03 UTC
Created attachment 307258 [details]
/var/log/messages during NM association

Comment 2 Dan Williams 2008-06-02 21:00:31 UTC
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?

Comment 3 AJ Bostian 2008-06-02 22:53:02 UTC
That's correct, I'm using the rt73usb that ships with the F9 kernel.

Comment 4 AJ Bostian 2008-06-10 15:45:58 UTC
Does this mean that I should file a report upstream?  (I'm not exactly sure
where upstream is in this case.)

Comment 5 Dan Williams 2008-07-03 02:07:56 UTC
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 2.6.25.9-76.fc9.

Comment 6 AJ Bostian 2008-07-03 13:10:15 UTC
Still no luck with kernel-2.6.25.9-76.fc9.

Comment 7 Dan Williams 2008-07-03 16:10:24 UTC
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
just fine.

Comment 8 John W. Linville 2008-10-29 15:15:23 UTC
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...

Comment 9 John W. Linville 2008-12-11 18:48:26 UTC
Closed due to lack of response...please reopen if the problem remains with current kernels.