mac80211 / iwl3945 + dynamic wep (again)

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?

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.

Hi,

Quoted 5 lines

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.

Quoted 2 lines

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?

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.

Quoted 5 lines · dragoran

btw would it make sense to ratelimit

"WEP decrypt failed (ICV)" messages?
they are a bit annoying when connected to this network...

Quoted 5 lines

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;
    }

---

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.

Quoted 10 lines · dragoran

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.

Quoted 3 lines

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.

Quoted 5 lines

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

Quoted 6 lines

Quoted 5 lines

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.

Quoted 6 lines

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.

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.

Unfortunately no. I remember you sending a patch "adding proper monitor mode to iwl4965" .. has this ever been ported to iwl3945 ?

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.

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?

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...

Quoted 6 lines · dragoran

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...

Quoted 17 lines · Johannes Berg

Hi,

Quoted 4 lines

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).

Quoted 9 lines

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?

Quoted 4 lines

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.

Quoted 10 lines

Quoted 6 lines

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.

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.

Quoted 9 lines

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).

Quoted 2 lines

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

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.

Quoted 13 lines

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.

Quoted 5 lines

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.

Quoted 10 lines

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...

Because in the case of hidden SSIDs, wpa_supplicant pretty much says to use ap_scan=2.

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.

Quoted 2 lines · Dan Williams

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..

Quoted 4 lines

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.

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?