I have composed a custom shim that is responsible for appending custom content to the OTA frame in the downstream direction, and removing this custom content in the upstream direction. All works well in terms of the addition and extraction of custom content while being benign to the original host data transfers and the EMANE stack.
I have currently positioned this shim to lie below the EMANE framework physical layer principally because it needs to extract custom OTA content while at the same time not being subject to packet drops that may occur within the EMANE framework physical layer. This is to say that this custom content needs to be received by all NEMS and will have different drop criteria than what exists in the EMANE physical layer. If the shim likes in between the MAC and PHY layers, it would be subject to the drop criteria in the EMANE framework physical layer, and therefore possibly lost on reception. The problem I now have is this custom content on the generation side needs to know the operating bandwidth as the key to the custom content generation. When the shim lays below the EMANE Phy Layer, the calls to processDownstream(DownstreamPacket &pkt, const ControlMessages &msgs) where the custom content gets prepended when received in my custom shim do not contain the control messages that identify the operating bandwidth. Presumably these messages are consumed by the EMANE framework Phy layer and result in population of the fields in the CommonPHYHeader, which this layer prepends to the downstream packet. One solution then might be to obtain this information from the CommonPHYHeader as field u64BandwidthHz which is prepended to the packet data by the EMANE Phy layer. This data is serialized in the EMANE PHY layer in the CommonPHYHeader class. Unfortunately, there is no way that I am aware of to deserialized this content as the DownstreamPacket class does not contain an accessor such as a get() function to the underlying data storage. If this accessor was available, it would be possible to read the header size, and then use something like msg.ParseFromArray to deserialize the contents into a CommonPHYHeader. Can the DownstreamPacket simply be dynamically cast to an UpstreamPacket which provides accessors to the CommonPHYHeader without any consequence? Presumably the DownstreamPacket might need to be duplicated in the case since the upstream processes destructively remove content. Any thoughts on how to obtain CommonPHYHeader fields using just the DownstreamPacket content or a better approach for solving this problem?
_______________________________________________ emane-users mailing list emane-users@nrl.navy.mil https://publists.nrl.navy.mil/mailman/listinfo/emane-users
