FPGA Intellectual Property
PCI Express*, Networking and Connectivity, Memory Interfaces, DSP IP, and Video IP
Intel Support hours are Monday-Fridays, 8am-5pm PST, except Holidays. Thanks to our community members who provide support during our down time or before we get to your questions. We appreciate you!

Need Forum Guidance? Click here
Search our FPGA Knowledge Articles here.
5952 Discussions

InterNiche stack drops packets when ip_chksum field is set to 0xFFFF

Honored Contributor II

For our embedded products we use the iNiche stack. We have several systems running and we see occasionally network packets being dropped by the iNiche stack. We have the impression that it is somehow related to Windows 7 machines, as we have never seen a drop of packets if an XP PC is controlling our embedded devices.  


I tracked down the actual packet which is dropped. It appears in this case that the checksum of the IP header has a value of 0xffff. The standard definition of the IP header is not entirely clear to me how to handle this case. In fact the standard describes a 1-complement sum and for the end result the complement should be taken.  


Now for the case shown in the WireShark window below the checksum is different from the calculation of the Inter Niche stack.  


In file ipdemux,c function ip_rcv() the following is coded:  


csum = pip->ip_chksum;  

pip->ip_chksum = 0;  

hdrlen = ip_hlen(pip);  

tempsum = ~cksum(pip, hdrlen >> 1);  


iNiche stack calculates the checksum with the ip_chksum field set to zero:  







0000 This word is set to zero by iNiche (see code snapshot above)  





------- 1-complement sum  



~FFFF = 0000 <=== This is used to compare against the checksum send in the packet which is 0xFFFF and thus fails.  


I found a note (see below) telling that -0 (i.e. 0xFFFF) should be used in case the checksum is +0. This is exactly what windows 7 does. This packet is dropped by InterNiche stack.  


Is this an error in the stack?
0 Kudos
4 Replies
Honored Contributor II

Basically, there shouldn't be such checksum like 0xFFFF, You should replace 0xFFFF to 0x0000.

Honored Contributor II

Hmmm I just read the thread http://www.ietf.org/mail-archive/web/ietf/current/msg21280.html 

The general view is that both 0x0000 and 0xffff are valid (and equivalent) for IP header checksums. Most code that generates them will not generate 0xffff. 

The InterNiche stack should just remove all the code that zaps the checksum, and just sum the entire header and verify the result is 0xffff. 


Note that 0xffff is special for the UDP checksum => not computed.
Honored Contributor II

I think it would be better to use 0x0000, not 0xFFFF. And in UDP it's 0x0000 too.

Honored Contributor II

Below the response we received via our EBV FAE 


Section 4 of RFC 1624 gives an example where a checksum is computed using the equation from RFC 1141, and as such incorrectly generates a checksum of 0xFFFF, whereas the checksum when calculated from scratch would be 0x0000. This would indicate that Windows 7 system is possibly generating a checksum using methods in RFC 1141 rather than the updated recommendations for incremental checksums in RFC 1624, derived from the base specification RFC 793. 



Having said that, Section 5. of this document acknowledges that systems may not agree on the checksum in this case, with a recommendation to work around systems that generate 0xFFFF by modifying the checksum checking methodology used. 



In summary, I can see this issue having two main points: 


(a) The Windows 7 machine does not generate RFC 793-complient checksums. It may use the methods in RFC 1141 which was updated to correct for 0xFFFF checksum "