How to automatically pad ethernet UDP packets

[mteverestand]

I'm using LabVIEW's UDP Palette to send and receive messages over Ethernet. I noticed that when I send packets with a UDP payload of less than 18 bytes, the Ethernet packet becomes less than 60 bytes. I am using a monitor on the network (Vector's CANoe), which reports those packets as error frames because they're too short. I can easily pad the payload I'm sending, but that increases the length counter in the IPv4 header, which makes the device receiving my packets think that the padding is part of my message. Is there a way I can edit the IPv4 header length to not include the padding, or to get the LabVIEW UDP VI's to include them for me?

If it matters, I'm using 64bit LabVIEW 2016. Thank you for your help.

[billko]

Probably the best way to do this is to give in.  Pad the payload and rework the messages to account for that.  The messaging system should probably have been developed with packet sizes in mind.  (I've run into the opposite where one of the senders wants to send a data packet that is so large it gets fragmented, so I feel your pain.)

Maybe you can designate them as "reserved bits".

[mteverestand]

Thanks for the reply. Unfortunately, I'm sending messages to a system that I don't have control over. When it sends messages to my computer, it's padded, but the IPv4 header length field doesn't include the pad bytes. When I receive those messages using labview, it automatically ignores the pad bytes, I assume because of the length in the IPv4 header. Do you know if it's possible to edit that field?

[Kyle97330]

I don't think LabVIEW's built-in UDP has a way to do this.  As far as I know it should be done automatically in the background and not require a manual override.

However, you could switch from their built-in UDP to using the .NET UDP object and methods and see if that does the padding?

[altenbach]

First of all, LabVIEW has no control over the packet header and "packets". All you can control is the payload, which might get fragmented into multiple packets by the network stack based on size and mtu, etc.

The problem here resides solely in your network monitor that apparently flags legitimate packets as errors, and that's where you need to solve this. Do they just get flagged or actually dropped?

Solving this on the LabVIEW side seems pointless.

[Kyle97330]

A message with less than 64 bytes is technically an error because it could cause problems with CSMA/CD.  However, this is only an issue on networks that use hubs (not switches) and can have frame collision issues.  Since it's nearly impossible to find a hub anymore (and quite cheap and easy to replace with a switch if you have one) this is almost certainly not going to cause an actual problem, but the small packet is technically against the Ethernet IEEE 802.3 standard.

[mteverestand]

@kyle, thanks for this reference. I'd rather not switch languages if I can avoid it, but I understand I may have to.

@altenbach, The packets are flagged by the network monitor, but received correctly by the unit I'm testing. The only problem is that I'm a test engineer, and if I try to report a bug to our software team, they'll focus on the error packet in the logs even if it doesn't usually matter to the unit.

The reason it's flagging the packets is that they're below the ethernet packet minimum length, which is a legitimate ethernet error, as far as I can tell. However, for some reason, the arp requests from the computer (no labview interaction) are also below that limit.

[altenbach]

---

@Kyle97330 wrote:

... but the small packet is technically against the Ethernet IEEE 802.3 standard.

---

If the min size is 64bytes, padding should be handled transparently by the stack, I thought.

(Just because CSMA/CD uses small packets, this has really nothing to do with the current discussion.)

[mteverestand · Accepted solution]

Hello thread,

I've solved the problem. As this thread explains, I'm looking at the contents of the bus before it gets to the network card, which does the dirty work of adding padding. @altenbach is correct, it's the fault of my bus monitor for not understanding that they won't be there if I'm monitoring before the ethernet hardware.

Thank you for your comments!