440,946 Members | 1,600 Online Need help? Post your question and get tips & solutions from a community of 440,946 IT Pros & Developers. It's quick & easy.

# Help! Raw Socket CheckSum

6 Replies

 P: n/a > /*PLEASE EXPLAIN THE BELOW ! */ unsigned short /* this function generates header checksums */ csum (unsigned short *buf, int nwords) { unsigned long sum; for (sum = 0; nwords > 0; nwords--) sum += *buf++; sum = (sum >> 16) + (sum & 0xffff); sum += (sum >> 16); return ~sum; } This is OT and you don't clarify what you don't understand. I can try explaining the C code itself. The algorithm assumes sizeof(short) = 2. It sums up the values from the array. It then redefines 'sum' as 2*(16 high order bits of 'sum') + (16 low order bits of 'sum'). There is no overflow because 'sum' is a long. Finally, it negates the sum (which many checksum algorithms do) and returns it as a short for future transmission. To understand more about checksum algos, try a different newsgroup. Nov 14 '05 #3

 P: n/a Method Man finally wrote on Saturday 09 October 2004 03:28 am: /*PLEASE EXPLAIN THE BELOW ! */ unsigned short /* this function generates header checksums */ csum (unsigned short *buf, int nwords) { unsigned long sum; for (sum = 0; nwords > 0; nwords--) sum += *buf++; sum = (sum >> 16) + (sum & 0xffff); sum += (sum >> 16); return ~sum; } I can try explaining the C code itself. The algorithm assumes sizeof(short) = 2. It sums up the values from the array. It then redefines 'sum' as 2*(16 high order bits of 'sum') + (16 low order bits of 'sum'). I may be confused, but I don't think that 2*(16 high order bits) + (16 low order bits) describes what happens. As I read it, it adds the high order bits to the low order bits, then it adds that result to the high order bits of the result. For instance, if the number is AE9CF88A, AE9C + F88A = 0001A726. ( sum = (sum >> 16) + (sum & 0xFFFF) ) 0001A726 + 0001 = 0001A727. ( sum += (sum >> 16) ) Note: (various ways of interpreting your description) 2*(AE9C + F88A) = 34E4E 2* AE9C + F88A = 255C2 2* 0001 + A727 = A729 2*(0001 + A727) = 14E50 I'm new at this, so please correct me if I'm wrong, but that is how I understood what was going on with that algorithm (minus the negation). Thanks, jab3 Nov 14 '05 #4

 P: n/a Hi guys, thanks for that. You have answered my question, sorry for not being more specific. I have also found a few rfc's to explain it for me as well. Sorry for posting in the wrong newsgroup but thanks for the help. Nov 14 '05 #5

 P: n/a "jab3" wrote in message news:gN********************@comcast.com... Method Man finally wrote on Saturday 09 October 2004 03:28 am: /*PLEASE EXPLAIN THE BELOW ! */ unsigned short /* this function generates header checksums */ csum (unsigned short *buf, int nwords) { unsigned long sum; for (sum = 0; nwords > 0; nwords--) sum += *buf++; sum = (sum >> 16) + (sum & 0xffff); sum += (sum >> 16); return ~sum; } I can try explaining the C code itself. The algorithm assumes sizeof(short) = 2. It sums up the values from the array. It then redefines 'sum' as 2*(16 high order bits of 'sum') + (16 low order bits of 'sum'). I may be confused, but I don't think that 2*(16 high order bits) + (16 low order bits) describes what happens. As I read it, it adds the high order bits to the low order bits, then it adds that result to the high order bits of the result. Yes, you're correct. Nov 14 '05 #6

 P: n/a On Sat, 9 Oct 2004 03:28:34 -0400, "Method Man" wrote in comp.lang.c: /*PLEASE EXPLAIN THE BELOW ! */ unsigned short /* this function generates header checksums */ csum (unsigned short *buf, int nwords) { unsigned long sum; for (sum = 0; nwords > 0; nwords--) sum += *buf++; sum = (sum >> 16) + (sum & 0xffff); sum += (sum >> 16); return ~sum; } This is OT and you don't clarify what you don't understand. I can try explaining the C code itself. The algorithm assumes sizeof(short) = 2. No, it does not make any assumptions at all about sizeof(short). Not in bits or bytes. In fact this code would work unchanged on implementations where sizeof(short) is 1 and sizeof(long) is 2. It would also work unchanged on implementations where sizeof(short) is 1 and sizeof(long) is 1. It sums up the values from the array. It sums the values from the array into an unsigned long, which is possibly wider than unsigned short. It then redefines 'sum' as 2*(16 high order bits of 'sum') + (16 low order bits of 'sum'). Nonsense, it does not 'redefine' anything. 'sum' was defined as an unsigned long at the start, and an unsigned long it remains. It performs a computation on sum. There is no overflow because 'sum' is a long. 'sum' is an unsigned long, and hence it subject to modulo wrap around if a calculation produces an out-of-range value. If it were a signed long, overflow would be possible, producing undefined behavior. Finally, it negates the sum (which many checksum algorithms do) and returns it as a short for future transmission. No, it returns it as an unsigned short, and that is quite different since the expression '~sum' could well be outside the range of values for a short, which would produce an implementation-defined result. To understand more about checksum algos, try a different newsgroup. -- Jack Klein Home: http://JK-Technology.Com FAQs for comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html comp.lang.c++ http://www.parashift.com/c++-faq-lite/ alt.comp.lang.learn.c-c++ http://www.contrib.andrew.cmu.edu/~a...FAQ-acllc.html Nov 14 '05 #7

### This discussion thread is closed

Replies have been disabled for this discussion. 