This is the mail archive of the
ecos-discuss@sourceware.org
mailing list for the eCos project.
RE: Can't Connect,TCP CHECKSUM INCORRECT
- From: "Alok Singh" <alok dot singh at broadcom dot com>
- To: "ariga masahiro" <ariga at link-lab dot co dot jp>, "Andrew Lunn" <andrew at lunn dot ch>, "Gary Thomas" <gary at mlbassoc dot com>
- Cc: ecos-discuss at ecos dot sourceware dot org
- Date: Mon, 5 Nov 2007 23:58:00 -0800
- Subject: RE: [ECOS] Can't Connect,TCP CHECKSUM INCORRECT
- References: <000501c7f691$4847e2f0$1c0110ac@ariga> <20070914082224.GA16840@lunn.ch> <000501c80eef$edf10f30$1c0110ac@ariga> <47134CDD.1080604@mlbassoc.com> <004301c80fa1$3dcb15d0$1c0110ac@ariga> <47149BA6.1080500@mlbassoc.com> <001301c81091$1d11b060$1c0110ac@ariga> <4715F2D0.7080704@mlbassoc.com> <000c01c81151$9add59c0$1c0110ac@ariga> <47173F99.80405@mlbassoc.com> <000601c8120c$667aa3c0$1c0110ac@ariga> <47187EEB.5020109@mlbassoc.com> <000501c8154d$ecc04db0$1c0110ac@ariga> <E06E3B7BBC07864CADE892DAF1EB0FBD01A1E856@NT-SJCA-0752.brcm.ad.broadcom.com> <000301c816ab$6acbf7f0$1c0110ac@ariga> <000a01c81a9e$6b8c2240$1c0110ac@ariga> <001a01c82044$937a9b50$1c0110ac@ariga>
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