How this could posibly be right ?!?!?!

uint32_t
WifiInformationElementVector::DeserializeSingleIe (Buffer::Iterator start)
{
  Buffer::Iterator i = start;
  uint8_t id = i.ReadU8 ();
  uint8_t length = i.ReadU8 ();
  Ptr<WifiInformationElement> newElement;
  switch (id)
    {
    default:
      NS_FATAL_ERROR ("Information element " << (uint16_t) id << " is not 
implemented");
      return 0;
    }
[...]
}

That switch is simply kicking in *every* time. The fun part is that the 
function seems only be called by mesh module, even if it's in the wifi module.

Anyway, a fix is needed, but my knowledge of those two modules is not enough to 
fix it.

The problem is that there are no information elements in the Wifi module.
Mesh information elemtnts are implemented in mesh module, but ASCII tries to deserialize mesh information elements as wifi information elements. This may be easily be fixed, but the same problem arises with peer-link management frames -- the type of frame is set by previously deserialized action header. I will fix this asap and provide you a patch

Technically there are some IntormationElements in WiFi:
- class Ssid : public WifiInformationElement
- class ExtendedSupportedRatesIE : public WifiInformationElement

It seems that those aren't stored in the WifiInformationElementVector class and, thus, not are not using this function. It's a guess tho, I haven't the time to check deeply right now.

Anyway, happy digging !

T.

Created attachment 1358 [details]
First version of proposed fix

First version of proposed fix.
TODO list:
1. PeerLinkFrameStart in peering management should be completely removed
2. Cosmetic changes in peer link and peering management dhould be done.


I have found two problems concerned with this bug:
1. I have used a WifiInformationElementVector instead of MeshInformationElementvector during instantiation.
2. PeerLinkFrame deserialization logic depends on the previous deserialized header, which causes internal assertion during Deserialize.

I have fixed both, but did not completely remove PeerLinkFrameStart

Thanks, keep up the good job :)

One thing that still puzzles me is that the function throwing the assert is supposed to do something, while if one tries to use it, it will throw an assert for sure. So, why it's there? To lure the n00b ?

It sounds like dead code, but I'm always a bit concerned in removing what I don't fully understand. Anyway, the bug is about mesh, so first we need to fix that part, then we can think about the dead code.

Cheers,

T.

Created attachment 1426 [details]
This is the trace file generated after executing mesh.cc

After applying the patch provided by Andreeve in NS-3.13, the trace file generated by executing mesh.cc is attached. Using this patch, only broadcast frames are traced in the ascii trace file where DA=ff:ff:ff:ff:ff:ff. No unicast frame is there in the trace file. Part of the trace file is attached.
Moreover this patch gives many errors when applied in NS-3.14.1
Hope to hear from you soon

Looking into this issue, I've got that (briefly) 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...).

Tommaso Pecorella is right when saying that "Technically there are some IntormationElements in WiFi: - class Ssid : public WifiInformationElement - class ExtendedSupportedRatesIE : public WifiInformationElement". However, they are not serialized/deserialized by using a IE vector. 

The idea of serialize/deserialize a set of IEs from a vector is very useful. Therefore, I suggest 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 (and peering) 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). It will also help further implementations using IEs.

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

I do not see any updates on this for some years, and it is not so easy to take over.
Could someone briefly explain what is the status of this bug?

(In reply to sebastien.deronne from comment #8)
> I do not see any updates on this for some years, and it is not so easy to
> take over.
> Could someone briefly explain what is the status of this bug?

It seems related also to bug 881 (cleanup of IE implementation).  I don't know of any status on this particular one, however.

I'm going to mark this as a duplicate of bug 881, and close it.

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