From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26212 invoked by alias); 6 Nov 2007 07:58:42 -0000 Received: (qmail 26202 invoked by uid 22791); 6 Nov 2007 07:58:41 -0000 X-Spam-Check-By: sourceware.org Received: from mms1.broadcom.com (HELO mms1.broadcom.com) (216.31.210.17) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 06 Nov 2007 07:58:37 +0000 Received: from [10.10.64.154] by mms1.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.1)); Mon, 05 Nov 2007 23:58:26 -0800 X-Server-Uuid: 6B5CFB92-F616-4477-B110-55F967A57302 Received: by mail-irva-10.broadcom.com (Postfix, from userid 47) id EE91E2AF; Mon, 5 Nov 2007 23:58:25 -0800 (PST) Received: from mail-irva-8.broadcom.com (mail-irva-8 [10.10.64.221]) by mail-irva-10.broadcom.com (Postfix) with ESMTP id D8D532AE; Mon, 5 Nov 2007 23:58:25 -0800 (PST) Received: from mail-sj1-12.sj.broadcom.com (mail-sj1-12.sj.broadcom.com [10.16.128.215]) by mail-irva-8.broadcom.com (MOS 3.7.5a-GA) with ESMTP id FXG51847; Mon, 5 Nov 2007 23:58:02 -0800 (PST) Received: from NT-SJCA-0752.brcm.ad.broadcom.com (nt-sjca-0752 [10.16.192.222]) by mail-sj1-12.sj.broadcom.com (Postfix) with ESMTP id 67A6C20502; Mon, 5 Nov 2007 23:58:02 -0800 (PST) Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 06 Nov 2007 07:58:00 -0000 Message-ID: In-Reply-To: <001a01c82044$937a9b50$1c0110ac@ariga> 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> <000301c816ab$6acbf7f0$1c0110ac@ariga> <000a01c81a9e$6b8c2240$1c0110ac@ariga> <001a01c82044$937a9b50$1c0110ac@ariga> From: "Alok Singh" To: "ariga masahiro" , "Andrew Lunn" , "Gary Thomas" cc: ecos-discuss@ecos.sourceware.org X-WSS-ID: 6B2EC12828G15627295-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes Mailing-List: contact ecos-discuss-help@ecos.sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: ecos-discuss-owner@ecos.sourceware.org Subject: RE: [ECOS] Can't Connect,TCP CHECKSUM INCORRECT X-SW-Source: 2007-11/txt/msg00020.txt.bz2 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]=20 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=20 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 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D 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(=3D0028 line-2,colum-1,2) indicates length from top of IP header(line-1,colum-15) to last of packet, but 0028(=3D40d) counts to line-4,colum-6,there are 6 bytes surplus. 2. data offset bits(=3D6 line-3,colum-15) indicates there are 4*6=3D24bytes 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=20 data offset bits. 3. option part of SYN packet(00 00 02 04 05 b4 01 01 04 02) changed to (00=20 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=20 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=20 CYGBLD_ISO_STRUCTTIMEVAL_HEADER=3D=3D"" CYGPKG_FILEIO_FNMATCH Unsatisfied Requires=20 CYGBLD_ISO_FNMATCH__HEADER=3D=3D"" Proposed Solutions: Item Value x CYGBLD_ISO_FNMATCH__HEADER Enabled, x CYGBLD_ISO_STRUCTTIMEVAL_HEADER Enabled, 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