Hello,
First sorry for the late report, the patches from the old thread fixed
the privacy mismatch issue and now I can connect to a dynamic wep
network. But the connection is not very stable because I get tons of wep
decrypt errors in dmesg (while the connection is working but slow).
The same network works fine with ipw3945. Also iwl3945 works fine with
static wep. I tryed the hwcrypt engine (hwcrypt=1) but it did not change
anything.
While connectiong with wpa_supplicant I saw that mac80211 does not
support the IW_AUTH_DROP_UNENCRYPTED ioctl while ipw3945 (ieee80211
based) does.
Could this be related? ie. mac80211 tryes to decrypt unencrypted frames
instead of dropping them?
If not any other ideas what could cause it? Or what kind of info is needed?
Second problem is that ssid is hidden. I was able to connect to it using
iwl3945 (even with hw_scan) but only with ap_scan=1 (while ap_scan=2
should be used for hidden ssid and thats what nm uses). Non mac80211
based drivers do not work with ap_scan=1 but with ap_scan=2. So this
needs to be fixed somehow so that nm can support both wireless stacks.
On Mon, Nov 26, 2007 at 11:04:24AM -0500, Dan Williams wrote:
> Because in the case of hidden SSIDs, wpa_supplicant pretty much says to
> use ap_scan=2.
Or ap_scan=1 with scan_ssid if and only if the driver supports it..
> 2) scan_ssid=1 hasn't worked consistently on all drivers because it's
> pretty new and many drivers don't support it yet. This is supposed to
> make the driver/firmware send out probe request for the SSID in
> question.
This is not only a driver issue, though. I believe there are full MAC
cards that do not support scan request with a specific SSID and the only
way to make them work with hidden SSIDs is to try to associate with the
SSID (i.e., use ap_scan=2).
In theory, wpa_supplicant could try to figure out whether the scan with
a specific SSID works or not (though, this is not that easy to do since
old drivers are likely to just ignore the provided SSID and do a
wildcard scan) and if that is the case, start probing the network with
ap_scan=2 like behavior. This would mean that it would go through the
configured networks and try to associate with each that is enabled and
marked with scan_ssid=1. If association is completed successfully, the
network could be added to scan results (at this point, the driver would
also be more likely to actually include it in the scan results, so
proper data could now be available).
The main problem with this is that it can take quite long time to do
this kind of association probing just to be able to get scan results.
Furthermore, at least some cards may require a full match in security
parameters, i.e., each SSID could potentially require multiple
association attempts (assuming the network block was not configured with
explicit security parameters).
Taken into account how much I like hidden SSIDs, I would likely just
prefer to ignore the issue and try to make people use proper security
with visible SSIDs if they want to limit access to their network. Use of
hidden SSIDs is just plain horrible way of making clients suffer without
any level of increased security.
--
Jouni Malinen PGP id EFC895FA
> Let me rant that ap_scan is the single thing that has given me the most
> headaches with NetworkManager. It's simply impossible use correctly on
> Linux. There's _got_ to be a better way to deal with hidden SSIDs.
What I'd expect you to do is do a directed scan like "iwlist wlan0 scan
essid XYZ" (and be sure that nl80211 will name that "ssid" rather than
the Jean-thought-it-was-better "essid") and then interpret the scan
results.
johannes
> looking at the code seems not:
> ---
> if (ieee80211_wep_decrypt_data(local->wep_rx_tfm, rc4key, klen,
> skb->data + hdrlen + WEP_IV_LEN,
> len)) {
> printk(KERN_DEBUG "WEP decrypt failed (ICV)\n");
> ret = -1;
> }
> ---
Huh I thought they were. Of course they need to be rate limited then.
Can you send a patch?
johannes
> this does not happen with the ipw3945 driver but with the iwl3945 so its
> either something with this driver or mac80211.
I just posted a patch for iwl4965 to make monitoring possible. Maybe you
can port that to iwl3945 and send me a packet dump with that patch
applied where the problem occurs. Or just do it without the patch,
should be good enough too.
Just grap iw (from git.sipsolutions.net) and create a new monitor
interface: ./iw dev wmaster0 interface add moni0 type monitor
and then run tcpdump/wireshark on that.
johannes
> Because in the case of hidden SSIDs, wpa_supplicant pretty much says to
> use ap_scan=2.
>
> There are a few problems here:
>
> 1) Historically, some drivers worked better with ap_scan=1 (madwifi),
> others worked better with ap_scan=2 (many fullmac drivers)
>
> 2) scan_ssid=1 hasn't worked consistently on all drivers because it's
> pretty new and many drivers don't support it yet. This is supposed to
> make the driver/firmware send out probe request for the SSID in
> question.
>
> So basically, we're up shit creek without a paddle. You have to use
> ap_scan=2 on some cards because they don't support specific-ssid
> scanning (with scan_ssid=1) to find the BSS you want to connect to, but
> some cards can handle ap_scan=1+scan_ssid=1 OK.
Fun. I'm pretty sure mac80211 handles ap_scan=1/scan_ssid=1 fine,
sending probe requests for that specific SSID.
> NM has logic to cache the BSSIDs of APs you've connected to before, and
> to match those up with an SSID when it sees them in the scan list if the
> AP isn't broadcasting the SSID. Unfortunately, that information isn't
> available to wpa_supplicant because wpa_supplicant doesn't have an
> interface to handle that sort of thing. Therefore, when faced with an a
> request to connect to a hidden network, wpa_supplicant must rely
> _entirely_ on the driver Doing The Right Thing with scan_ssid=1 or
> ap_scan=2, and that almost never works due to inconsistency in driver
> implementation.
Who invented hidden SSIDs anyway? Well, I guess I can actually test this
now that I finally have a second mac80211-based wireless card, although
iwl4965 is special wrt. scanning. I guess the trick will be to make
ap_scan=2 work although ap_scan=1/scan_ssid=1 works much better :(
We can fix that in nl80211 by making sure that scan_ssid is implemented
right away and whoever has nl80211 support needs to support that so that
we can rely on it...
johannes
> what works:
> connect to a hidden ssid with ap_scan=1 in wpa_supplicant.conf
> what does not work:
> connect to a hidden ssid with ap_scan=2 in wpa_supplicant.conf
> ---
> for non mac80211 drivers its the opposite ie. ap_scan=2 can connect to
> hidden ssid while ap_scan=1 works
> (thats also whats documented in the wpa_supplicant docs and what nm uses).
>
> so NM can't support mac80211 and non mac80211 drivers at the same time
> without ugly hacks due to this issue.
That's weird. But why does it use ap_scan=2 to start with? With
mac80211, ap_scan=1 is *much* much better because it lets wpa_supplicant
control much of roaming, mac80211 really is designed that way.
I don't see why ap_scan=2 doesn't work though, can you enable some
wpa_supplicant debugging and send me the logs? Or can you turn off
encryption and see if you can connect to a hidden SSID? I'd think it
should work because we do a directed scan so the probe response should
tell us the SSID.
johannes
On Mon, Nov 26, 2007 at 01:14:04PM +0100, Johannes Berg wrote:
> That's weird. But why does it use ap_scan=2 to start with? With
> mac80211, ap_scan=1 is *much* much better because it lets wpa_supplicant
> control much of roaming, mac80211 really is designed that way.
>
> I don't see why ap_scan=2 doesn't work though, can you enable some
> wpa_supplicant debugging and send me the logs?
Well, like you said, it was designed to work with ap_scan=1 and
actually, there was not even code for selecting the BSS in the original
version. Unless someone has added that functionality, it does not
work with ap_scan=2 which is only configuring the SSID, not BSSID, to
the driver.
--
Jouni Malinen PGP id EFC895FA
Hi,
> First sorry for the late report, the patches from the old thread fixed
> the privacy mismatch issue and now I can connect to a dynamic wep
> network. But the connection is not very stable because I get tons of wep
> decrypt errors in dmesg (while the connection is working but slow).
> The same network works fine with ipw3945. Also iwl3945 works fine with
> static wep. I tryed the hwcrypt engine (hwcrypt=1) but it did not change
> anything.
> While connectiong with wpa_supplicant I saw that mac80211 does not
> support the IW_AUTH_DROP_UNENCRYPTED ioctl while ipw3945 (ieee80211
> based) does.
> Could this be related? ie. mac80211 tryes to decrypt unencrypted frames
> instead of dropping them?
Odd. I'll have to take a look. I recently noticed that mac80211 would
always *accept* unencrypted frames but it shouldn't try to decrypt them.
> Second problem is that ssid is hidden. I was able to connect to it using
> iwl3945 (even with hw_scan) but only with ap_scan=1 (while ap_scan=2
> should be used for hidden ssid and thats what nm uses). Non mac80211
> based drivers do not work with ap_scan=1 but with ap_scan=2. So this
> needs to be fixed somehow so that nm can support both wireless stacks.
Uh so say that again what works where and what doesn't?
johannes
On Mon, Nov 26, 2007 at 03:50:00PM +0100, dragoran wrote:
> btw would it make sense to ratelimit
>
> "WEP decrypt failed (ICV)" messages?
> they are a bit annoying when connected to this network...
>
> dmesg | grep ICV | wc -l
> 3489
>
> after some minutes.
While I fully agree that these messages should be rate limited, it is
somewhat surprising to see this large a number of reported ICV failures.
Does the ipw3945 not filter out FCS errors before passing the frame for
WEP decryption? Or is there something odd about this network/client
configuration that makes the client try to decrypt frames that are not
really for it?
I can think of one valid case (VLAN with separate broadcast domains
using the same BSS), all other cases seem like waste of CPU power since
I would have expected the frames to be filtered out before reaching WEP
decryption if this STA is not the correct destination for them.
--
Jouni Malinen PGP id EFC895FA
On Nov 28, 2007 5:50 PM, Johannes Berg <[email protected]> wrote:
>
> > this does not happen with the ipw3945 driver but with the iwl3945 so its
> > either something with this driver or mac80211.
>
> I just posted a patch for iwl4965 to make monitoring possible. Maybe you
> can port that to iwl3945 and send me a packet dump with that patch
> applied where the problem occurs. Or just do it without the patch,
> should be good enough too.
>
> Just grap iw (from git.sipsolutions.net) and create a new monitor
> interface: ./iw dev wmaster0 interface add moni0 type monitor
> and then run tcpdump/wireshark on that.
iw does not build here :
cc -I/lib/modules/`uname -r`/build//include -Wall
-I/lib/modules/`uname -r`/build/include -g -c -o iw.o iw.c
iw.c:11:31: error: netlink/genl/genl.h: No such file or directory
iw.c:12:33: error: netlink/genl/family.h: No such file or directory
iw.c:13:33: error: netlink/genl/ctrl.h: No such file or directory
iw.c: In function 'nl80211_init':
iw.c:31: warning: implicit declaration of function 'genl_connect'
iw.c:37: warning: implicit declaration of function 'genl_ctrl_alloc_cache'
iw.c:37: warning: assignment makes pointer from integer without a cast
iw.c:44: warning: implicit declaration of function 'genl_ctrl_search_by_name'
iw.c:44: warning: assignment makes pointer from integer without a cast
iw.c:54: warning: implicit declaration of function 'nl_cache_free'
iw.c: In function 'nl80211_cleanup':
iw.c:62: warning: implicit declaration of function 'genl_family_put'
---
this headers do indeed not exist in /usr/include/netlink
commenting them out results into:
interface.c: In function 'handle_interface_add':
interface.c:82: warning: implicit declaration of function 'nlmsg_alloc'
interface.c:82: warning: assignment makes pointer from integer without a cast
interface.c:88: warning: implicit declaration of function 'genlmsg_put'
interface.c:88: warning: implicit declaration of function 'genl_family_get_id'
interface.c:91: error: invalid lvalue in unary '&'
interface.c:98: warning: passing argument 2 of 'nl_send_auto_complete'
from incompatible pointer type
interface.c: In function 'handle_interface_del':
interface.c:122: warning: assignment makes pointer from integer without a cast
interface.c:133: error: invalid lvalue in unary '&'
interface.c:135: warning: passing argument 2 of
'nl_send_auto_complete' from incompatible pointer type
make: *** [interface.o] Error 1
build tested on fedora 8
with libnl-devel-1.0-0.10.pre5.4
On Nov 28, 2007 8:47 PM, Johannes Berg <[email protected]> wrote:
>
>
> > > Just grap iw (from git.sipsolutions.net) and create a new monitor
> > > interface: ./iw dev wmaster0 interface add moni0 type monitor
> > > and then run tcpdump/wireshark on that.
> >
> > iw does not build here :
> > cc -I/lib/modules/`uname -r`/build//include -Wall
> > -I/lib/modules/`uname -r`/build/include -g -c -o iw.o iw.c
> > iw.c:11:31: error: netlink/genl/genl.h: No such file or directory
> > iw.c:12:33: error: netlink/genl/family.h: No such file or directory
> > iw.c:13:33: error: netlink/genl/ctrl.h: No such file or directory
>
> Yeah, you need libnl-pre8.
ok will rebuild libnl and do the tests on friday.
On Mon, 2007-11-26 at 13:14 +0100, Johannes Berg wrote:
> > what works:
> > connect to a hidden ssid with ap_scan=1 in wpa_supplicant.conf
> > what does not work:
> > connect to a hidden ssid with ap_scan=2 in wpa_supplicant.conf
> > ---
> > for non mac80211 drivers its the opposite ie. ap_scan=2 can connect to
> > hidden ssid while ap_scan=1 works
> > (thats also whats documented in the wpa_supplicant docs and what nm uses).
> >
> > so NM can't support mac80211 and non mac80211 drivers at the same time
> > without ugly hacks due to this issue.
>
> That's weird. But why does it use ap_scan=2 to start with? With
> mac80211, ap_scan=1 is *much* much better because it lets wpa_supplicant
> control much of roaming, mac80211 really is designed that way.
Because in the case of hidden SSIDs, wpa_supplicant pretty much says to
use ap_scan=2.
There are a few problems here:
1) Historically, some drivers worked better with ap_scan=1 (madwifi),
others worked better with ap_scan=2 (many fullmac drivers)
2) scan_ssid=1 hasn't worked consistently on all drivers because it's
pretty new and many drivers don't support it yet. This is supposed to
make the driver/firmware send out probe request for the SSID in
question.
So basically, we're up shit creek without a paddle. You have to use
ap_scan=2 on some cards because they don't support specific-ssid
scanning (with scan_ssid=1) to find the BSS you want to connect to, but
some cards can handle ap_scan=1+scan_ssid=1 OK.
NM has logic to cache the BSSIDs of APs you've connected to before, and
to match those up with an SSID when it sees them in the scan list if the
AP isn't broadcasting the SSID. Unfortunately, that information isn't
available to wpa_supplicant because wpa_supplicant doesn't have an
interface to handle that sort of thing. Therefore, when faced with an a
request to connect to a hidden network, wpa_supplicant must rely
_entirely_ on the driver Doing The Right Thing with scan_ssid=1 or
ap_scan=2, and that almost never works due to inconsistency in driver
implementation.
Dan
> I don't see why ap_scan=2 doesn't work though, can you enable some
> wpa_supplicant debugging and send me the logs? Or can you turn off
> encryption and see if you can connect to a hidden SSID? I'd think it
> should work because we do a directed scan so the probe response should
> tell us the SSID.
>
> johannes
On Sun, 2007-11-25 at 12:00 +0100, drago01 wrote:
> Johannes Berg wrote:
> > Hi,
> >
> >
> >> First sorry for the late report, the patches from the old thread fixed
> >> the privacy mismatch issue and now I can connect to a dynamic wep
> >> network. But the connection is not very stable because I get tons of wep
> >> decrypt errors in dmesg (while the connection is working but slow).
> >> The same network works fine with ipw3945. Also iwl3945 works fine with
> >> static wep. I tryed the hwcrypt engine (hwcrypt=1) but it did not change
> >> anything.
> >> While connectiong with wpa_supplicant I saw that mac80211 does not
> >> support the IW_AUTH_DROP_UNENCRYPTED ioctl while ipw3945 (ieee80211
> >> based) does.
> >> Could this be related? ie. mac80211 tryes to decrypt unencrypted frames
> >> instead of dropping them?
> >>
> >
> > Odd. I'll have to take a look. I recently noticed that mac80211 would
> > always *accept* unencrypted frames but it shouldn't try to decrypt them.
> >
> >
> ok thx, let me now if you need more info / tests.
> >> Second problem is that ssid is hidden. I was able to connect to it using
> >> iwl3945 (even with hw_scan) but only with ap_scan=1 (while ap_scan=2
> >> should be used for hidden ssid and thats what nm uses). Non mac80211
> >> based drivers do not work with ap_scan=1 but with ap_scan=2. So this
> >> needs to be fixed somehow so that nm can support both wireless stacks.
> >>
> >
> > Uh so say that again what works where and what doesn't?
> >
> >
> sorry for being confusing.
> what works:
> connect to a hidden ssid with ap_scan=1 in wpa_supplicant.conf
> what does not work:
> connect to a hidden ssid with ap_scan=2 in wpa_supplicant.conf
> ---
> for non mac80211 drivers its the opposite ie. ap_scan=2 can connect to
> hidden ssid while ap_scan=1 works
> (thats also whats documented in the wpa_supplicant docs and what nm uses).
>
> so NM can't support mac80211 and non mac80211 drivers at the same time
> without ugly hacks due to this issue.
Let me rant that ap_scan is the single thing that has given me the most
headaches with NetworkManager. It's simply impossible use correctly on
Linux. There's _got_ to be a better way to deal with hidden SSIDs.
Dan
Jouni Malinen wrote:
> On Mon, Nov 26, 2007 at 03:50:00PM +0100, dragoran wrote:
>
>> btw would it make sense to ratelimit
>>
>> "WEP decrypt failed (ICV)" messages?
>> they are a bit annoying when connected to this network...
>>
>> dmesg | grep ICV | wc -l
>> 3489
>>
>> after some minutes.
>>
>
> While I fully agree that these messages should be rate limited, it is
> somewhat surprising to see this large a number of reported ICV failures.
> Does the ipw3945 not filter out FCS errors before passing the frame for
> WEP decryption? Or is there something odd about this network/client
> configuration that makes the client try to decrypt frames that are not
> really for it?
>
this does not happen with the ipw3945 driver but with the iwl3945 so its
either something with this driver or mac80211.
Johannes Berg wrote:
> On Mon, 2007-11-26 at 15:50 +0100, dragoran wrote:
>
>> btw would it make sense to ratelimit
>>
>> "WEP decrypt failed (ICV)" messages?
>> they are a bit annoying when connected to this network...
>>
>> dmesg | grep ICV | wc -l
>> 3489
>>
>> after some minutes.
>>
>
> I think they're only shown in a DEBUG config, no?
>
>
looking at the code seems not:
---
if (ieee80211_wep_decrypt_data(local->wep_rx_tfm, rc4key, klen,
skb->data + hdrlen + WEP_IV_LEN,
len)) {
printk(KERN_DEBUG "WEP decrypt failed (ICV)\n");
ret = -1;
}
---
and here I have:
# CONFIG_MAC80211_DEBUG is not set
> > Just grap iw (from git.sipsolutions.net) and create a new monitor
> > interface: ./iw dev wmaster0 interface add moni0 type monitor
> > and then run tcpdump/wireshark on that.
>
> iw does not build here :
> cc -I/lib/modules/`uname -r`/build//include -Wall
> -I/lib/modules/`uname -r`/build/include -g -c -o iw.o iw.c
> iw.c:11:31: error: netlink/genl/genl.h: No such file or directory
> iw.c:12:33: error: netlink/genl/family.h: No such file or directory
> iw.c:13:33: error: netlink/genl/ctrl.h: No such file or directory
Yeah, you need libnl-pre8.
johannes
On Mon, 2007-11-26 at 19:49 -0800, Jouni Malinen wrote:
> On Mon, Nov 26, 2007 at 11:04:24AM -0500, Dan Williams wrote:
>
> > Because in the case of hidden SSIDs, wpa_supplicant pretty much says to
> > use ap_scan=2.
>
> Or ap_scan=1 with scan_ssid if and only if the driver supports it..
Right; but ap_scan=1 + scan_ssid is simply a _better_ way to achieve the
same end. All drivers should be able to handle ap_scan=2 and just
blowing the settings to the card with WEXT. Perhaps we should introduce
a WEXT capability bit that advertises the ability to scan specific SSIDs
(at least, cfg80211 should have something like this in its capability
bits) so that some intelligence can be used here.
But the point is, select the alternate, better-working code path where
you _explicitly_ know it works, rather than trying something that might
likely fail and trying to fall back after the failure to the catch-all.
That produces a better user experience, I believe, and is more robust in
the face of crappy drivers.
> > 2) scan_ssid=1 hasn't worked consistently on all drivers because it's
> > pretty new and many drivers don't support it yet. This is supposed to
> > make the driver/firmware send out probe request for the SSID in
> > question.
>
> This is not only a driver issue, though. I believe there are full MAC
> cards that do not support scan request with a specific SSID and the only
> way to make them work with hidden SSIDs is to try to associate with the
> SSID (i.e., use ap_scan=2).
>
> In theory, wpa_supplicant could try to figure out whether the scan with
> a specific SSID works or not (though, this is not that easy to do since
> old drivers are likely to just ignore the provided SSID and do a
Yeah, this seems like something you don't really want to do. It's too
complicated, raises latency of a successful connection, and is ugly.
Don't do it :)
> wildcard scan) and if that is the case, start probing the network with
> ap_scan=2 like behavior. This would mean that it would go through the
> configured networks and try to associate with each that is enabled and
> marked with scan_ssid=1. If association is completed successfully, the
> network could be added to scan results (at this point, the driver would
> also be more likely to actually include it in the scan results, so
> proper data could now be available).
>
> The main problem with this is that it can take quite long time to do
> this kind of association probing just to be able to get scan results.
> Furthermore, at least some cards may require a full match in security
> parameters, i.e., each SSID could potentially require multiple
> association attempts (assuming the network block was not configured with
> explicit security parameters).
>
> Taken into account how much I like hidden SSIDs, I would likely just
> prefer to ignore the issue and try to make people use proper security
> with visible SSIDs if they want to limit access to their network. Use of
> hidden SSIDs is just plain horrible way of making clients suffer without
> any level of increased security.
Yep. We want to encourage less breakage. But we do run into the case
where one SSID is hidden with different security settings coming from
the same BSSID as a broadcasted SSID, which is out there in quite a few
places. Somebody (Cisco?) must have recommended that at one point when
APs were more expensive.
Dan
On Mon, 2007-11-26 at 15:50 +0100, dragoran wrote:
> btw would it make sense to ratelimit
>
> "WEP decrypt failed (ICV)" messages?
> they are a bit annoying when connected to this network...
>
> dmesg | grep ICV | wc -l
> 3489
>
> after some minutes.
I think they're only shown in a DEBUG config, no?
johannes
Johannes Berg wrote:
>> Because in the case of hidden SSIDs, wpa_supplicant pretty much says to
>> use ap_scan=2.
>>
>> There are a few problems here:
>>
>> 1) Historically, some drivers worked better with ap_scan=1 (madwifi),
>> others worked better with ap_scan=2 (many fullmac drivers)
>>
>> 2) scan_ssid=1 hasn't worked consistently on all drivers because it's
>> pretty new and many drivers don't support it yet. This is supposed to
>> make the driver/firmware send out probe request for the SSID in
>> question.
>>
>> So basically, we're up shit creek without a paddle. You have to use
>> ap_scan=2 on some cards because they don't support specific-ssid
>> scanning (with scan_ssid=1) to find the BSS you want to connect to, but
>> some cards can handle ap_scan=1+scan_ssid=1 OK.
>>
>
> Fun. I'm pretty sure mac80211 handles ap_scan=1/scan_ssid=1 fine,
> sending probe requests for that specific SSID.
>
>
yes it does an work fine that way. but ap_scan=2 = no go.
I can get some logs tomorrow for you.
If I remeber correctly wpa_supplicant just says "Got X scan results" and
never find the ssid asked for.
>> NM has logic to cache the BSSIDs of APs you've connected to before, and
>> to match those up with an SSID when it sees them in the scan list if the
>> AP isn't broadcasting the SSID. Unfortunately, that information isn't
>> available to wpa_supplicant because wpa_supplicant doesn't have an
>> interface to handle that sort of thing. Therefore, when faced with an a
>> request to connect to a hidden network, wpa_supplicant must rely
>> _entirely_ on the driver Doing The Right Thing with scan_ssid=1 or
>> ap_scan=2, and that almost never works due to inconsistency in driver
>> implementation.
>>
>
> Who invented hidden SSIDs anyway? Well, I guess I can actually test this
> now that I finally have a second mac80211-based wireless card, although
> iwl4965 is special wrt. scanning. I guess the trick will be to make
> ap_scan=2 work although ap_scan=1/scan_ssid=1 works much better :(
>
>
well a "fix" would be for nm to try ap_scan=2 when it fails fall back to
ap_scan=1 + scan_ssid=1 bt thats nothing more than a hack.
> We can fix that in nl80211 by making sure that scan_ssid is implemented
> right away and whoever has nl80211 support needs to support that so that
> we can rely on it...
>
yes that should finally fix it ... but until then we need something that
works.
btw would it make sense to ratelimit
"WEP decrypt failed (ICV)" messages?
they are a bit annoying when connected to this network...
dmesg | grep ICV | wc -l
3489
after some minutes.
Johannes Berg wrote:
> Hi,
>
>
>> First sorry for the late report, the patches from the old thread fixed
>> the privacy mismatch issue and now I can connect to a dynamic wep
>> network. But the connection is not very stable because I get tons of wep
>> decrypt errors in dmesg (while the connection is working but slow).
>> The same network works fine with ipw3945. Also iwl3945 works fine with
>> static wep. I tryed the hwcrypt engine (hwcrypt=1) but it did not change
>> anything.
>> While connectiong with wpa_supplicant I saw that mac80211 does not
>> support the IW_AUTH_DROP_UNENCRYPTED ioctl while ipw3945 (ieee80211
>> based) does.
>> Could this be related? ie. mac80211 tryes to decrypt unencrypted frames
>> instead of dropping them?
>>
>
> Odd. I'll have to take a look. I recently noticed that mac80211 would
> always *accept* unencrypted frames but it shouldn't try to decrypt them.
>
>
ok thx, let me now if you need more info / tests.
>> Second problem is that ssid is hidden. I was able to connect to it using
>> iwl3945 (even with hw_scan) but only with ap_scan=1 (while ap_scan=2
>> should be used for hidden ssid and thats what nm uses). Non mac80211
>> based drivers do not work with ap_scan=1 but with ap_scan=2. So this
>> needs to be fixed somehow so that nm can support both wireless stacks.
>>
>
> Uh so say that again what works where and what doesn't?
>
>
sorry for being confusing.
what works:
connect to a hidden ssid with ap_scan=1 in wpa_supplicant.conf
what does not work:
connect to a hidden ssid with ap_scan=2 in wpa_supplicant.conf
---
for non mac80211 drivers its the opposite ie. ap_scan=2 can connect to
hidden ssid while ap_scan=1 works
(thats also whats documented in the wpa_supplicant docs and what nm uses).
so NM can't support mac80211 and non mac80211 drivers at the same time
without ugly hacks due to this issue.
> While I fully agree that these messages should be rate limited, it is
> somewhat surprising to see this large a number of reported ICV failures.
> Does the ipw3945 not filter out FCS errors before passing the frame for
> WEP decryption? Or is there something odd about this network/client
> configuration that makes the client try to decrypt frames that are not
> really for it?
I agree. We have the following chunk of code in the decrypt handler:
/*
* No point in finding a key and decrypting if the frame is neither
* addressed to us nor a multicast frame.
*/
if (!(rx->flags & IEEE80211_TXRXD_RXRA_MATCH))
return TXRX_CONTINUE;
the RA_MATCH flag is cleared when the frame is neither multicast nor
addressed to us so I don't see how we can get into WEP decryption. A
concurrently running tcpdump might help though without the keys it'd be
hard to verify everything.
The fact that ipw3945 doesn't print out any such messages is hardly
indicative of a mac80211 problem btw, maybe it simply doesn't contain
such debug messages.
johannes
On Dec 4, 2007 7:57 AM, dragoran <[email protected]> wrote:
>
> On Dec 3, 2007 12:47 PM, dragoran <[email protected]> wrote:
> > It seems not to happen today (with an updated kernel 2.6.23.9-77.fc8;
> > which contains recent wireless updates from #everything).
> > I don't know if its fixed or if the I am just not receiving crap right
> > now... but will be connected for ~4hours to this ap now..
> > will report if it happens or not until then...
> >
>
> ok confirmed it does no longer happen with the updated kernel.
> maybe the drop_unencrypted stuff fixed it...
>
I was wrong ... it happened again...
will try the to create the dump sometime this week and send it to you.
On Dec 3, 2007 12:47 PM, dragoran <[email protected]> wrote:
> It seems not to happen today (with an updated kernel 2.6.23.9-77.fc8;
> which contains recent wireless updates from #everything).
> I don't know if its fixed or if the I am just not receiving crap right
> now... but will be connected for ~4hours to this ap now..
> will report if it happens or not until then...
>
ok confirmed it does no longer happen with the updated kernel.
maybe the drop_unencrypted stuff fixed it...
It seems not to happen today (with an updated kernel 2.6.23.9-77.fc8;
which contains recent wireless updates from #everything).
I don't know if its fixed or if the I am just not receiving crap right
now... but will be connected for ~4hours to this ap now..
will report if it happens or not until then...
> Unfortunately no. I remember you sending a patch "adding proper monitor
> mode to iwl4965" .. has this ever been ported to iwl3945 ?
Yes, but it doesn't show the FCS since I didn't know whether it would be
present in the frame when it's received from the card.
> Can do this (next week)
[...]
> I cannot say for sure now but last time I looked at the wpa_supplicant
> -ddd output while this was happening nothing was printed at all. But I
> will do this again and let you know.
Thanks.
johannes
Johannes Berg wrote:
> Hmm.
>
> Not really very helpful. Do you have the WEP key that was in use at that
> time?
no .. (have not stored it somewhere)
> Also, did the message actually occur during this dump?
>
>
Yes and not only once ;)
> Is there any way to get the FCS of packets up to mac80211 from the
> iwlwifi drivers, or is it already snipped off by the firmware?
>
> Maybe you have a separate device you could capture traffic with?
> Preferably not iwlwifi, it seems to have trouble in monitor mode, at
> least my iwl4965 doesn't really seem to see traffic in foreign BSSes.
>
>
Unfortunately no. I remember you sending a patch "adding proper monitor
mode to iwl4965" .. has this ever been ported to iwl3945 ?
> Could you amend the failing printk to something like:
>
> DECLARE_MAC_BUF(mac1);
> DECLARE_MAC_BUF(mac2);
>
> [...]
>
> printk(KERN_DEBUG "WEP decrypt failed (ICV, A1=%s, A2=%s, seq=%x, wepidx=%d\n",
> print_mac(mac1, hdr->addr1), print_mac(mac2, hdr->addr2),
> le16_to_cpu(hdr->seq_ctrl), keyidx)
>
> Then start a packet capture and wait until the message occurs. Once it
> does, quickly run "iwlist key" as root to know what keys are currently
> in use and send me both the keys and the failing packet.
>
>
Can do this (next week)
> Also, please see if maybe the printk is correlated (in time) with
> rekeying, the wpa_supplicant output (maybe with -dd) should tell you.
>
>
I cannot say for sure now but last time I looked at the wpa_supplicant
-ddd output while this was happening nothing was printed at all. But I
will do this again and let you know.
thx
Hmm.
Not really very helpful. Do you have the WEP key that was in use at that
time? Also, did the message actually occur during this dump?
Is there any way to get the FCS of packets up to mac80211 from the
iwlwifi drivers, or is it already snipped off by the firmware?
Maybe you have a separate device you could capture traffic with?
Preferably not iwlwifi, it seems to have trouble in monitor mode, at
least my iwl4965 doesn't really seem to see traffic in foreign BSSes.
Could you amend the failing printk to something like:
DECLARE_MAC_BUF(mac1);
DECLARE_MAC_BUF(mac2);
[...]
printk(KERN_DEBUG "WEP decrypt failed (ICV, A1=%s, A2=%s, seq=%x, wepidx=%d\n",
print_mac(mac1, hdr->addr1), print_mac(mac2, hdr->addr2),
le16_to_cpu(hdr->seq_ctrl), keyidx)
Then start a packet capture and wait until the message occurs. Once it
does, quickly run "iwlist key" as root to know what keys are currently
in use and send me both the keys and the failing packet.
Also, please see if maybe the printk is correlated (in time) with
rekeying, the wpa_supplicant output (maybe with -dd) should tell you.
johannes