On Apr 26, 2017, at 6:50 AM, Levente Mészáros <levente.meszaros@xxxxxxxxx> wrote:
> I have a PCAP file which contains a fragmented 802.11 A-MSDU. At the last frame where reassembly happens, Wireshark tells me: Malformed Packet (Exception occured). After analyzing the issue carefully, I came to the conclusion that there might be a bug in Wireshark.
>
> The reason being is that if I change the simulator to write the MSDU subframe header length field in little endian byte order, then the packet validation error goes away. In this case, I can see all MSDUs properly in the reassembled A-MSDU.
>
> Unfortunately, at the same time a new error appears due to incorrect MSDU length during dissecting. I think the error is caused by the fact that the packet validator assumes little endian byte order, while the dissecting code *correctly* assumes big endian byte order as required by the standard.
That's *extremely* unlikely to be the case.
"Malformed Packet (Exception occured)" means, in almost all cases, that the validation being done is "make sure you don't run past the end of the packet"; it's not doing any detailed validation of particular fields, it's just doing bounds checks in the *very* low-level "fetch the value of a field from the packet" code, used by the dissecting code, that knows nothing about 802.11. That validation isn't done by a piece of code completely separate from the dissecting code, it's done as part of the dissecting process.
> I found this to be related to the following bug report: https://www.wireshark.org/lists/wireshark-bugs/201302/msg00166.html
bugs.wireshark.org is back, and the bug in question is at
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=8305
and Alexis La Goutte says there, in a comment:
> After some verification, there is a not a bug in Wireshark. (I think it is a bug in your network simulator...)
>
> The Subframe length is in "big endian format (network order)" and not little endian
>
> From 802.11-2012 : 8.3.2.2 A-MSDU format
> [...]
> The A-MSDU subframe header contains three fields: DA, SA, and Length. The order of these fields and the bits within these fields are the same as the IEEE 802.3 frame format
> [...]
>
> IEEE 802.3 Frame format use network to host order (big endian)
> I am using Wireshark 2.0.2. Could somebody give me some hints whether I'm right or wrong?
We'd probably need to see the capture to determine where the error is occurring.