Re: Malformed packet 802.11 A-MSDU subframe length

[Guy Harris <guy () alum mit edu>]

On Apr 26, 2017, at 6:50 AM, Levente Mészáros <levente.meszaros () gmail com> 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.
___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev () wireshark org>
Archives:    https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request () wireshark org?subject=unsubscribe