Hi, I am currently using a Cisco Autonomous access point in monitor mode. I forward the captured frames to my pc using an UDP port that is not open (that is why you will only see odd numbers in the captures) and capture it with Wireshark configured with the correct CWIDS port. The problem I got is that the frames that contain the EAPoL messages are misread and so I cannot decrypt my data. When looking more deeply in the QoS data header I noticed that the QoS Control flags were set at 0xaaaa which corresponds exactly to the 2 first byte of the LLC header (SNAP). If I look at the rest of the frame in hexa and do not consider the QoS Control field then I am able to find the LLC header and the EAPoL header. Is that normal? This could be a Cisco-side bug in their monitor mode but I saw you had the same kind of problem with PEEKREMOTE frames in old versions of the software so I decided to ask the question. You will find a capture in the 1.12 and another in the 2.0.3 versions. Thanks in advance for your answers, YB
asked 09 May '16, 07:56  Yonibley |
One Answer:
As both dissectors were originally written by me (and a third one I wrote also has that problem) I should probably take a look at the fix in peekremote to find out what I don't understand so far :-) Can you please open a bug, attach a sample capture (it you are worried about private data, set the private flag for the attachment) and assign it to me (jmayer at loplof de) answered 09 May '16, 13:48  jmayer +1 - doing all those things will make it a lot easier for us to figure out what's happening and, if possible, make it happen the way it's supposed to happen, and thus will make it a lot more likely that this problem will be fixed. I'm guessing that either 1) the CWIDS header isn't as long as our dissector thinks it will be, and we're treating some byte in the middle of the 802.11 header as being at the beginning of the 802.11 header (and thus treating bytes in the LLC header as if they're part of the 802.11 header) or 2) the 802.11 header is somehow mangled in the packets that the Cisco AP is sending out (and perhaps there's something in the CWIDS header to tell us this). The joys of reverse engineering - we don't have a spec for CWIDS so we have to guess how it works. (09 May '16, 23:10) Guy Harris ♦♦ Well, that could just be off by 2 bytes - the aa aa 03 is an 802.2 header, which appears right after the 802.11 header. If we could see the 2 bytes before what Wireshark is claiming to be the frame control field, that would be interesting. It would also be interesting to see the full dissection of the Cisco WIDS header. But don't put that as answers or further comments in this item, add them to the bug which you will have filed first. (09 May '16, 23:58) Guy Harris ♦♦ And if the problem with peekremote was bug 9586, then it's somewhat similar, in that both bugs might be due to not handling newer versions of the headers, but Wildpackets^WSavvius and Cisco are different companies, so it's not as if Savvius's protocol design had anything to do with Cisco's protocol design - there might be no connection between the two issues other than "both protocols encapsulate 802.11 packets and send them over the wire". (10 May '16, 00:04) Guy Harris ♦♦ |
I saw that A-MSDU is being used (Aggregate MSDU). I am wondering if the A-MSDU is causing an error in deciphering the information in Wireshark.
Is it possible to disable A-MSDU and re-capture?
May be a wild guess, but it is strange behavior.