Hello,
I am unable to connect to a dynamic wep network with hidden ssid using
iwl3945 and the lastest fedora 7 kernel (which should have very recent
stuff). The problem is that the card never finds the ap. Running
wpa_supplicant directly shows "Got scan results xxx bytes" (can't
remeber the exact message).
While with ipw3945d + ieee80211 it works fine. (NetworkManager does not
connect either see http://bugzilla.gnome.org/show_bug.cgi?id=464215 ).
I haven't tryed the suggestion there yet because I am not near the
network right now.
Any idea whats wrong? Does it work for anybody (maybe with other
mac80211 drivers)
Currently I am not sure whom to blame iwl3945 or mac80211 or both.
Hey,
I bit more info. I am hearing it is a Cisco CCX feature and will not be
included in the open source code.
Dana
-----Original Message-----
From: [email protected]
[mailto:[email protected]] On Behalf Of
Ferguson, Dana R
Sent: Wednesday, October 10, 2007 10:43 AM
To: John W. Linville; Dan Williams
Cc: [email protected]; ipw3945-devel
Subject: Re: [ipw3945-devel] mac80211/iwlwifi + hidden ssids
Hi,
Engineers here have brought to my attention that this has been going on
for several projects and has been reported in Bugzilla on 2915, 3945 and
now the current. I can't get into the old data bases to provide bug
ID's. So I can't provide more details.
I am wondering why it keeps getting over looked? Have we narrowed it
down to where it is failing?
Dana
-----Original Message-----
From: [email protected]
[mailto:[email protected]] On Behalf Of John
W. Linville
Sent: Wednesday, October 10, 2007 8:20 AM
To: Dan Williams
Cc: [email protected]; ipw3945-devel
Subject: Re: [ipw3945-devel] mac80211/iwlwifi + hidden ssids
On Wed, Oct 10, 2007 at 11:07:46AM -0400, Dan Williams wrote:
> On Wed, 2007-10-10 at 16:57 +0200, dragoran wrote:
> > btw shouldn't all mac80211 drivers either work or not work because
the
> > code for this is in mac80211 and not in the drivers?
>
> Yeah, pretty much; but each driver/firmware may handle hidden ssids
> slightly differently. mac80211 should bring some sanity to this area,
> but I wouldn't discount variation between even mac80211 based drivers.
Hmmm...doesn't the iwlwifi firmware intercede in scanning?
John
--
John W. Linville
[email protected]
------------------------------------------------------------------------
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Ipw3945-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/ipw3945-devel
------------------------------------------------------------------------
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Ipw3945-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/ipw3945-devel
On Wed, Oct 10, 2007 at 10:34:07AM -0400, Dan Williams wrote:
> best we can do is set AP_SCAN=2, let wpa_supplicant blow all the
> settings to the card, and just _hope_ that the card/driver are smart
> enough to find the hidden SSID on their own and associate. Which is
> less often than we'd hope.
Dan, how does this comport w/ the mac80211 behavior? I.E. if mac80211
can find my hidden AP when using WEP (or nothing), why can't ap_scan=2
find the same AP?
John
--
John W. Linville
[email protected]
On Wed, 2007-10-10 at 14:10 -0400, John W. Linville wrote:
> On Wed, Oct 10, 2007 at 10:54:46AM -0700, Ferguson, Dana R wrote:
> > Hey,
> >
> > I bit more info. I am hearing it is a Cisco CCX feature and will not be
> > included in the open source code.
> >
> > Dana
>
> Huh? I'm not sure what "it" is? Care to elaborate?
Yeah, it's unclear. CCX should have _nothing_ to do with hidden SSID
support since hidden SSIDs (and workarounds to support them) existed
waaay before Cisco coughed up CCX.
Dan
> I do find it dismaying to hear that Intel is holding back wireless
> compatibility features from Linux...
>
> John
On 10/10/07, Dan Williams <[email protected]> wrote:
>[..]
> wpa_supplicant's support for hidden SSIDs sort of sucks; mainly because
> the drivers implement this in different ways. wpa_supplicant says you
> must use "ap_scan=2" for hidden SSIDs (and possibly ssid_scan=1 to do
> specific ssid probe requests), which causes wpa_supplicant to blast all
> settings to the card directly and not try to be smart about AP scanning
> and selection. However, this doesn't work often because drivers are
> inconsistent about this.
>
> The way it _should_ work is that if scan_ssid = 1 for a network,
> wpa_supplicant should ask that the driver scan the specific ssid using
> IW_SCAN_THIS_ESSID. The card would then issue specific SSID scan
> requests on each channel during the scan, and hopefully find the AP in
> question.
>
> Unfortunately, most drivers don't support IW_SCAN_THIS_ESSID. So the
> best we can do is set AP_SCAN=2, let wpa_supplicant blow all the
> settings to the card, and just _hope_ that the card/driver are smart
> enough to find the hidden SSID on their own and associate. Which is
> less often than we'd hope.
so your are suggestion to use ap_scan=2 and add scan_ssid=1 to the
network block?
nm seems not to do this.
btw shouldn't all mac80211 drivers either work or not work because the
code for this is in mac80211 and not in the drivers?
I will be able to test again this friday will try this and the
ap_scan=1 if there are other suggestion feel free to say them so I can
add them to my "totest" list ;)
Hi,
Engineers here have brought to my attention that this has been going on
for several projects and has been reported in Bugzilla on 2915, 3945 and
now the current. I can't get into the old data bases to provide bug
ID's. So I can't provide more details.
I am wondering why it keeps getting over looked? Have we narrowed it
down to where it is failing?
Dana
-----Original Message-----
From: [email protected]
[mailto:[email protected]] On Behalf Of John
W. Linville
Sent: Wednesday, October 10, 2007 8:20 AM
To: Dan Williams
Cc: [email protected]; ipw3945-devel
Subject: Re: [ipw3945-devel] mac80211/iwlwifi + hidden ssids
On Wed, Oct 10, 2007 at 11:07:46AM -0400, Dan Williams wrote:
> On Wed, 2007-10-10 at 16:57 +0200, dragoran wrote:
> > btw shouldn't all mac80211 drivers either work or not work because
the
> > code for this is in mac80211 and not in the drivers?
>
> Yeah, pretty much; but each driver/firmware may handle hidden ssids
> slightly differently. mac80211 should bring some sanity to this area,
> but I wouldn't discount variation between even mac80211 based drivers.
Hmmm...doesn't the iwlwifi firmware intercede in scanning?
John
--
John W. Linville
[email protected]
------------------------------------------------------------------------
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Ipw3945-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/ipw3945-devel
On Wed, 2007-10-10 at 11:20 -0400, John W. Linville wrote:
> On Wed, Oct 10, 2007 at 11:07:46AM -0400, Dan Williams wrote:
> > On Wed, 2007-10-10 at 16:57 +0200, dragoran wrote:
>
> > > btw shouldn't all mac80211 drivers either work or not work because the
> > > code for this is in mac80211 and not in the drivers?
> >
> > Yeah, pretty much; but each driver/firmware may handle hidden ssids
> > slightly differently. mac80211 should bring some sanity to this area,
> > but I wouldn't discount variation between even mac80211 based drivers.
>
> Hmmm...doesn't the iwlwifi firmware intercede in scanning?
Yes, but we tell it which SSID to scan for. Not that we know whether it
cares...
johannes
On Wed, Oct 10, 2007 at 03:47:27PM +0200, dragoran wrote:
> On 10/10/07, John W. Linville <[email protected]> wrote:
> > On Wed, Oct 10, 2007 at 11:45:12AM +0200, dragoran wrote:
> > > Hello,
> > > I am unable to connect to a dynamic wep network with hidden ssid using
> > > iwl3945 and the lastest fedora 7 kernel (which should have very recent
<snip>
> > Fedora 7 kernels are a little behind (1-2 weeks behind wireless-2.6)
> > ATM, so it might be best to handle this at bugzilla.kernel.org.
>
> Ok, will file a bug after collecting more data (wpa_supplicant output).
Ooops, make that bugzilla.redhat.com please!
> > F7 _does_ have the kernel patch to probe for hidden SSIDs when
> > associating. What I've found with that patch is that manually
> > invoking the wireless tools yields satisfactory results, but that NM
> > (which afaik relies on wpa_supplicant) still tends to have problems.
> I know I also followed the thread on the nm list but it seems that I
> cannot even get a connection with wpa_supplicant started by hand.
<snip>
> the wpa_supplicant.conf I tryed:
> -----------
> # this driver requires ap_scan=2 mode when using hidden SSIDs
> # request driver to take care of AP selection and roaming
> ap_scan=2
<snip>
> the exact same config works with the old stack.... should I try to
> change the ap_scan value to 1 ?
I think that would be worthwhile.
John
--
John W. Linville
[email protected]
On Wed, 2007-10-10 at 09:06 -0400, John W. Linville wrote:
> On Wed, Oct 10, 2007 at 11:45:12AM +0200, dragoran wrote:
> > Hello,
> > I am unable to connect to a dynamic wep network with hidden ssid using
> > iwl3945 and the lastest fedora 7 kernel (which should have very recent
> > stuff). The problem is that the card never finds the ap. Running
> > wpa_supplicant directly shows "Got scan results xxx bytes" (can't
> > remeber the exact message).
> > While with ipw3945d + ieee80211 it works fine. (NetworkManager does not
> > connect either see http://bugzilla.gnome.org/show_bug.cgi?id=464215 ).
> > I haven't tryed the suggestion there yet because I am not near the
> > network right now.
> > Any idea whats wrong? Does it work for anybody (maybe with other
> > mac80211 drivers)
> > Currently I am not sure whom to blame iwl3945 or mac80211 or both.
>
> Fedora 7 kernels are a little behind (1-2 weeks behind wireless-2.6)
> ATM, so it might be best to handle this at bugzilla.kernel.org.
>
> F7 _does_ have the kernel patch to probe for hidden SSIDs when
> associating. What I've found with that patch is that manually
> invoking the wireless tools yields satisfactory results, but that NM
> (which afaik relies on wpa_supplicant) still tends to have problems.
> My hunch is that wpa_supplicant (at least how NM configures it)
> is doing something "too smart", but I really don't know.
wpa_supplicant's support for hidden SSIDs sort of sucks; mainly because
the drivers implement this in different ways. wpa_supplicant says you
must use "ap_scan=2" for hidden SSIDs (and possibly ssid_scan=1 to do
specific ssid probe requests), which causes wpa_supplicant to blast all
settings to the card directly and not try to be smart about AP scanning
and selection. However, this doesn't work often because drivers are
inconsistent about this.
The way it _should_ work is that if scan_ssid = 1 for a network,
wpa_supplicant should ask that the driver scan the specific ssid using
IW_SCAN_THIS_ESSID. The card would then issue specific SSID scan
requests on each channel during the scan, and hopefully find the AP in
question.
Unfortunately, most drivers don't support IW_SCAN_THIS_ESSID. So the
best we can do is set AP_SCAN=2, let wpa_supplicant blow all the
settings to the card, and just _hope_ that the card/driver are smart
enough to find the hidden SSID on their own and associate. Which is
less often than we'd hope.
Dan
> Do you have control over the AP? If so, can you temporarily try
> using static WEP or an open configuration so that you can test using
> iwconfig?
>
> Thanks,
>
> John
1. Blan SSID scanning is not CCX feature. It should work just need to
be properly configured.
2. Scanning in iwl driver is always initiated by the driver unlike ipw2X.
3. CCX is closed standard by Cisco and we are not eligible to open it.
Talk to Cisco
Tomas
On 10/10/07, John W. Linville <[email protected]> wrote:
> On Wed, Oct 10, 2007 at 10:54:46AM -0700, Ferguson, Dana R wrote:
> > Hey,
> >
> > I bit more info. I am hearing it is a Cisco CCX feature and will not be
> > included in the open source code.
> >
> > Dana
>
> Huh? I'm not sure what "it" is? Care to elaborate?
>
> I do find it dismaying to hear that Intel is holding back wireless
> compatibility features from Linux...
>
> John
> --
> John W. Linville
> [email protected]
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems? Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> _______________________________________________
> Ipw3945-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/ipw3945-devel
>
On Wed, Oct 10, 2007 at 11:45:12AM +0200, dragoran wrote:
> Hello,
> I am unable to connect to a dynamic wep network with hidden ssid using
> iwl3945 and the lastest fedora 7 kernel (which should have very recent
> stuff). The problem is that the card never finds the ap. Running
> wpa_supplicant directly shows "Got scan results xxx bytes" (can't
> remeber the exact message).
> While with ipw3945d + ieee80211 it works fine. (NetworkManager does not
> connect either see http://bugzilla.gnome.org/show_bug.cgi?id=464215 ).
> I haven't tryed the suggestion there yet because I am not near the
> network right now.
> Any idea whats wrong? Does it work for anybody (maybe with other
> mac80211 drivers)
> Currently I am not sure whom to blame iwl3945 or mac80211 or both.
Fedora 7 kernels are a little behind (1-2 weeks behind wireless-2.6)
ATM, so it might be best to handle this at bugzilla.kernel.org.
F7 _does_ have the kernel patch to probe for hidden SSIDs when
associating. What I've found with that patch is that manually
invoking the wireless tools yields satisfactory results, but that NM
(which afaik relies on wpa_supplicant) still tends to have problems.
My hunch is that wpa_supplicant (at least how NM configures it)
is doing something "too smart", but I really don't know.
Do you have control over the AP? If so, can you temporarily try
using static WEP or an open configuration so that you can test using
iwconfig?
Thanks,
John
--
John W. Linville
[email protected]
On Wed, Oct 10, 2007 at 11:07:46AM -0400, Dan Williams wrote:
> On Wed, 2007-10-10 at 16:57 +0200, dragoran wrote:
> > btw shouldn't all mac80211 drivers either work or not work because the
> > code for this is in mac80211 and not in the drivers?
>
> Yeah, pretty much; but each driver/firmware may handle hidden ssids
> slightly differently. mac80211 should bring some sanity to this area,
> but I wouldn't discount variation between even mac80211 based drivers.
Hmmm...doesn't the iwlwifi firmware intercede in scanning?
John
--
John W. Linville
[email protected]
On Wed, 2007-10-10 at 16:57 +0200, dragoran wrote:
> On 10/10/07, Dan Williams <[email protected]> wrote:
> >[..]
> > wpa_supplicant's support for hidden SSIDs sort of sucks; mainly because
> > the drivers implement this in different ways. wpa_supplicant says you
> > must use "ap_scan=2" for hidden SSIDs (and possibly ssid_scan=1 to do
> > specific ssid probe requests), which causes wpa_supplicant to blast all
> > settings to the card directly and not try to be smart about AP scanning
> > and selection. However, this doesn't work often because drivers are
> > inconsistent about this.
> >
> > The way it _should_ work is that if scan_ssid = 1 for a network,
> > wpa_supplicant should ask that the driver scan the specific ssid using
> > IW_SCAN_THIS_ESSID. The card would then issue specific SSID scan
> > requests on each channel during the scan, and hopefully find the AP in
> > question.
> >
> > Unfortunately, most drivers don't support IW_SCAN_THIS_ESSID. So the
> > best we can do is set AP_SCAN=2, let wpa_supplicant blow all the
> > settings to the card, and just _hope_ that the card/driver are smart
> > enough to find the hidden SSID on their own and associate. Which is
> > less often than we'd hope.
>
> so your are suggestion to use ap_scan=2 and add scan_ssid=1 to the
> network block?
> nm seems not to do this.
It should be doing this...
> btw shouldn't all mac80211 drivers either work or not work because the
> code for this is in mac80211 and not in the drivers?
Yeah, pretty much; but each driver/firmware may handle hidden ssids
slightly differently. mac80211 should bring some sanity to this area,
but I wouldn't discount variation between even mac80211 based drivers.
Dan
> I will be able to test again this friday will try this and the
> ap_scan=1 if there are other suggestion feel free to say them so I can
> add them to my "totest" list ;)
On Wed, Oct 10, 2007 at 10:54:46AM -0700, Ferguson, Dana R wrote:
> Hey,
>
> I bit more info. I am hearing it is a Cisco CCX feature and will not be
> included in the open source code.
>
> Dana
Huh? I'm not sure what "it" is? Care to elaborate?
I do find it dismaying to hear that Intel is holding back wireless
compatibility features from Linux...
John
--
John W. Linville
[email protected]
On 10/10/07, John W. Linville <[email protected]> wrote:
> On Wed, Oct 10, 2007 at 11:45:12AM +0200, dragoran wrote:
> > Hello,
> > I am unable to connect to a dynamic wep network with hidden ssid using
> > iwl3945 and the lastest fedora 7 kernel (which should have very recent
> > stuff). The problem is that the card never finds the ap. Running
> > wpa_supplicant directly shows "Got scan results xxx bytes" (can't
> > remeber the exact message).
> > While with ipw3945d + ieee80211 it works fine. (NetworkManager does not
> > connect either see http://bugzilla.gnome.org/show_bug.cgi?id=464215 ).
> > I haven't tryed the suggestion there yet because I am not near the
> > network right now.
> > Any idea whats wrong? Does it work for anybody (maybe with other
> > mac80211 drivers)
> > Currently I am not sure whom to blame iwl3945 or mac80211 or both.
>
> Fedora 7 kernels are a little behind (1-2 weeks behind wireless-2.6)
> ATM, so it might be best to handle this at bugzilla.kernel.org.
Ok, will file a bug after collecting more data (wpa_supplicant output).
> F7 _does_ have the kernel patch to probe for hidden SSIDs when
> associating. What I've found with that patch is that manually
> invoking the wireless tools yields satisfactory results, but that NM
> (which afaik relies on wpa_supplicant) still tends to have problems.
I know I also followed the thread on the nm list but it seems that I
cannot even get a connection with wpa_supplicant started by hand.
> My hunch is that wpa_supplicant (at least how NM configures it)
> is doing something "too smart", but I really don't know.
>
> Do you have control over the AP? If so, can you temporarily try
> using static WEP or an open configuration so that you can test using
> iwconfig?
no if I had I could do some more testing. but the only thing I can nod
with this ap is to test if it works or not.
the wpa_supplicant.conf I tryed:
-----------
# this driver requires ap_scan=2 mode when using hidden SSIDs
# request driver to take care of AP selection and roaming
ap_scan=2
# enable control interface using UNIX domain sockets
ctrl_interface=/var/run/wpa_supplicant
# you can include one or more network blocks here
network={
ssid="NETWORKNAME"
key_mgmt=IEEE8021X
eap=TTLS
phase2="auth=MSCHAPV2"
identity="username"
password="password"
}
----------------------------------
the exact same config works with the old stack.... should I try to
change the ap_scan value to 1 ?