This is the mail archive of the ecos-discuss@sourceware.org mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RE: Can't Connect,TCP CHECKSUM INCORRECT


Ariga,

>>I only changed coding in retrieving data in BigEndian as I reported to
>>you.
>> I think others are resolved by Macros of bigendian.

Can you let us know what code you changed to retrieve data in
Big-endian?

-Alok

-----Original Message-----
From: ariga masahiro [mailto:ariga@link-lab.co.jp] 
Sent: Tuesday, November 06, 2007 12:44 PM
To: Andrew Lunn; Alok Singh; Gary Thomas
Cc: ecos-discuss@ecos.sourceware.org
Subject: Re: [ECOS] Can't Connect,TCP CHECKSUM INCORRECT

Hello,

We have held argumental conference.
Our board is hardware wired in DATA BUS in order
to retrieve DATA from MAC in Big Endian form like below.

Normal DATA BUS connection
  SH        SMSC(MAC)
D15 <------> D15
 |            |
D08 <------> D08
D07 <------> D07
 |            |
D00 <------> D00

Our Board DATA BUS connection
  SH        SMSC(MAC)
D15 <------> D07
 |            |
D08 <------> D00
D07 <------> D15
 |            |
D00 <------> D08

I know you will be surprised as much as I did.
The trouble is, our company have had already achievements
with this design.Our executives are reluctant to change hardware,
and I am too weak to change company's decision.
After quarrelsome debate, it concluded that my current problem
is not concerned with Endian issue.They doubt my configuration.

So I beseech you to help me again.
I sum up my trouble.
After exchanged commands in UDP,
host begins to TCP Connect and send SYN packet
to our target.Target receives SYN packet and tries to
send back SYN-ACK but that packet becomes Malformed packet.
SYN-ACK packet is never recieved by host.
Please refer to Ethereal txt log file I sent before.

I captured TCP connection between Windows PCs,
and compared SYN - SYNACK packets between Windows PCs log and
host-target 
log,
and I noticed there are some incomprehensible points.

Below is from Ethereal Capture log

Windows<-->Windows  -- no problem
PC-client[172.16.1.28]<-->PC-server[172.16.1.21]
[172.16.1.28]-->[172.16.1.21]
SYN-Packet
00 10 a4 8a 8a ce 00 15  c5 6d 23 f0 08 00 45 00
00 30 30 b8 40 00 80 06  6f be ac 10 01 1c ac 10
01 15 04 c5 04 21 33 5d  c7 c1 00 00 00 00 70 02
ff ff 24 c9 00 00 02 04  05 b4 01 01 04 02
[172.16.1.21]-->[172.16.1.28]
SYN-ACK-Packet
00 15 c5 6d 23 f0 00 10  a4 8a 8a ce 08 00 45 00
00 30 16 2a 40 00 80 06  8a 4c ac 10 01 15 ac 10
01 1c 04 21 04 c5 20 08  8f 1b 33 5d c7 c2 70 12
44 70 31 24 00 00 02 04  05 b4 01 01 04 02
=========================================================
cygwin<-->eCos  -- SYN-ACK [CHECKSUM INCORRECT][Malformed packet]
host-client[172.16.1.28]<-->target-server[172.16.1.200]
[172.16.1.28]-->[172.16.1.200]
SYN-Packet
00 40 31 08 01 00 00 15  c5 6d 23 f0 08 00 45 00
00 30 35 81 40 00 80 06  6a 42 ac 10 01 1c ac 10
01 c8 05 1e 22 42 a6 39  a9 dc 00 00 00 00 70 02
ff ff b0 a4 00 00 02 04  05 b4 01 01 04 02
[172.16.1.200]-->[172.16.1.28]
SYN-ACK-Packet
00 15 c5 6d 23 f0 00 40  31 08 01 00 08 00 45 00
00 28 00 02 40 00 40 06  df c9 ac 10 01 c8 ac 10
01 1c 22 42 05 1e 17 7a  85 37 a6 39 a9 dd 60 12
44 70 ec 30 00 00 00 00  00 00 00 00

My incomprehensible points are,
about Target's SYN-ACK-Packet,
1. paket length in IP header(=0028 line-2,colum-1,2) indicates
   length from top of IP header(line-1,colum-15) to last of packet,
   but 0028(=40d) counts to line-4,colum-6,there are 6 bytes surplus.
2. data offset bits(=6 line-3,colum-15) indicates there are 4*6=24bytes
   from top of TCP header(line-3,colum-3) to last of packet.
   But 24 counts to line-4,colum-10,there are 2 bytes surplus.
   And there is a contradiction between paket length in IP header and
TCP 
data offset bits.
3. option part of SYN packet(00 00 02 04  05 b4 01 01 04 02) changed to
(00 
00 00 00  00 00 00 00)
   in Target's SYN-ACK-Packet.

Please, could you enlighten me what is cause of this phenomenon ?

By the way,I calculated checksum mannually and confirmed they are all 
correct.

I only changed coding in retrieving data in BigEndian as I reported to
you.
I think others are resolved by Macros of bigendian.

Currently when building, Resolve conflicts dialog appears like below.

Resolve conflicts
Item                  Conflict    Property
CYGPKG_POSIX_CLOCKS   Unsatisfied Requires 
CYGBLD_ISO_STRUCTTIMEVAL_HEADER=="<cyg/posix/sys/time.h>"
CYGPKG_FILEIO_FNMATCH Unsatisfied Requires 
CYGBLD_ISO_FNMATCH__HEADER=="<cyg/fileio/fnmatch.h>"
Proposed Solutions:
Item                               Value
x CYGBLD_ISO_FNMATCH__HEADER       Enabled,<cyg/fileio/fnmatch.h>
x CYGBLD_ISO_STRUCTTIMEVAL_HEADER  Enabled,<cyg/posix/sys/time.h>

I also send ecc file.
Suspicious option is CYGSEM_KERNEL_SCHED_TIMESLICE_ENABLE.
Now CYGSEM_KERNEL_SCHED_TIMESLICE_ENABLE is false
Must I make it true ?

I am checking myself options,
but it is like searching diamond among Pacific Oceans' sands.
Could you give me atleast any hints whatsoever ?

I look forward for your reply.
Thanks in advance.

Masahiro Ariga


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]