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

[Bernard Fouché]

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.

Regards,

	Bernard Fouché
	Kuantic
---
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
>