Re: [ECOS] Can't Connect,TCP CHECKSUM INCORRECT

[Andrew Lunn <andrew@lunn.ch>]

On Tue, Oct 30, 2007 at 11:41:48AM +0900, ariga masahiro wrote:
> Hello,
>
> I am the same person who sent the mailing list titled
> "What functions should I call in ethernet drv ?".
> At that time I was helped by your advices.
> I was very much obliged.
>
> I am sorry to say that I am encountered another trouble
> and I ask you again your help.
>
> Since then I continued to test transmission between host and target.
> host(Client)  : 172.16.1.28  : nc_test_master
> target(Server): 172.16.1.200 : nc_test_slave
>
> UDP packets look like correctly transmitted between both terminals.
>
> But when host tries to connect to target in TCP,
> always happens connection error(timeout).
> Below is host's output on cygwin shell.
>
> $ ./nc_test_master.exe 172.16.1.200
> Start Network Characterization - MASTER
> ================== No load, master at 100% ========================
> Start TCP echo [64,10240] - no delays
> Can't connect to slave: Connection refused
> Can't connect to slave: Connection refused
> Can't connect to slave: Connection refused
>
> I sent also Etherreal packets captutre log file(text-gz format).
> \TCP-checksum-log\DEBUG-00-prescale-20\EtherReal-log-txt\etherreal-TCP-2.txt
> DEBUG=00,CYGHWR_HAL_SH_RTC_PRESCALE=20(CYGNUM_HAL_RTC_PERIOD=14745)
>> From here on,I refer to this file as er.txt.
>
> When host send SYN packet to target(er.txt,line 89),
> target tried to reply SYN-ACK but resulted [CHECKSUM INCORRECT].
> Target's TCP packets almost always [CHECKSUM INCORRECT].
> I also noticed Seq, Ack,and Win numbers all suspicious.
> When Ack-number looks proper,CHECKSUM INCORRECT not occurs, but never 
> connected.
>
> I traced TCP checksum routine,and I am not sure they are correct.
> I set break at 735 line in tcp_output() function in
> packages\net\bsd_tcpip\current\src\sys\netinet\tcp_output.c
>
>       730: #endif /* INET6 */
>       731:       {
>       732:     m->m_pkthdr.csum_flags = CSUM_TCP;
>       733:     m->m_pkthdr.csum_data = offsetof(struct tcphdr, th_sum);
>       734:     if (len + optlen)
>       735:         th->th_sum = in_addword(th->th_sum,
>       736:             htons((u_short)(optlen + len)));
> Then jumped to
> packages\net\bsd_tcpip\current\src\sys\netinet\in_cksum.c(200): 
> in_addword(u_short a, u_short b)
>
>       199: u_short
>       200: in_addword(u_short a, u_short b)
>       201: {
>       202:     u_int32_t sum = a + b;
>       203:
>       204:     ADDCARRY(sum);
>       205:     return (sum);
>       206: }
>
> ADDCARRY is defined as below in in_cksum.c(76)
>
> #define ADDCARRY(x)  (x > 65535 ? x -= 65535 : x)
>
> Now this looks not doing one's complement sum for me.
> Is this really correct function ?

Something to consider. This code works for many people on lots of
differ net hardware, big endian and little endian. This is also taken
directly from FreeBSD which has many more uses than eCos. So it is
very unlikely to be a bug in something like this.

It is much more likely you have a configuration problem for your
hardware or a bug in your new code for the hardware dependant part of
the device driver.

> Our most serious concern is, my concoction in driver source to accommodate 
> to target's hardware pecuriality
> is affecting those misbehaviour.
> As I said in last mail, our company's target board was hardware wired to
> retreive data in BigEndian.

What is probably a better idea is to get your hardware engineer to fix
your board so the ethernet device is using the correct
endianness. This should not be too hard, maybe replace a pull up
resister with a patch wire to ground etc...

         Andrew


-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss