Bug 449189 - rt73usb needs ap_scan=2 to connect to hidden essid, NetworkManager sets ap_scan=1
Summary: rt73usb needs ap_scan=2 to connect to hidden essid, NetworkManager sets ap_sc...
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 9
Hardware: x86_64
OS: Linux
low
low
Target Milestone: ---
Assignee: John W. Linville
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2008-05-31 00:21 UTC by AJ Bostian
Modified: 2008-12-11 18:48 UTC (History)
4 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2008-12-11 18:48:26 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
/var/log/messages during NM association (2.21 KB, text/plain)
2008-05-31 00:21 UTC, AJ Bostian
no flags Details

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.


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