cRIO 9068 UDP Padding

[1hdsquad]

Im using a cRIO9068 to send specific UDP packets (GVCP Discovery Ping). The length of the ethernet frame should be 50 bytes. Unfortunately Labview pads the packet with zeros and my frames end up being 60 bytes long. Unsurprisingly the target system does not recognize the packets and does not respond.

The behaviour can be tested easily: Send a small UDP packet and wireshark it: padded with zeros. 60 bytes long.

What can I do to stop the padding? I did not have the problems using an older cRIO or windows pc. I can imagine the problem is not Labview Realtime but the underlying linux system. Any ideas? Apart from this padding problem I like the 9068 and its performance, it happily runs at 20% cpu usage where the old 9074 was barely abe to keep up at 100%...

[BradM]

Is the UDP packet itself padded or the ethernet frame? I wouldn't be surprised if it's the fact that it's simply enforcing IEEE 802.3 standards for ethernet communication, a minimum mean to ensure collisions are detected, by padding the ethernet frame to the minimum size. http://en.wikipedia.org/wiki/Ethernet_frame#Runt_frames

[1hdsquad]

The ethernet frame is padded, wireshark can highlight the padding.

I dont have access to the GigE Vision standard but it seems as if the discovery ping is required to be 'too short'. I tried a different software and camera and the packet looks the same: 50 bytes per packet, not padded.

[BradM]

A quick dive into the Xilinx EMAC PS driver shows that they unfortunately don't offer a way to disable their hardware MAC from padding/addingCRC (the two seem to be tied together). Not sure what you can do shy of doing some research for some USB ethernet dongles that support this sort of functionality. Or get your hands dirty and try hacking up the kernel to make that happen, but it seems odd that there is equipment that depends on violating ethernet standards to work...

[1hdsquad]

Thank you!

Im in contact with the manufacturer of the camera. They've got access to GigE Vision standard, and maybe they can add support for padded discovery pings... I agree with you about the violated standard.

[BradM]

No problem. If you decide that you don't mind getting your hands dirty, you could always hop on over to the community forums (I hang out there a fair bit), there are a few folks who have some kernel knowledge who frequent those boards. https://decibel.ni.com/content/groups/ni-linux-real-time