05-31-2016 05:27 AM
I'm using a Z-7045 with vxWorks 6.9
Wireshark shows that, when XMT checksum offloading is enabled, the transmitted UDP checksum value for small UDP payload sizes (1 or 2 bytes) is 0xFFFF
According to RFC 768 I believe this is interpreted as an actual UDP checksum value of 0, which is not correct for the data transmitted
As a result, the (Windows based) network receiver discards the UDP packet
I observe that UDP payloads of length > 2 have the correct UDP checksum
A workaround is to disable XMT checksum offloading in the GEM interface; the resulting transmitted UDP checksum value calculated by the vxWorks IPNET stack is correct, and the receiver accepts the UDP packet
Can anyone confirm if this is a known error in the Zynq GEM operation?
Let me know if I can provide more info; thanks for any advice you can share
- Paulito Mendoza
06-14-2016 11:53 PM
Yes there is a known issue and checksum field should be zero before giving the frame to HW for checksum calculation.
Here is the workaround that implemented in our driver which you can try.
06-02-2018 07:26 AM
The patch only works for internally generated IP packet with ip_summed==CHECKSUM_PARTIAL. For CHECKSUM_NODE (packets which already have a valid UDP checksum) then the HW overwrites with the wrong checksum. A packet with a checksum already present is not meant to be overridden, but the HW has no way of disabling transmit checksum on a packet by packet basis.