Rather than drift the thread this problem was originally brought up here
I thought I'd start a new one on this topic.
From the log you posted, it appears that the driver is silently failing on handshake message three when AES encryption is tried.
There are a couple of places where a failure can occur without a debug message being issued. The attached small patch adds debug messages there.
Could you try it on a vanilla version of the latest CVS and attach a copy of the debug log to a posting here?
Here they are (debug=31). My setup hasn't changed at all since the last time. The first part of the debug is using TKIP, then I switched to AES.
It turns out that the slightly different command sequences you used for the logs posted 9/2/07 as compared to what was used on the logs posted 8/31/07 also changed the software timing enough so that - although AES still fails - the behavior that the small patch was intended to observe did not occur.
As far as I can tell, the command sequences used both times are, or should be, entirely valid. That they don't have the intended effect I consider to be a bug in the driver. Event driven systems can change behavior pretty significantly in response to seemingly very minor changes in stimuli.
Could you (flinch, flinch) try the patch again using the exact same sequence of commands - if possible - as was used when the 8/31/07 logs were generated? e.g.
Set auth to WPA-PSK
Set encrypt to AES
Set key value
Here are the new traces, I made sure that the extra info are printed.
I'm not 100% sure, but I think I had to scan to have them printed, if that can help.
It looks like the driver doesn't like something about handshake message 3 from the AP when AES is used. Something in the frame - other than the encryption specification - causes the driver to silently ignore it.
I've modified the patch yet again to print the frame date for handshake message 3 when compiled with debug enabled and invoked with debug=8. Probably debug=15 gives a better idea of context, though.
Could you try it for both AES and TKIP? Hopefully the info will give me enough to go on that I can actually come up with a fix.
The patch is attached in the file chkeap1.patch.gz. You can apply it to a vanilla copy of the latest CVS.
Thanks for working this into your spare time, here. Maybe we can get an improved driver out of this.
Thank you for looking into this. I started with TKIP, then I switched to AES. I couldn't generate a "WPA EAP IE needed" with TKIP, but it could be because there's no problem with this cipher. All traces have been generated with the highest level of verbosity debug=31.
Thanks for the logs. No "WPA EAP IE needed" with TKIP is a good thing.
The log info shows that the size and leading content of the EAPOL frame sent by the AP is the same for all practical purposes for both AES and TKIP. Unfortunately, I screwed up the frame is too big to be printed in its entirety (I should have known) and so does not include the key data - which is what we really need.
So, I've set up yet another patch and its attached to this post as "chkeap2.patch.gz". This one only prints out the key data portion of the EAPOL packet for handshake message 3 when debug is enabled.
As your schedule permits, could you give it a try?
Sorry, and thanks,
Like the precedent, these have been generated with debug=31. If you would prefer a lower level, or just one file, just tell me.
Well, you do good work, you rascal, you.
It turns out the AP sends exactly the same key data regardless of whether the driver is configured for TKIP or AES encryption. FYI, here's how it parses
[code183un5vb] ver grp ciph cnt pair ciphers AKM
TKIP - dd 1c 0050f201 0100 0050f202 0200 0050f204 0050f202 0100 0050f202 0000
AES - dd 1c 0050f201 0100 0050f202 0200 0050f204 0050f202 0100 0050f202 0000
^ -- -- -- --
| TKIP CCMP TKIP PSK
See e.g. lines 22032 and 38238 of your latest debug.gz.
What it says is that it offers TKIP only for the group cipher, and our choice of CCMP or TKIP for our pairwise cipher. Authentication and key management are PSK. The problem arises because the driver only allows a single cipher type to be specified, and that is used for both group and pairwise encryption. When the driver looks at this stuff, it finds a mismatch between what the AP offers for group encryption and what it's configured with, and silently ignores the frame.
Since the AP's behavior is consistent with the spec, I think this has to be deemed a bug in the driver. However, adding the capability to separately specify group and pairwise cipher schemes is a non- trivial exercise. The capability does need to be there, but I don't think Wireless Extensions provides for that yet. So we'd have to use some sort of private command to do it.
It looks like the rt61 driver "works" because it only checks the key descriptor version, MIC, nonce, and replay count. This is sorta OK because the key descriptor version tells it if CCMP is used for neither group nor pairwise cipher (a value of 1), or for either (a value of 2) - see 802.11i pp. 78. It basically ignores the key data field, and thereby accepts a group cipher scheme it is not configured for. (Shows how often the group cipher is actually used.)
One possible workaround may be to try to somehow cajole your AP into offering CCMP group encryption.
Thanks again for all your work here,
Hi Vern, sorry for the late reply, I had a long week.
One possible workaround may be to try to somehow cajole your AP into offering CCMP group encryption.[/quote291j1bjl]
I don't think this will be possible, the AP is a Neuf Box, and it doesn't really offer any advanced option, otherwise I would have turned off mixed TKIP-AES and use AES only. I can only choose between WEP and WPA TKIP-AES, nothing else.
I don't mind at all sticking with TKIP since it works fine, so if you cannot fix that easily, it's no problem.
If you decide to go through, I can always provide traces.
Thank you for looking into this,
I guess there're policy questions as well as technical issues to be looked at before jumping in. For example, should we just ignore the group cipher spec? Seems to work OK for the rt61 driver.
Yes, it would be fine if rt2500 behaves like rt61. Or perhaps, the driver could switch to the cipher group reported by the ap if it's close enough from the one it's currently configured to use, though I think the first approach is better since it doesn't override user space settings.
I'll post a patch that pretends the group cipher matches when we find the pairwise cipher matches Soon.
Just as a matter of interest, what do the Neuf Box folks have to say about the matter?
What do you mean? Should I contact the support?
It may be helpful. What I suspect is that, although the Neuf Box AP's behavior is consistent with the spec, it may not be what Cegetel really intends.
The reason I say it is that it would seem logical that if CCMP is used for pairwise message encryption, they would wish to use it for group message encryption also, rather than TKIP, which - after all - is not really quite as strong as CCMP. It is not incoceivable that they actually do so, regardless of what is indicated in the RSN IE they include in the handshake message.
I'm not sure this is the case, but it may be worthwhile to draw their attention to the question.
Ok, I'll see if I can find someone to talk to, this is very technical and the hotline will probably not be able to answer.
The attached patch handles the Cegetel problem by pretending that the AP has a comparable group cipher scheme if the driver finds that it has a comparable pairwise cipher scheme.
Could you try it? If it works for you, I think I'll just dump it into CVS.
Ok, I won't be back home before next friday (the 12th) though.
Edit Well done, it is working for me!
In CVS. Thanks for the work.