[En-Nut-Discussion] IP Checksum calculation broken. Reenabled old algorithm for the meantime.
bernard.fouche at kuantic.com
Mon Jun 18 11:20:53 CEST 2012
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.
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.
More information about the En-Nut-Discussion