Bugzilla – Bug 1482
Asciitrace produces fatal error in mesh simulation
Last modified: 2017-04-18 15:21:46 EDT
Created attachment 1432 [details] Mesh.cc file with AsciiTrace code added This is same as mesh.cc except line number 152 and 200 are added When i try to create Asciitrace file using AsciiTraceHelper as given in the attached file it give following error: >'build' finished successfully (20.524s) >assert failed. cond="!m_metadataSkipped", msg="Error: attempting to enable the >packet metadata subsystem too late in the simulation, which is not allowed. >A common cause for this problem is to enable ASCII tracing after sending any >packets. One way to fix this problem is to call ns3::PacketMetadata::Enable >() near the beginning of the program, before any packets are sent.", >file=../src/network/model/packet-metadata.cc, line=59 >terminate called without an active exception >Command ['/home/ehsan/Documents/NS-3/ns-allinone-3.14.1/ns-3.14.1/build/scratch/mesh1'] terminated with signal SIGIOT. Run it under a debugger to get more >information (./waf --run <program> --command-template="gdb --args %s <args>"). But when I added ns3::PacketMetadata::Enable () at line 152 as given in attached file, then it gives following error: >'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.
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"