From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21932 invoked by alias); 6 Nov 2007 08:30:40 -0000 Received: (qmail 21911 invoked by uid 22791); 6 Nov 2007 08:30:38 -0000 X-Spam-Check-By: sourceware.org Received: from pop132.ocn.ne.jp (HELO pop132.ocn.ne.jp) (60.37.31.215) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 06 Nov 2007 08:30:34 +0000 Received: from ariga (p1143-ipbf2202marunouchi.tokyo.ocn.ne.jp [122.17.131.143]) by pop132.ocn.ne.jp (OCN) with SMTP id lA68USrR015506; Tue, 6 Nov 2007 17:30:28 +0900 (JST) Message-ID: <001501c8204f$486d3180$1c0110ac@ariga> From: "ariga masahiro" To: "Alok Singh" , "Andrew Lunn" , "Gary Thomas" Cc: 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> Date: Tue, 06 Nov 2007 08:30:00 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook Express 6.00.2900.2869 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/msg00021.txt.bz2 >>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? Only next two functions. \packages\devs\eth\smsc\lan91cxx\current\src\if_lan91cxx.c cyg_uint8 get_data_byte(struct eth_drv_sc *sc) { //20070919 int sf; cyg_uint8 c; struct lan91cxx_priv_data *cpd = (struct lan91cxx_priv_data *)sc->driver_private; // //20070919 // db_printf("cpd->data_pos=%d rxd_t=%d\n",cpd->data_pos,sizeof(rxd_t)); if( cpd->data_pos == sizeof(rxd_t) ) { cpd->data_buf = get_data(sc); cpd->data_pos = 0; //20070919 sf = 1; } //20070919 begin else{ sf = 0; } //20070919 end //20070919 begin //ORG c = (cpd->data_buf>>(cpd->data_pos*8))&0xFF; c = (cpd->data_buf>>(sf*8))&0xFF; // //20070919 // db_printf("cpd->data_buf=%x c=%x\n",cpd->data_buf,c); cpd->data_pos++; return c; } cyg_uint16 get_data_short(struct eth_drv_sc *sc) { cyg_uint16 val; val = get_data_byte(sc); //20071023 // val |= get_data_byte(sc)<<8; val = val<<8 | get_data_byte(sc); return CYG_LE16_TO_CPU(val); } -----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=="" CYGPKG_FILEIO_FNMATCH Unsatisfied Requires CYGBLD_ISO_FNMATCH__HEADER=="" 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