Bug 1482

Same error occurred when I use to create netanim xml file by just adding following code at line 237

AnimationInterface anim ("mesh-animation.xml");
anim.EnablePacketMetadata (true);

The error was:

>'build' finished successfully (14.013s)
>msg="Information element 27 is not implemented", file=../src/wifi/model/wifi- >information-element-vector.cc, line=90
>terminate called without an active exception

The problem cause is that mesh Information Elements (IEs) are defined on the specific files mesh-information-element-vector.h/.cc and not on the wifi implementation IEs (information-element-vector.cc). As an IE definition, in my opnion, it should be implemented on wifi model, regardless the 802.11 amendment.

Therefore, the solution could be either move the mesh IE definition and implemetation to wifi model or to force the AscciiTrace to search at mesh IEs (which seems to be a bad choice).

I'll try to look in depth to this problem...

Going deep into this issue, we will find out that the AsciiTrace will call somewhere the method ns3::Packet::Print which will recognize the presence of Information Elements (in the mesh example). Therefore, in order to read the IEs (which was previously added to the packet as a MeshInformationElementVector set) the method ns3::WifiInformationElementVector::Deserialize will be called, following by the ns3::WifiInformationElementVector::DeserializeSingleIe to deserialize each IE on the packet.

However, the method is unable to recognize any IE, as it was implemented as a virtual class. In this manner, only the ns3:MeshInformationElementVector can do this. 

In my opinion, to implement the ns3::WifiInformationElementVector as a virtual class makes not much sense as the IEs are part of the 802.11 standard (wifi) regardless the amendment (802.11n, 802.11s...).

My sugestion is to move the definition of any IE to the wifi model (from mesh or any other which makes use of IEs) to the wifi model and let the  ns3::WifiInformationElementVector to deserialize and hence instanciate each IE on the packet. 

I think by this way we can solve both problems with AsciiTrace and netanim regarding to mesh example (as it is the unique example that includes a vector of IEs direct to the packet and try to get them back from a vector again).

Any comments would be greatly appreciated... (even to say that I am wrong)

Hi,
Any way to move this forward?
-john

(In reply to comment #3)
> Going deep into this issue, we will find out that the AsciiTrace will call
> somewhere the method ns3::Packet::Print which will recognize the presence of
> Information Elements (in the mesh example). Therefore, in order to read the IEs
> (which was previously added to the packet as a MeshInformationElementVector
> set) the method ns3::WifiInformationElementVector::Deserialize will be called,
> following by the ns3::WifiInformationElementVector::DeserializeSingleIe to
> deserialize each IE on the packet.
> 
> However, the method is unable to recognize any IE, as it was implemented as a
> virtual class. In this manner, only the ns3:MeshInformationElementVector can do
> this. 
> 
> In my opinion, to implement the ns3::WifiInformationElementVector as a virtual
> class makes not much sense as the IEs are part of the 802.11 standard (wifi)
> regardless the amendment (802.11n, 802.11s...).
> 
> My sugestion is to move the definition of any IE to the wifi model (from mesh
> or any other which makes use of IEs) to the wifi model and let the 
> ns3::WifiInformationElementVector to deserialize and hence instanciate each IE
> on the packet. 
> 
> I think by this way we can solve both problems with AsciiTrace and netanim
> regarding to mesh example (as it is the unique example that includes a vector
> of IEs direct to the packet and try to get them back from a vector again).
> 
> Any comments would be greatly appreciated... (even to say that I am wrong)

Created attachment 2109 [details]
patch to move wifi information element

move definition of Wifi information element IDs from mesh to wifi module; implement more fully the WifiInformationElementVector header class

Created attachment 2110 [details]
split PeerLinkFrameStart header

split PeerLinkFrameStart header into different header types, avoiding the need to set the header type before deserializing

The attached two patches fix the basic issue that has been preventing ascii trace, animation trace, and pyviz from working with mesh module.  The issue that Silvio mentioned is fixed by the first patch.  The second patch fixes an issue in that action frames such as peer link open could not be deserialized without side information about the header type; this side information was not available in the tracing code.

There is still some additional work that can be done:
- mesh.cc animation XML causes my installation of NetAnim to freeze
- Print() methods of some of the information elements are unimplemented

*** Bug 1483 has been marked as a duplicate of this bug. ***

Created attachment 2113 [details]
fix mesh-related print methods

This patch fixes the remaining issues:
- mesh animation freezes (due to multi-line packet header Print() output)
- formatting of Print() methods, and implementation of missing ones

patches pushed in changesets 11587:38e93ba5afa5, 11588:5a52126492c1, and 11589:d3bfef4544ec

It's back... just a different IE.

msg="Information element 0 is not implemented", file=../src/wifi/model/wifi-information-element-vector.cc, line=98

(In reply to Tommaso Pecorella from comment #11)
> It's back... just a different IE.
> 
> msg="Information element 0 is not implemented",
> file=../src/wifi/model/wifi-information-element-vector.cc, line=98

This is a specific instance of bug 2505, so I will close it here, and post patches there (I have a patch to fix but it requires network module changes).

The actual problem here is that the Deserialize reads past its boundary, and shouldn't read what it thinks is "Information element 0".  It reads past its boundary because it is a list of TLVs and it doesn't know where the list ends, at the point of deserialization.

The packet metadata has this length information, however, so it can be used with a different variant of Deserialize (to be added to the ns3::Chunk class).

closing it as 'Moved to bug 2505"