Questions about MGEN output data stream format

[szl0144]

Hi,

I use MGEN to generate traffic flow for EMANE, my MGEN version is 5.02. I set the DATA part in the packet payload part using DATA command, and I try to extract it in EMANE in MAC layer according to 9. MGEN Message Payload in the user manual, but they doesn't match. The way I extract it is following:

1) Substract the ethernet header, IPv4 header and UDP header in order and get the MGEN message payload. 2) Shift the pointer from the beginning of the message payload buffer address to the data payload part.

However, the data is not I set in MGEN, I am confused about the UDP IPv4 and Ethernet header format set in MGEN and the message payload format, is there any material I can check about this?

Thanks, Shaoyi

[weston-nrl]

Does the MGEN log on the receiver contain the correct (or any) payload information?

See also the notes in Section 9 of the User's Guide regarding ensuring that your packet has sufficient length to hold the desired payload information. That section also has information about what the minimum MGEN message sizes are (to which your payload size would need to be added).

[szl0144]

Hi,

I checked the ethernet frame payload, and found the IPv4 header information is definitely correct, and the UDP header information seems correct, but I observed the src and dst port number is 50698 in host byte order which can't match the port number 5001 in the mgen.log. And I think the message payload extracted in EMANE doesn't match the format in user guide, I am not sure if there is any encode operation on MGEN message payload.

I set the message size to be 512 bytes which is larger than 28 bytes that UDP protocol needs..

Sincerely, Shaoyi

[weston-nrl]

Have you tried looking at the packets in Wireshark and comparing that with your packet parsing code results? The port numbers should show up correctly there, and possibly help you locate any issues with your parsing code.

The possibility of commandline payload syntax issues, byte ordering problems, etc. is why I asked whether any payload data showed up in the MGEN log, even if it doesn't match what you put in. Note from the user's guide that DATA specified in an MGEN script/commandline should be in pairs of hexadecimal values (see section 6.11). There are other ways data can be sent using more advanced MGEN usage (like the 'Flow' class in the python code in src/python/mgen.py), but that's the way it works with the standard application.

[szl0144]

Great suggestion! I just forgot to mention that the packet information in mgen.log matches the values I set by commandline and the RECV message matches the SEND message.

Do you mean the standard application is EMANE or other application receiving the data flow?

[weston-nrl]

No I mean the standard MGEN application. EMANE is completely unrelated to MGEN other than that MGEN can be run within an EMANE emulation as a traffic source/destination.

[bebopagogo]

If you are sniffing EMANE OTA (over the air) packets directly off the the Ethernet, note that the EMANE PHY layer (and MAC layer) has its own encapsulation headers on top of any user packets conveyed in an "Over the air" transmission. For example, the EMANE PHY OTA header has stuff like radio transmit frequency, transmit duration, etc meta-data that the emulation environment uses. User data content (like MGEN/UDP/IP packets) are embedded within those EMANE MAC/PHY/Ethernet frames that you may be observing for transmissions pertaining to user data (i.e.not network control, etc) transmit events. If you want to see the MGEN frames and you are using EMANE "transvirtual" network stack binding, you would want to sniff from the virtual TAP device that the EMANE "transvirtual" binding creates. I.e., not the physical device on the EMANE OTA "channel"