[En-Nut-Discussion] IP Checksum calculation broken. Reenabled old algorithm for the meantime.

Harald Kipp harald.kipp at egnite.de
Mon Jun 18 14:07:34 CEST 2012

Hi Ole,

On 18.06.2012 10:34, Ole Reinhardt wrote: 
> Ok, so in general the alignment should always be the same, right? There
> is no chance that we have a 4+2 byte alignment in one situation and a 4
> byte alignment in another?

That's what my patch tries to guarantee. Btw. the main reason for this change was to improve the speed of memcpy, not to simplify the checksum calculation. I still tested IP checksumming with unaligned buffers.

> What's about the ICMP checksum thing where we calculate the checksum
> just over a part of the ICMP packet data?

That should make any difference. However, in sys/types.h we have

#if defined(__avr__)
#define NUTMEM_ALIGNMENT        1
#elif defined(__CORTEX__)
#define NUTMEM_ALIGNMENT        1
#elif defined(__ARM__)
#define NUTMEM_ALIGNMENT        4
#elif defined(__AVR32__)
#define NUTMEM_ALIGNMENT        4
#define NUTMEM_ALIGNMENT        sizeof(int)

This means, that malloc() will use 1 byte alignment for the Cortex. In this case forget everything I told you about NETBUF alignment.

On ARM and AVR32, NETBUFs are allocated by malloc with 4 byte alignment. The 14 byte Ethernet header is shifted by 2, resulting in 4 byte IP header alignment. On Cortex and AVR this doesn't make much sense, but shouldn't hurt.

Since I introduced the current version of the checksum routine, I never experienced any problems with AVR/ARM7/ARM9. Considering this, may be either the checksum routine is still buggy on certain alignments or the compiler cannot handle this correctly, as Bernard reported.

I'm not yet familiar enough with the Cortex platform. But it looks strange to me, that no alignment is required at all. I expected at least 16-bit alignment.



More information about the En-Nut-Discussion mailing list