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

Bernard Fouché bernard.fouche at kuantic.com
Mon Jun 18 11:20:53 CEST 2012

Hello Ole,

just a few words about a similar issue I ran into on a Cortex-M3 while 
coding for eCos (yes we use Ethernut but still with atmega at the 
moment...): arm-eabi-gcc often uses ldmia/stmia for copying multiple 
registers from/to addresses that are supposed to be correctly aligned 
(check the asm of the concerned code to see if these instructions are 
used). When the adresses are not aligned with ldm/stm, you don't get an 
exception but weird results (the processed bytes are mixed up). In my 
case it happened because I was passing a pointer to a structure to a 
copy function:because it was a struct *, gcc assumed that the pointer 
was always aligned and ldm/stm could be used. Casting the pointer to 
void * and using memcpy() solved the problem.

Hope it helps.


	Bernard Fouché
Le contenu de cet email est confidentiel et réservé aux seuls destinataires.
Reproduction et diffusion interdites, sauf accord préalable.

Le 18/06/2012 10:34, Ole Reinhardt a écrit :
> Moin Harald,
>> Ole, which CPU did you use?
> I'm using LPC1778 with trunk HEAD.
>> Regarding alignment: In r4028 I added a 2 byte offset to the network
>> buffer, which aligns them to (32 + 16)-bit addresses. Due to the 14
>> byte Ethernet header, this aligns the IP part to a 32-bit address.
> 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?
> What's about the ICMP checksum thing where we calculate the checksum
> just over a part of the ICMP packet data?
>>> @Harald: Do you have any ideas what I could do for better testing and
>>> evaluating the problem?
>> Testing it with network traffic is cumbersome. For testing I add the
>> legacy and the new code to the application and call them directly with
>> a prepared buffer.
> I'll do so with some test code later.
> Bye,
> Ole

More information about the En-Nut-Discussion mailing list