Network problem - header checksum error -

[Steve Hunt]

I have found that by changing file
cpukit/libnetworking/netinet/ip_output.c - by adding a delay just before
in_cksum_hdr(ip) - the checksum is correctly calculated and everything
works!!!! so perhaps the header is still being changed by the driver at
that time? or is everything in the same thread? perhaps 'ip' is pointing
directly to the hardware and the registers are not stable???.

Very strange ...  but I have not have had time to investigate further
yet - but I will also see if using in_cksum() in place of in_cksum_hdr()
fixes (hides) the problem.

As a side issue - I noticed that when my delay was by adding a 'printf'
I had a quite stable time reported by ping (~2ms) - but when I used
usleep() the time for ping to return changed in a cyclical and
predictable way from 10ms to 1mS !!!!! - would this be expected?  I will
do some more tests.

By the way, my target system is a pc104+ ... not very fast by modern
standards.

Steve Hunt

On Fri, 2006-04-14 at 18:15 +0200, Steve Hunt wrote:
> No - it looks like only the header checksum is wrong.
> 
> On Fri, 2006-04-14 at 16:30 +0200, Sylvain Prestavoine wrote:
> > ----- Original Message ----- 
> > From: "Steve Hunt" <hunt at alceli.ch>
> > To: <rtems-users at rtems.com>
> > Sent: Friday, April 14, 2006 2:44 PM
> > Subject: Network problem - header checksum error -
> > 
> > 
> > > I am having a problem getting rtems to run.  I can boot my application
> > > on my pc104 with rtk8139 network chip using pxe boot and grub.
> > > 
> > > However once my application is running (and is therefore now using the
> > > rtems network stack not the pxe or grub networking) any packets sent
> > > from my system seem to have incorrect header checksum.
> > > 
> > > For instance a ping to the device reports no replies - but ethereal
> > > 'sniffer' shows the reply packet arriving - but with corrupt header
> > > checksum.
> > > 
> > 
> > How are other datas, corrupted or no ?
> > Perhaps is an endianness problem ?
> > 
> > --
> > -Stan
> > 
> > 
> > 
>