[patch] BLIP checksum algorithm is subtly wrong

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Calculate a checksum over data that causes more than one carry during the 
summing.
2. Note how other systems reject said packet due to a bad checksum.

What is the expected output? What do you see instead?
The expected output is that each carry is counted. The existing code only 
counts the first carry, leading to very intermittent but fully reproducible 
packet errors.

What version of the product are you using? On what operating system?
TinyOS 2.x trunk as of a couple of weeks.

Please provide any additional information below.

Below is an example of packet data which hit the checksumming error here. 
Expected checksum for it is 0xfffd, but got calculated as 0xfffe.

char pkt4260_to_csum[] = {
0xfd, 0x00, 0xb8, 0x1e, 0x00, 0x01, 0x00, 0x00, // src ip 
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x06,
0xfd, 0x00, 0xb8, 0x1e, 0x00, 0x01, 0x00, 0x00, // dst ip 
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x02,

0x00, 0x11, // next-header
0x00, 0x12, // payload length

0x16, 0x33, 0x16, 0x33, 0x00, 0x12, 0xff, 0xfe, // payload
0x62, 0x40, 0x7e, 0x03, 0xb2, 0x18, 0xbe, 0x02, 
0x18, 0xbe,
};

Original issue reported on code.google.com by jmatts...@dius.com.au on 21 Dec 2011 at 6:23

Attachments:

• tinyos-blip-bad-cksum.patch

[GoogleCodeExporter]

Original comment by sdh...@gmail.com on 11 Jan 2012 at 5:10

• Changed state: Accepted
• Added labels: Milestone-2.1.2, Priority-Critical
• Removed labels: Priority-Medium

[GoogleCodeExporter]

Tested and applied in r5873.

Original comment by sdh...@gmail.com on 18 Jan 2012 at 8:46

• Changed state: Fixed