Bugzilla – Full Text Bug Listing |
Summary: | mesh example producing malformed pcaps | ||
---|---|---|---|
Product: | ns-3 | Reporter: | Tom Henderson <tomh> |
Component: | mesh | Assignee: | 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
Created attachment 1821 [details]
bugged trace
Note that the example contains another "bug". Data is sent from the source, but the echo is not received back. 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) 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. 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
Created attachment 2100 [details]
set header to type QoS Data instead of Data
Created attachment 2101 [details]
set MeshControlPresent flag in the QoS Control field
patches pushed in changesets 11584:42b7c1e05e11 and 11585:a4ee9fd2ae07 |