On Wednesday 16 April 2008 23:55 in
<D936D925018D154694D8A362EEB08920043539AE@orsmsx416.amr.corp.intel.com>,
Chatre, Reinette wrote:
> There seems to be a lot going on through initialization scripts of your
> distribution. Could you disable all that and try to get up and running
> with as little variables as possible? It may be that the interface is
> automatically brought up when the module is loaded - this script should
> be among your network init scripts. Can you disable that? You can load
> the driver with debugging and see through the logs if anything is trying
> to use it. The first goal is to load the driver and not have it do any
> work after initial load.
Ok, I did this now. iwl3945 is now only loaded manually by modprobe, and the
initscript is disabled for wlan0.
> After this follow the following steps (I am assuming you are not using
> security):
> $ /sbin/ip link set dev wlan0 up
> $ iwlist wlan0 scan
> Search for your AP in the above output - should match with your
> wpa_supplicant conf file.
> $ iwconfig wlan0 channel <channel of your AP> ap <MAC of your AP> essid
> <essid of your AP>
> $ iwconfig
> check above output to see if you are associated
> next use your usual net app to get an IP (dhclient?)
>
> Can you associate with the above steps? What do the logs look like?
The dmesg output is here:
https://www.cs.tcd.ie/~furlongm/iwlwifi/2.6.25-dmesg-wirelesstools-only
iwconfig wlan0 said it was associated (connecting to the AP with no security
now):
wlan0 IEEE 802.11g ESSID:"testing"
Mode:Managed Frequency:2.417 GHz Access Point: 00:0F:CC:5E:86:00
Bit Rate=54 Mb/s Tx-Power=15 dBm
Retry min limit:7 RTS thr:off Fragment thr=2352 B
Encryption key:off
Link Quality=84/100 Signal level=-49 dBm Noise level=-88 dBm
Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0
Tx excessive retries:0 Invalid misc:0 Missed beacon:0
but it never got an IP address, no matter what timeout I set for the dhcp
client.
iwlist wlan0 scan showed the AP a few times, but mostly found nothing at
all. When it did find APs, it found at most 2-3 APs, whereas the ipw driver
finds 10 or more APs on the same machine.
Marcus.
> Not wishing to muddy the waters, but I've found that the iwlwifi driver
> with a 3945 card is only reliable for scanning and associating for
> my laptop (x86_64) with disable_hw_scan=1 set, this is with
> 2.4.24.4-64.fc8 kernel. Driver version is 1.2.26.
>
> Previous to the recent heavy driver development, with 2.6.23.15-137.fc8
> the opposite was the case. This was driver version 1.2.23.
>
> Currently with sw scanning *every* scan returns my own 2 APs, whereas
> using hw scanning I often receive "No scan results" and my 2 APs
> sometimes appear in the scan output and disappear frequently. It's
> equally unreliable when I can see my neighbours APs, the software scan
> is reliable when signals are strong enough to register at all.
What I've found (a long time ago with hostapd) is that some APs are slow
and the firmware-assisted scanning has a too small dwell period. Maybe
we should have a module option for that so we can ask people to change
that in such cases? You could try to change the IWL_ACTIVE_DWELL_TIME_24
(and/or IWL_ACTIVE_DWELL_TIME_52) to higher values and maybe setting
IWL_PLCP_QUIET_THRESH to 0.
johannes
> Second the 3954 and 4965 my uCode may crash intentionally if you send
> probe requests on a passive channel.according EEPROM.
I really wonder what sort of error handling strategy that is, even if
it's done for regulatory compliance purposes I don't see a need to crash
the whole card. Especially considering that the userspace MLME in
wpa_supplicant will scan by itself (yes, it scans in userspace, whether
or not you may like that), of course it would be made comply with
regulatory settings but that makes it hard to develop.
> I personally wish to not make SW scanning possible at all for that reason.
That is not going to happen since you can always "scan" by sending probe
requests manually.
> At last iwlwifi HW scanning can handle up to 4 essids for direct scan
> but currently wireless tools interface cannot utilize this.
Does anybody actually *want* that? I personally dislike the behaviour of
scanning for all previously known SSIDs actively when hidden SSIDs are
so uncommon, I see it as an information disclosure vulnerability.
johannes
> > I'll leave it up to you (collective you, not necessarily a personal
> > you), how to best deal with associating with APs which are not
> > broadcasting their SSIDs. I agree with you (personal you this time) that
> > roaming around the country broadcasting those SSIDs does not seem
> > particularly desirable. So how should the ability to connect to non SSID
> > broadcasting APs be implemented?
>
> I would probably list, in network-manager, "I found (a) hidden
> network(s)" and ask the user for an SSID to scan for actively at that
> particular time, rather than trying to scan for all previously known
> SSIDs even if those networks weren't hidden, as windows laptops (at
> least those with Intel hardware but I haven't seen many others) seem to
> do.
Or it could remember the BSSID and when it encounters the BSSID again
scan it actively to see if it still has the same (albeit hidden) SSID.
My N810 behaves that way too, incidentally, it seems to first scan
broadcast but if you then don't select a network quickly it starts
scanning all networks directedly that it has previously saved.
johannes
On Sat, Apr 19, 2008 at 11:32 AM, Johannes Berg
<[email protected]> wrote:
>
> > Second the 3954 and 4965 my uCode may crash intentionally if you send
> > probe requests on a passive channel.according EEPROM.
>
> I really wonder what sort of error handling strategy that is, even if
> it's done for regulatory compliance purposes I don't see a need to crash
> the whole card. Especially considering that the userspace MLME in
> wpa_supplicant will scan by itself (yes, it scans in userspace, whether
> or not you may like that), of course it would be made comply with
> regulatory settings but that makes it hard to develop.
It should not scan on not supported channel in any conditions. EEPROM
and reg.c has to be combined.
>
> > I personally wish to not make SW scanning possible at all for that reason.
>
> That is not going to happen since you can always "scan" by sending probe
> requests manually.
Probe request before association is a must, no argue about it.
> > At last iwlwifi HW scanning can handle up to 4 essids for direct scan
> > but currently wireless tools interface cannot utilize this.
>
> Does anybody actually *want* that? I personally dislike the behaviour of
> scanning for all previously known SSIDs actively when hidden SSIDs are
> so uncommon, I see it as an information disclosure vulnerability.
Sure you want that. User space applications handles number of
preferred SSIDs, let's call them profiles. It's desired that you do
direct scan for those SSIDss for faster connection.
Currently it takes 20 minutes for NM to connect to network I want in
crowded air. (I'm exaggerating now I don't have real number... but
it's something like that)
It's not just for hidden ssids.
Tomas
On Sun, 2008-04-20 at 23:39 +0300, Tomas Winkler wrote:
> On Sat, Apr 19, 2008 at 11:32 AM, Johannes Berg
> <[email protected]> wrote:
> >
> > > Second the 3954 and 4965 my uCode may crash intentionally if you send
> > > probe requests on a passive channel.according EEPROM.
> >
> > I really wonder what sort of error handling strategy that is, even if
> > it's done for regulatory compliance purposes I don't see a need to crash
> > the whole card. Especially considering that the userspace MLME in
> > wpa_supplicant will scan by itself (yes, it scans in userspace, whether
> > or not you may like that), of course it would be made comply with
> > regulatory settings but that makes it hard to develop.
>
> It should not scan on not supported channel in any conditions. EEPROM
> and reg.c has to be combined.
The driver should _certainly_ be enforcing regulatory domains. Even if
userspace requests a scan of a channel that is not available in the
regulatory domain, the driver needs to be rejecting the scan request in
situations where the firmware would reject it.
If the firmware triggers an assertion, that definitely indicates a bug
in the driver, where the driver is not properly gating options sent to
the firmware. Only in the most exceptional circumstances should the
firmware actually crash.
> >
> > > I personally wish to not make SW scanning possible at all for that reason.
> >
> > That is not going to happen since you can always "scan" by sending probe
> > requests manually.
>
> Probe request before association is a must, no argue about it.
>
> > > At last iwlwifi HW scanning can handle up to 4 essids for direct scan
> > > but currently wireless tools interface cannot utilize this.
> >
> > Does anybody actually *want* that? I personally dislike the behaviour of
> > scanning for all previously known SSIDs actively when hidden SSIDs are
> > so uncommon, I see it as an information disclosure vulnerability.
>
> Sure you want that. User space applications handles number of
> preferred SSIDs, let's call them profiles. It's desired that you do
> direct scan for those SSIDss for faster connection.
> Currently it takes 20 minutes for NM to connect to network I want in
> crowded air. (I'm exaggerating now I don't have real number... but
> it's something like that)
More like 1 or 2 minutes; though the scanning algorithm in NM 0.7 does
need to be optimized somewhat. Cards that advertise > 14 channels are
assumed to take a prohibitively long time to scan while connected
(madwifi was the largest offender here), and therefore NM will not
request scans for a/b/g devices while connected, but will collect and
use background scan results.
Dan
> It's not just for hidden ssids.
>
> Tomas
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
On Fri, 18 Apr 2008 15:35:21 -0700
"Chatre, Reinette" <[email protected]> wrote:
> On , Brian Morrison wrote:
>
> > Not wishing to muddy the waters, but I've found that the iwlwifi
> > driver with a 3945 card is only reliable for scanning and associating
> > for
> > my laptop (x86_64) with disable_hw_scan=1 set, this is with
> > 2.4.24.4-64.fc8 kernel. Driver version is 1.2.26.
>
> I agree that your problem is related (no scanning results from driver),
> but it does seem to be different from what we are trying to debug here.
> In this case the user is not receiving scanning results when using sw
> scanning while the driver should have been using hw scanning because the
> user is not using that driver parameter as you are.
Yes, I just thought it might be useful to know that some people are
seeing the exact reverse.
It's actually working well for me now, so I'm in no hurry to break it :)
--
Brian Morrison
bdm at fenrir dot org dot uk
"Arguing with an engineer is like wrestling with a pig in the mud;
after a while you realize you are muddy and the pig is enjoying it."
GnuPG key ID DE32E5C5 - http://wwwkeys.uk.pgp.net/pgpnet/wwwkeys.html
On Mon, 2008-04-21 at 21:39 +0300, Tomas Winkler wrote:
> On Mon, Apr 21, 2008 at 3:14 AM, Dan Williams <[email protected]> wrote:
> > On Sun, 2008-04-20 at 23:39 +0300, Tomas Winkler wrote:
> > > On Sat, Apr 19, 2008 at 11:32 AM, Johannes Berg
> > > <[email protected]> wrote:
> > > >
> > > > > Second the 3954 and 4965 my uCode may crash intentionally if you send
> > > > > probe requests on a passive channel.according EEPROM.
> > > >
> > > > I really wonder what sort of error handling strategy that is, even if
> > > > it's done for regulatory compliance purposes I don't see a need to crash
> > > > the whole card. Especially considering that the userspace MLME in
> > > > wpa_supplicant will scan by itself (yes, it scans in userspace, whether
> > > > or not you may like that), of course it would be made comply with
> > > > regulatory settings but that makes it hard to develop.
> > >
> > > It should not scan on not supported channel in any conditions. EEPROM
> > > and reg.c has to be combined.
> >
> > The driver should _certainly_ be enforcing regulatory domains. Even if
> > userspace requests a scan of a channel that is not available in the
> > regulatory domain, the driver needs to be rejecting the scan request in
> > situations where the firmware would reject it.
>
> The problem is only in software scanning as the radio is tuned not
> through the scanning code.
> We need to fix this as passive channels are concern.
>
> > If the firmware triggers an assertion, that definitely indicates a bug
> > in the driver, where the driver is not properly gating options sent to
> > the firmware. Only in the most exceptional circumstances should the
> > firmware actually crash.
>
> Firmware might be crashed any time but wrong driver behavior. It's not
> designed to be robust towards 'friendly driver' it supposed to be
> defensive in way that it guarantees that it won't violated FCC.
>
> >
> > > >
> > > > > I personally wish to not make SW scanning possible at all for that reason.
> > > >
> > > > That is not going to happen since you can always "scan" by sending probe
> > > > requests manually.
> > >
> > > Probe request before association is a must, no argue about it.
> > >
> > > > > At last iwlwifi HW scanning can handle up to 4 essids for direct scan
> > > > > but currently wireless tools interface cannot utilize this.
> > > >
> > > > Does anybody actually *want* that? I personally dislike the behaviour of
> > > > scanning for all previously known SSIDs actively when hidden SSIDs are
> > > > so uncommon, I see it as an information disclosure vulnerability.
> > >
> > > Sure you want that. User space applications handles number of
> > > preferred SSIDs, let's call them profiles. It's desired that you do
> > > direct scan for those SSIDss for faster connection.
> > > Currently it takes 20 minutes for NM to connect to network I want in
> > > crowded air. (I'm exaggerating now I don't have real number... but
> > > it's something like that)
> >
> > More like 1 or 2 minutes; though the scanning algorithm in NM 0.7 does
> > need to be optimized somewhat. Cards that advertise > 14 channels are
> > assumed to take a prohibitively long time to scan while connected
> > (madwifi was the largest offender here), and therefore NM will not
> > request scans for a/b/g devices while connected, but will collect and
> > use background scan results.
> >
> Actually in place with 70 and more APs I was never able to associate
> with NM, only manual configuration works.
> At my home place actually it works 100% but I have like 4 APs in surrounding.
> I'm working with stock NM in latest F8.
Probably a supplicant issue here, since wpa_supplicant doesn't cache
scan results over time (like NM does) and therefore when NM asks the
supplicant to associate, the supplicant has to scan _again_ to find the
network to associate with. You could probably reproduce by creating a
supplicant config file and trying to associate with wpa_supplicant and
scan_ssid=1 + ap_scan=1 like NM is doing.
There's some consensus about fixing this upstream in wpa_supplicant, but
there's nobody working on it quite yet.
dan
On Sat, 2008-04-19 at 10:32 +0200, Johannes Berg wrote:
> > At last iwlwifi HW scanning can handle up to 4 essids for direct
> > scan but currently wireless tools interface cannot utilize this.
>
> Does anybody actually *want* that? I personally dislike the behaviour
> of scanning for all previously known SSIDs actively when hidden SSIDs
> are so uncommon, I see it as an information disclosure vulnerability.
I can't speak for what others may want, but the Payment Card Industry
security guidelines include not broadcasting the SSID as one of their
requirements, if that is what you mean by "hidden SSIDs."
--
Vincent C Jones <[email protected]>
Networking Unlimited, Inc.
On , Brian Morrison wrote:
> Not wishing to muddy the waters, but I've found that the iwlwifi
> driver with a 3945 card is only reliable for scanning and associating
> for
> my laptop (x86_64) with disable_hw_scan=1 set, this is with
> 2.4.24.4-64.fc8 kernel. Driver version is 1.2.26.
I agree that your problem is related (no scanning results from driver),
but it does seem to be different from what we are trying to debug here.
In this case the user is not receiving scanning results when using sw
scanning while the driver should have been using hw scanning because the
user is not using that driver parameter as you are.
Reinette
On Sat, 2008-04-19 at 15:51 +0200, Johannes Berg wrote:
> > > I'll leave it up to you (collective you, not necessarily a personal
> > > you), how to best deal with associating with APs which are not
> > > broadcasting their SSIDs. I agree with you (personal you this time) that
> > > roaming around the country broadcasting those SSIDs does not seem
> > > particularly desirable. So how should the ability to connect to non SSID
> > > broadcasting APs be implemented?
> >
> > I would probably list, in network-manager, "I found (a) hidden
> > network(s)" and ask the user for an SSID to scan for actively at that
> > particular time, rather than trying to scan for all previously known
> > SSIDs even if those networks weren't hidden, as windows laptops (at
> > least those with Intel hardware but I haven't seen many others) seem to
> > do.
>
> Or it could remember the BSSID and when it encounters the BSSID again
> scan it actively to see if it still has the same (albeit hidden) SSID.
That's what NM does; NM will cache the BSSIDs of previously associated
APs and use that to determine which APs to connect to automatically.
wpa_supplicant, unfortunately, doesn't use this trick when associating
(since it doesn't really store state at all), and therefore in the
hidden AP case, NM passes "ap_scan=1 + scan_ssid=1" to probe-scan the AP
that we want to connect to. But that's still only _one_ AP being
probe-scanned, not 4...
There's likely some room for improvement in wpa_supplicant here, since
there's added latency waiting for the supplicant to do scans when NM
already knows exactly which AP/BSSID to connect to already, but we can't
push the exact SSID into the supplicant's config, because that would
cause the supplicant to only ever assocate with that AP (I _think_ so at
least) and therefore not roam correctly.
Dan
> My N810 behaves that way too, incidentally, it seems to first scan
> broadcast but if you then don't select a network quickly it starts
> scanning all networks directedly that it has previously saved.
>
> johannes
On Fri, 18 Apr 2008 15:12:13 -0700, you wrote:
>
> On Friday, April 18, 2008 2:57 PM, Johannes Berg wrote:
>
>> Just jumping in here because I want to know if there are any mac8021=
1
>> bugs (I don't have any 5 GHz hw except the iwl4965, no AP), would it
>> maybe help to explicitly enable sw scanning?
>
> First thing is that there is a iwlwifi driver or ucode problem as it
> asserts every time (it seems) when mac_config is called for channels =
38,
> 42, 46, and 52. Channel 36 succeeds. The cause of the ucode error is
> unclear to me as I am waiting for somebody to get back to me about wh=
at
> the contents of that "event log dump" means.
>
> I looked further about why mac_config is called for those channels an=
d
> the reason appears to be that it is done from ieee80211_sta_scan_work=
=2E
> This should not happen as it should only do so for sw scanning (if I
> understand correctly), while the default for this driver is hw scanni=
ng
> (and the user is not overriding the default). I am thus now trying to
> figure out how it actually thinks sw scanning is enabled through some
> simple debugging where mac80211 tries to run the driver's hw_scan
> function.
>
> Explicitly enabling sw scanning is an interesting idea.
>
> Marcus: could you please run your test twice with that patch? The fir=
st
> time you run it as you did before, the second time please provide the
> driver parameter "disable_hw_scan=3D1" together with the debug parame=
ter.
Both dmesg logs here:
https://www.cs.tcd.ie/~furlongm/iwlwifi/2.6.25-dmesg-with-patch
https://www.cs.tcd.ie/~furlongm/iwlwifi/2.6.25-dmesg-with-patch-disable=
_hw_scan
This time I was able to associate, and the dhcp client got an address e=
ach time (with and without disable_hwscan=3D1). However, with disable_h=
w_scan=3D1, I tried to associate, then dmesg said it had timed out. Aft=
er playing around a bit, I figured out that I could only properly assoc=
iate with my AP (essid testing) after I associated with a different AP =
(connected to my neighbours one). Rebooted a few times and repeated and=
it worked each time.
Unfortunately both with and without disable_hwscan=3D1, I lost the conn=
ection after a few minutes.
(Quick question: I can't find information about using wireless-tools an=
d wpa for this driver. I saw for other drivers they use iwpriv set_algo=
=3D2 for wpa support, but iwl3945 doesn't seem to support this yet or i=
s there a different way?)
Marcus.
_________________________________________________________________
Love Hotmail? It just got better =96 Drag and Drop capabilities, new Re=
ading Panes making it easier to read your mail, enhanced security setti=
ngs, 5GB of FREE storage? New Windows Live Hotmail. Get your free accou=
nt here
http://get.live.com/mail/overview/-
On Friday, April 18, 2008 7:33 PM, Marcus Furlong wrote:
> Both dmesg logs here:
>
> https://www.cs.tcd.ie/~furlongm/iwlwifi/2.6.25-dmesg-with-patch
> https://www.cs.tcd.ie/~furlongm/iwlwifi/2.6.25-dmesg-with-patch
> -disable_hw_scan
This is very strange. Did anything change in your setup since you sent
the logs that created the debug file named
"2.6.25-dmesg-wirelesstools-only"? In the above log
2.6.25-dmesg-with-patch hardware scanning is indeed being used ... while
it was not in the previous test runs. Note the debug message
"iwl3945_mac_hw_scan enter" and "iwl3945_mac_hw_scan leave". This
message only appears in this log (2.6.25-dmesg-with-patch) and none of
the others.
I find it very hard to believe that this patch caused hw scanning to
work all of a sudden.
Reinette
On Fri, 18 Apr 2008 15:12:13 -0700
"Chatre, Reinette" <[email protected]> wrote:
> Explicitly enabling sw scanning is an interesting idea.
>
> Marcus: could you please run your test twice with that patch? The first
> time you run it as you did before, the second time please provide the
> driver parameter "disable_hw_scan=1" together with the debug parameter.
Not wishing to muddy the waters, but I've found that the iwlwifi driver
with a 3945 card is only reliable for scanning and associating for
my laptop (x86_64) with disable_hw_scan=1 set, this is with
2.4.24.4-64.fc8 kernel. Driver version is 1.2.26.
Previous to the recent heavy driver development, with 2.6.23.15-137.fc8
the opposite was the case. This was driver version 1.2.23.
Currently with sw scanning *every* scan returns my own 2 APs, whereas
using hw scanning I often receive "No scan results" and my 2 APs
sometimes appear in the scan output and disappear frequently. It's
equally unreliable when I can see my neighbours APs, the software scan
is reliable when signals are strong enough to register at all.
One of the Fedora common bugs advised the used of sw scanning, this is
still showing up on the common bugs list.
--
Brian Morrison
"Arguing with an engineer is like wrestling with a pig in the mud;
after a while you realize you are muddy and the pig is enjoying it."
On Sat, 2008-04-19 at 15:09 +0200, Johannes Berg wrote:
> > > Does anybody actually *want* that? I personally dislike the behaviour
> > > of scanning for all previously known SSIDs actively when hidden SSIDs
> > > are so uncommon, I see it as an information disclosure vulnerability.
> >
> > I can't speak for what others may want, but the Payment Card Industry
> > security guidelines include not broadcasting the SSID as one of their
> > requirements, if that is what you mean by "hidden SSIDs."
>
> So how would you feel if I told you that, after you have once used that
> hidden network, your laptop will be broadcasting the SSID in probe
> requests every time it scans, no matter where you are, even if you've
> moved across the continent?
I am not going to waste bandwidth debating the correctness of the PCI
guidelines, because right or wrong, they are what they are. I was just
trying to point out that the need to deal with access points which do
not broadcast their SSIDs is real and likely to become more common in
the future, at least for any systems using wireless in a retail or other
credit card dealing environment.
I'll leave it up to you (collective you, not necessarily a personal
you), how to best deal with associating with APs which are not
broadcasting their SSIDs. I agree with you (personal you this time) that
roaming around the country broadcasting those SSIDs does not seem
particularly desirable. So how should the ability to connect to non SSID
broadcasting APs be implemented?
My hope is that the more you are aware of the constraints on others who
want to take advantage of all your hard work, the more likely you are to
make the correct decisions and trade offs. I am not attacking your
efforts, ability or motivation. I only wanted to point out that the
design assumption in the first quotation that "hidden SSIDs are so
uncommon" may need to be revised.
--
Vincent C Jones <[email protected]>
Networking Unlimited, Inc.
On Sat, 2008-04-19 at 15:09 +0200, Johannes Berg wrote:
> > > Does anybody actually *want* that? I personally dislike the behaviour
> > > of scanning for all previously known SSIDs actively when hidden SSIDs
> > > are so uncommon, I see it as an information disclosure vulnerability.
> >
> > I can't speak for what others may want, but the Payment Card Industry
> > security guidelines include not broadcasting the SSID as one of their
> > requirements, if that is what you mean by "hidden SSIDs."
>
> So how would you feel if I told you that, after you have once used that
> hiddent network, your laptop will be broadcasting the SSID in probe
> requests every time it scans, no matter where you are, even if you've
> moved across the continent?
Unfortuately, I keep getting way too many reports about hidden SSIDs
still. I don't feel like it's something we can start ignoring (yet).
Maybe in a few years, but we've still got to handle this for the
forseeable future.
Dan
> > iwlist wlan0 scan showed the AP a few times, but mostly found nothing
> > at all. When it did find APs, it found at most 2-3 APs, whereas
> > the ipw driver
> > finds 10 or more APs on the same machine.
>
> I am seeing something very strange in this log and the logs you sent in
> your first message. It appears that your driver uses software scanning
> while hardware scanning is the default for this driver. This appears to
> be the cause of the ucode errors as the A band channels are configured
> as part of the scanning process.
Just jumping in here because I want to know if there are any mac80211
bugs (I don't have any 5 GHz hw except the iwl4965, no AP), would it
maybe help to explicitly enable sw scanning?
johannes
On Mon, Apr 21, 2008 at 3:14 AM, Dan Williams <[email protected]> wrote:
> On Sun, 2008-04-20 at 23:39 +0300, Tomas Winkler wrote:
> > On Sat, Apr 19, 2008 at 11:32 AM, Johannes Berg
> > <[email protected]> wrote:
> > >
> > > > Second the 3954 and 4965 my uCode may crash intentionally if you send
> > > > probe requests on a passive channel.according EEPROM.
> > >
> > > I really wonder what sort of error handling strategy that is, even if
> > > it's done for regulatory compliance purposes I don't see a need to crash
> > > the whole card. Especially considering that the userspace MLME in
> > > wpa_supplicant will scan by itself (yes, it scans in userspace, whether
> > > or not you may like that), of course it would be made comply with
> > > regulatory settings but that makes it hard to develop.
> >
> > It should not scan on not supported channel in any conditions. EEPROM
> > and reg.c has to be combined.
>
> The driver should _certainly_ be enforcing regulatory domains. Even if
> userspace requests a scan of a channel that is not available in the
> regulatory domain, the driver needs to be rejecting the scan request in
> situations where the firmware would reject it.
The problem is only in software scanning as the radio is tuned not
through the scanning code.
We need to fix this as passive channels are concern.
> If the firmware triggers an assertion, that definitely indicates a bug
> in the driver, where the driver is not properly gating options sent to
> the firmware. Only in the most exceptional circumstances should the
> firmware actually crash.
Firmware might be crashed any time but wrong driver behavior. It's not
designed to be robust towards 'friendly driver' it supposed to be
defensive in way that it guarantees that it won't violated FCC.
>
> > >
> > > > I personally wish to not make SW scanning possible at all for that reason.
> > >
> > > That is not going to happen since you can always "scan" by sending probe
> > > requests manually.
> >
> > Probe request before association is a must, no argue about it.
> >
> > > > At last iwlwifi HW scanning can handle up to 4 essids for direct scan
> > > > but currently wireless tools interface cannot utilize this.
> > >
> > > Does anybody actually *want* that? I personally dislike the behaviour of
> > > scanning for all previously known SSIDs actively when hidden SSIDs are
> > > so uncommon, I see it as an information disclosure vulnerability.
> >
> > Sure you want that. User space applications handles number of
> > preferred SSIDs, let's call them profiles. It's desired that you do
> > direct scan for those SSIDss for faster connection.
> > Currently it takes 20 minutes for NM to connect to network I want in
> > crowded air. (I'm exaggerating now I don't have real number... but
> > it's something like that)
>
> More like 1 or 2 minutes; though the scanning algorithm in NM 0.7 does
> need to be optimized somewhat. Cards that advertise > 14 channels are
> assumed to take a prohibitively long time to scan while connected
> (madwifi was the largest offender here), and therefore NM will not
> request scans for a/b/g devices while connected, but will collect and
> use background scan results.
>
Actually in place with 70 and more APs I was never able to associate
with NM, only manual configuration works.
At my home place actually it works 100% but I have like 4 APs in surrounding.
I'm working with stock NM in latest F8.
Tomas
> > So how would you feel if I told you that, after you have once used that
> > hidden network, your laptop will be broadcasting the SSID in probe
> > requests every time it scans, no matter where you are, even if you've
> > moved across the continent?
>
> I am not going to waste bandwidth debating the correctness of the PCI
> guidelines, because right or wrong, they are what they are. I was just
> trying to point out that the need to deal with access points which do
> not broadcast their SSIDs is real and likely to become more common in
> the future, at least for any systems using wireless in a retail or other
> credit card dealing environment.
Oh, I don't want to debate the PCI guidelines, just saying that, which
is what I started out with, I don't see much reason to have active
scanning for four SSIDs.
> I'll leave it up to you (collective you, not necessarily a personal
> you), how to best deal with associating with APs which are not
> broadcasting their SSIDs. I agree with you (personal you this time) that
> roaming around the country broadcasting those SSIDs does not seem
> particularly desirable. So how should the ability to connect to non SSID
> broadcasting APs be implemented?
I would probably list, in network-manager, "I found (a) hidden
network(s)" and ask the user for an SSID to scan for actively at that
particular time, rather than trying to scan for all previously known
SSIDs even if those networks weren't hidden, as windows laptops (at
least those with Intel hardware but I haven't seen many others) seem to
do.
johannes
On Sat, 2008-04-19 at 00:37 +0200, Johannes Berg wrote:
> What I've found (a long time ago with hostapd) is that some APs are slow
> and the firmware-assisted scanning has a too small dwell period. Maybe
> we should have a module option for that so we can ask people to change
> that in such cases? You could try to change the IWL_ACTIVE_DWELL_TIME_24
> (and/or IWL_ACTIVE_DWELL_TIME_52) to higher values and maybe setting
> IWL_PLCP_QUIET_THRESH to 0.
Just as a datapoint, mac80211's sw scanning uses about 30 msec for
active and 200 for passive (on both bands).
johannes
On , Marcus Furlong wrote:
> iwlist wlan0 scan showed the AP a few times, but mostly found nothing
> at all. When it did find APs, it found at most 2-3 APs, whereas
> the ipw driver
> finds 10 or more APs on the same machine.
I am seeing something very strange in this log and the logs you sent in
your first message. It appears that your driver uses software scanning
while hardware scanning is the default for this driver. This appears to
be the cause of the ucode errors as the A band channels are configured
as part of the scanning process.
Now, how this happens is weird. I tried running 2.6.25-rc9 myself and
was not able to reproduce the problem - hardware scanning was used. The
driver is also explicit when HW scanning is disabled, this does not
appear in your logs, it is also explicit about when it runs HW scanning,
this also does not appear in your logs. So it does not seem as though
you are disabling the default HW scanning, but yet it uses SW scanning.
How it ends up using software scanning is not clear.
In an effort to trace what could be happening I created a small patch
(attached) that adds more debugging to the scanning code. Could you
please run with this patch and send us the debug output?
Thank you very much
Reinette
On Sat, Apr 19, 2008 at 1:39 AM, Johannes Berg
<[email protected]> wrote:
> On Sat, 2008-04-19 at 00:37 +0200, Johannes Berg wrote:
>
> > What I've found (a long time ago with hostapd) is that some APs are slow
> > and the firmware-assisted scanning has a too small dwell period. Maybe
> > we should have a module option for that so we can ask people to change
> > that in such cases? You could try to change the IWL_ACTIVE_DWELL_TIME_24
> > (and/or IWL_ACTIVE_DWELL_TIME_52) to higher values and maybe setting
> > IWL_PLCP_QUIET_THRESH to 0.
>
> Just as a datapoint, mac80211's sw scanning uses about 30 msec for
> active and 200 for passive (on both bands).
>
First of all we have some scanning fixes coming soon
Second the 3954 and 4965 my uCode may crash intentionally if you send
probe requests on a passive channel.according EEPROM.
I personally wish to not make SW scanning possible at all for that reason.
Third the scanning on passive channels is a bit conservative we need
to changed that in the FW.
At last iwlwifi HW scanning can handle up to 4 essids for direct scan
but currently wireless tools interface cannot utilize this.
Tomas
> johannes
>
> > Does anybody actually *want* that? I personally dislike the behaviour
> > of scanning for all previously known SSIDs actively when hidden SSIDs
> > are so uncommon, I see it as an information disclosure vulnerability.
>
> I can't speak for what others may want, but the Payment Card Industry
> security guidelines include not broadcasting the SSID as one of their
> requirements, if that is what you mean by "hidden SSIDs."
So how would you feel if I told you that, after you have once used that
hiddent network, your laptop will be broadcasting the SSID in probe
requests every time it scans, no matter where you are, even if you've
moved across the continent?
johannes
On Friday, April 18, 2008 2:57 PM, Johannes Berg wrote:
> Just jumping in here because I want to know if there are any mac80211
> bugs (I don't have any 5 GHz hw except the iwl4965, no AP), would it
> maybe help to explicitly enable sw scanning?
First thing is that there is a iwlwifi driver or ucode problem as it
asserts every time (it seems) when mac_config is called for channels 38,
42, 46, and 52. Channel 36 succeeds. The cause of the ucode error is
unclear to me as I am waiting for somebody to get back to me about what
the contents of that "event log dump" means.
I looked further about why mac_config is called for those channels and
the reason appears to be that it is done from ieee80211_sta_scan_work.
This should not happen as it should only do so for sw scanning (if I
understand correctly), while the default for this driver is hw scanning
(and the user is not overriding the default). I am thus now trying to
figure out how it actually thinks sw scanning is enabled through some
simple debugging where mac80211 tries to run the driver's hw_scan
function.
Explicitly enabling sw scanning is an interesting idea.
Marcus: could you please run your test twice with that patch? The first
time you run it as you did before, the second time please provide the
driver parameter "disable_hw_scan=1" together with the debug parameter.
Thank you
Reinette
On Fri, 2008-04-18 at 23:23 +0100, Brian Morrison wrote:
> On Fri, 18 Apr 2008 15:12:13 -0700
> "Chatre, Reinette" <[email protected]> wrote:
>
> > Explicitly enabling sw scanning is an interesting idea.
> >
> > Marcus: could you please run your test twice with that patch? The first
> > time you run it as you did before, the second time please provide the
> > driver parameter "disable_hw_scan=1" together with the debug parameter.
>
> Not wishing to muddy the waters, but I've found that the iwlwifi driver
> with a 3945 card is only reliable for scanning and associating for
> my laptop (x86_64) with disable_hw_scan=1 set, this is with
> 2.4.24.4-64.fc8 kernel. Driver version is 1.2.26.
>
> Previous to the recent heavy driver development, with 2.6.23.15-137.fc8
> the opposite was the case. This was driver version 1.2.23.
>
> Currently with sw scanning *every* scan returns my own 2 APs, whereas
> using hw scanning I often receive "No scan results" and my 2 APs
> sometimes appear in the scan output and disappear frequently. It's
> equally unreliable when I can see my neighbours APs, the software scan
> is reliable when signals are strong enough to register at all.
>
> One of the Fedora common bugs advised the used of sw scanning, this is
> still showing up on the common bugs list.
The specific issue that caused Linville and I to request that people use
disable_hw_scan=1 was to diagnose an issue with iwl3945 where the driver
would subsequently fail to find an AP that was previously associated
with, without an rmmod/modprobe cycle.
After resume from sleep or hibernate, and in some cases where the STA
got disconnected, even repeated 'iwlist wlan0 scan' would fail to find
the previously associated AP, despite showing up to 30 or so APs in the
area, and despite being just 30 FT away from one AP in the SSID.
Setting disable_hw_scan=1 "fixed" the issue, though we hadn't gotten too
far with debugging it yet.
Dan
On Mon, Apr 21, 2008 at 10:20 PM, Dan Williams <[email protected]> wrote:
>
> On Mon, 2008-04-21 at 21:39 +0300, Tomas Winkler wrote:
> > On Mon, Apr 21, 2008 at 3:14 AM, Dan Williams <[email protected]> wrote:
> > > On Sun, 2008-04-20 at 23:39 +0300, Tomas Winkler wrote:
> > > > On Sat, Apr 19, 2008 at 11:32 AM, Johannes Berg
> > > > <[email protected]> wrote:
> > > > >
> > > > > > Second the 3954 and 4965 my uCode may crash intentionally if you send
> > > > > > probe requests on a passive channel.according EEPROM.
> > > > >
> > > > > I really wonder what sort of error handling strategy that is, even if
> > > > > it's done for regulatory compliance purposes I don't see a need to crash
> > > > > the whole card. Especially considering that the userspace MLME in
> > > > > wpa_supplicant will scan by itself (yes, it scans in userspace, whether
> > > > > or not you may like that), of course it would be made comply with
> > > > > regulatory settings but that makes it hard to develop.
> > > >
> > > > It should not scan on not supported channel in any conditions. EEPROM
> > > > and reg.c has to be combined.
> > >
> > > The driver should _certainly_ be enforcing regulatory domains. Even if
> > > userspace requests a scan of a channel that is not available in the
> > > regulatory domain, the driver needs to be rejecting the scan request in
> > > situations where the firmware would reject it.
> >
> > The problem is only in software scanning as the radio is tuned not
> > through the scanning code.
> > We need to fix this as passive channels are concern.
> >
> > > If the firmware triggers an assertion, that definitely indicates a bug
> > > in the driver, where the driver is not properly gating options sent to
> > > the firmware. Only in the most exceptional circumstances should the
> > > firmware actually crash.
> >
> > Firmware might be crashed any time but wrong driver behavior. It's not
> > designed to be robust towards 'friendly driver' it supposed to be
> > defensive in way that it guarantees that it won't violated FCC.
> >
> > >
> > > > >
> > > > > > I personally wish to not make SW scanning possible at all for that reason.
> > > > >
> > > > > That is not going to happen since you can always "scan" by sending probe
> > > > > requests manually.
> > > >
> > > > Probe request before association is a must, no argue about it.
> > > >
> > > > > > At last iwlwifi HW scanning can handle up to 4 essids for direct scan
> > > > > > but currently wireless tools interface cannot utilize this.
> > > > >
> > > > > Does anybody actually *want* that? I personally dislike the behaviour of
> > > > > scanning for all previously known SSIDs actively when hidden SSIDs are
> > > > > so uncommon, I see it as an information disclosure vulnerability.
> > > >
> > > > Sure you want that. User space applications handles number of
> > > > preferred SSIDs, let's call them profiles. It's desired that you do
> > > > direct scan for those SSIDss for faster connection.
> > > > Currently it takes 20 minutes for NM to connect to network I want in
> > > > crowded air. (I'm exaggerating now I don't have real number... but
> > > > it's something like that)
> > >
> > > More like 1 or 2 minutes; though the scanning algorithm in NM 0.7 does
> > > need to be optimized somewhat. Cards that advertise > 14 channels are
> > > assumed to take a prohibitively long time to scan while connected
> > > (madwifi was the largest offender here), and therefore NM will not
> > > request scans for a/b/g devices while connected, but will collect and
> > > use background scan results.
> > >
> > Actually in place with 70 and more APs I was never able to associate
> > with NM, only manual configuration works.
> > At my home place actually it works 100% but I have like 4 APs in surrounding.
> > I'm working with stock NM in latest F8.
>
> Probably a supplicant issue here, since wpa_supplicant doesn't cache
> scan results over time (like NM does) and therefore when NM asks the
> supplicant to associate, the supplicant has to scan _again_ to find the
> network to associate with. You could probably reproduce by creating a
> supplicant config file and trying to associate with wpa_supplicant and
> scan_ssid=1 + ap_scan=1 like NM is doing.
>
> There's some consensus about fixing this upstream in wpa_supplicant, but
> there's nobody working on it quite yet.
>
Thanks for info, will try
> dan
>
>
>