Bug 1483 - Fatal Error while generating netanim trace for 802.11s Mesh network simulation
Fatal Error while generating netanim trace for 802.11s Mesh network simulation
Status: RESOLVED DUPLICATE of bug 1482
Product: ns-3
Classification: Unclassified
Component: mesh
ns-3.14
All All
: P5 normal
Assigned To: Kirill Andreev
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2012-08-06 05:07 UTC by Ehsan Elahi
Modified: 2015-08-07 01:26 UTC (History)
6 users (show)

See Also:


Attachments
Mesh.cc file with netanim code added (8.73 KB, application/octet-stream)
2012-08-06 05:07 UTC, Ehsan Elahi
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Ehsan Elahi 2012-08-06 05:07:19 UTC
Created attachment 1433 [details]
Mesh.cc file with netanim code added

I just modified mesh.cc file to generate xml file for netanim. I added two lines at 232 and 233 as given in the attached file. Following error occurred:

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


For me its a very critical bug because I'm actively working on IEEE 802.11s mesh network simulation.
Comment 1 Ehsan Elahi 2012-08-06 05:08:48 UTC
Same error occurred when generating AsciiTrace in the same simulation
Comment 2 Silvio Sampaio 2012-08-10 20:49:48 UTC
I think this bug cause is the same of the bug 1482.

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 netanim to search at mesh IEs
(which seems to be a bad choice).

I'll try to look in depth to this problem...
Comment 3 John Abraham 2012-08-11 08:31:00 UTC
actually this problem is not directly related to the netanim module. Netanim is completely oblivious of mesh/wif and uses generic packet printing similar to ascii tracing. This is likely a result of non-standard design  in the mesh module.
Comment 4 Silvio Sampaio 2012-08-24 06:15:07 UTC
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)
Comment 5 Tom Henderson 2015-08-07 01:26:19 UTC

*** This bug has been marked as a duplicate of bug 1482 ***