Bug 1901

Summary: mesh example producing malformed pcaps
Product: ns-3 Reporter: Tom Henderson <tomh>
Component: meshAssignee: Tom Henderson <tomh>
Status: RESOLVED FIXED    
Severity: normal CC: ns-bugs, tommaso.pecorella
Priority: P5    
Version: pre-release   
Hardware: PC   
OS: Linux   
Attachments: bugged trace
set header to type QoS Data instead of Data
set MeshControlPresent flag in the QoS Control field

Description Tom Henderson 2014-04-21 11:18:48 EDT
To reproduce:

./waf --run "mesh --pcap=1"

examine the first pcap mp--0-1.pcap; packet 2 MeshPeering Open (among others) displays as "malformed" in Wireshark.

Reported on ns-3-users list.
Comment 1 Tommaso Pecorella 2014-04-21 17:34:06 EDT
Created attachment 1821 [details]
bugged trace
Comment 2 Tommaso Pecorella 2014-04-21 17:35:10 EDT
Note that the example contains another "bug". Data is sent from the source, but the echo is not received back.
Comment 3 Tom Henderson 2014-04-22 10:27:18 EDT
A user provided more information about this here:

https://groups.google.com/d/msg/ns-3-users/ij_wTw2mElI/k-igdeBrZr0J


I don't think that we should keep this open for updating to the standard.  I'd suggest two action items here:

1) update documentation here:
http://www.nsnam.org/docs/models/html/mesh.html

to account for the information provided in the above post

2) look into whether the example is functioning correctly (Tommaso's point)
Comment 4 Tom Henderson 2015-07-17 18:28:48 EDT
Here is an update on this bug.

As of ns-3.23, Christopher Hepner's contribution fixed the packet formats to be compliant to the standard (and to Wireshark):

* Category codes and the categories compliant to IEEE-802.11-2012 Table 8-38—Category values.
* Information Elements (An adjustment of the element ID values was needed according to Table 8-54 of IEEE-802.11-2012).
* Mesh Peering Management element format changed according to IEEE-802.11-2012 Figure 8-370.
* Mesh Configuration element format changed according to IEEE-802.11-2012 Figure 8-363.
* PERR element format changed according to IEEE-802.11-2012 Figure 8-394.

So the mesh frames are now compliant, but there is a lingering pcap-related bug.  The data frames (e.g. carrying UDP) are not displayed correctly in wireshark above the mesh layer.  The IEEE 802.11 frame is of type Data frame/Subtype 0 (not QoS).  However at the end of the header are some additional bytes which should not be there and therefore the higher layers of the packet can't be parsed correctly by Wireshark.  The additional bytes are: "00 1d 00 00 00 00".

The incorrect application level behavior mentioned by Tommaso is due to bugs 1605/912.
Comment 5 Tom Henderson 2015-07-24 16:48:56 EDT
Attached two patches should fix this.

> The IEEE 802.11 frame is of type Data frame/Subtype 0 (not QoS).  However at 
> the end of the header are some additional bytes which should not be there and 
> therefore the higher layers of the packet can't be parsed correctly by 
> Wireshark.  The additional bytes are: "00 1d 00 00 00 00".

The first patch sets the frame type to be of QoS Data instead of plain Data; this is required for mesh.  The second patch sets the missing Mesh Control Present flag in the QoS Control field; this is needed for wireshark to parse the additional bytes of the MeshHeader listed above (e.g. the '1d' shown above is the mesh control field TTL value).

With these patches, the mesh tests that rely on pcap will fail and need to be regenerated.  devices-mesh-dot11s-regression and devices-mesh-flame-regression
Comment 6 Tom Henderson 2015-07-24 16:50:05 EDT
Created attachment 2100 [details]
set header to type QoS Data instead of Data
Comment 7 Tom Henderson 2015-07-24 16:50:43 EDT
Created attachment 2101 [details]
set MeshControlPresent flag in the QoS Control field
Comment 8 Tom Henderson 2015-08-17 18:59:51 EDT
patches pushed in changesets 11584:42b7c1e05e11 and 11585:a4ee9fd2ae07