> My current paranoid theory is that the M$ setup CD configures the > WPA2 with a binary key, derived from the passphrase by a proprietary > password hash that only Windows uses. In several days of googling > this problem, I've seen several claims that M$ has 2 password hashes > that it tries with WPA2 (thus enabling Windows to also work with > standard APs). M$ had an excuse for that with WEP, since it hadn't > been standardized yet, but not with WPA2.
Interesting... It should be possible to prove this "two hash functions" theory from packet captures: some of them should show TWO connection attempts, the first attempt _failing_ with the mismatched hash function. Note that I said "some captures": the first hash function tried by Windows could well be the correct one by chance and then you will not see anything unusual. Then you need to capture against the other AP style. Another way to prove this two hash functions theory would be to try and fail to decrypt traffic with your problematic AP. Aircrack-ng has normally zero problem decrypting a WPA capture as long as: 1. you give it the key, and 2. the capture includes the initial handshake. So seeing aircrack-ng fail would strongly support your theory. Warning: this tool has a lot of quirks, so first make sure you can make it work on your system by decrypting at least _another_, non-problematic WPA capture. Please keep us updated. Note: as a lesser sin, maybe Windows just implemented some hash before the WPA standard was completed and then left it there. Just a wild guess... _______________________________________________ networkmanager-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/networkmanager-list
