From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18223 invoked by alias); 13 Nov 2007 01:13:21 -0000 Received: (qmail 18215 invoked by uid 22791); 13 Nov 2007 01:13:20 -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, 13 Nov 2007 01:13:16 +0000 Received: from ariga (p1143-ipbf2202marunouchi.tokyo.ocn.ne.jp [122.17.131.143]) by pop132.ocn.ne.jp (OCN) with SMTP id lAD1DA2k016338; Tue, 13 Nov 2007 10:13:10 +0900 (JST) Message-ID: <001001c82592$5a026b20$1c0110ac@ariga> From: "ariga masahiro" To: "Gary Thomas" , "Alok Singh" , "Andrew Lunn" Cc: References: <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> <001501c8204f$486d3180$1c0110ac@ariga> <20071106083527.GB16191@lunn.ch> <000301c820cf$6a8a0b50$1c0110ac@ariga> <000801c820da$3d702c20$1c0110ac@ariga> <002101c8210d$f76211b0$1c0110ac@ariga> <001301c82117$a6bb3430$1c0110ac@ariga> <002101c821aa$8ea9d1b0$1c0110ac@ariga> <001001c821e0$8d1edc60$1c0110ac@ariga> <000c01c82269$ec1a5bc0$1c0110ac@ariga> Date: Tue, 13 Nov 2007 01:13: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/msg00080.txt.bz2 Hello, I setted break point at ether_demux()'s 599 line in if_ethersubr.c and dumped mbuf data when received SYN packet from host and was confirmed its content is just as same as Ethereal captured data and also mh_len is correct. ether_demux(ifp, eh, m) 596-601 lines case ETHERTYPE_IP: if (ipflow_fastforward(m)) return; schednetisr(NETISR_IP); inq = &ipintrq; break; Ethereal captured SYN-packet host[172.16.1.28]-->target[172.16.1.200] TCP SYN packet 0000 00 40 31 08 01 00 00 15 c5 6d 23 f0 08 00 45 00 0010 00 30 09 fb 40 00 80 06 95 c8 ac 10 01 1c ac 10 0020 01 c8 04 d2 22 42 10 7d 2c a0 00 00 00 00 70 02 0030 ff ff c3 e9 00 00 02 04 05 b4 01 01 04 02 mbuf dumped data {m_hdr={mh_next=*00000000,mh_nextpkt=*00000000,mh_data=*8C092EAC,mh_len=0x30,mh_type=0x1,mh_flags=0x2}, 8C092EAC 45 00 00 30 09 FB 40 00 8C092EB4 80 06 95 C8 AC 10 01 1C 8C092EBC AC 10 01 C8 04 D2 22 42 8C092EC4 10 7D 2C A0 00 00 00 00 8C092ECC 70 02 FF FF C3 E9 00 00 8C092ED4 02 04 05 B4 01 01 04 02 8C092EDC 00 40 31 08 01 00 08 06 8C092EE4 00 01 08 00 06 04 00 01 Also I setted break point at eth_drv_send()'s line 748 in eth_drv.c. and dumped sg_list in which sending packet is reserved. This is just before jumping to lan91cxx_send(). eth_drv.c eth_drv_send(struct ifnet *ifp) 746: // Tell hardware to send this packet 747: if ( sg_len ) break 748: (sc->funs->send)(sc, sg_list, sg_len, total_len, (unsigned long)m0); sg_list [0] = {buf=0x8C0928AE,len=0x36} [1] = {buf=0x8,len=0x8C0816B4} [2] = {buf=0x0,len=0x8C081248} 8C0928AE 00 15 C5 6D 23 F0 00 40 8C0928B6 31 08 01 00 08 00 45 00 8C0928BE 00 28 00 02 40 00 40 06 8C0928C6 DF C9 AC 10 01 C8 AC 10 8C0928CE 01 1C 22 42 05 3F 11 0E 8C0928D6 A5 2E 78 6A D4 5B 60 12 8C0928DE 44 70 D5 D5 00 00 02 04 8C0928E6 05 B4 00 00 00 00 00 00 And I confirmed that already at this point IP packet length(line-3,column-1,2) is contradicting with TCP data-offset(line-6,column-7). Both lengths too short. Thus I think it proves that my current trouble(=SYN-ACK becomes Malformed Packet) is not concerned with hardware byte swapping.(at least directry) I think it is caused by something else. I beseech you to consider again without attention to hardware byte swapping. I re-post my trouble or question from 11/6/2007 mail. > 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 think at least my next observation is connected with my problem. This is from 11/08/2007 mail. > I traced tcp_output function. > It looks to me, at tcp_output's next points, append option part. > line 688-691 > if (optlen) { > bcopy(opt, th + 1, optlen); > th->th_off = (sizeof (struct tcphdr) + optlen) >> 2; > } > Although peer sent 8 bytes option,optlen was 4. > > Also it looks to me, in generating SYN-ACK packet, at next switch > sentence, > case (TH_SYN|TH_ACK) context should be executed. > But it all passed out these block, never entered if sentence(line 445) > block. > At that time tp->t_flags was 0xA1,flags was 0x12. > > line 445-510 > /* > * Send `CC-family' options if our side wants to use them (TF_REQ_CC), > * options are allowed (!TF_NOOPT) and it's not a RST. > */ > if ((tp->t_flags & (TF_REQ_CC|TF_NOOPT)) == TF_REQ_CC && > (flags & TH_RST) == 0) { > switch (flags & (TH_SYN|TH_ACK)) { > /* > * This is a normal ACK, send CC if we received CC before > * from our peer. > */ > case TH_ACK: > if (!(tp->t_flags & TF_RCVD_CC)) > break; > /*FALLTHROUGH*/ > > /* > * We can only get here in T/TCP's SYN_SENT* state, when > * we're a sending a non-SYN segment without waiting for > * the ACK of our SYN. A check above assures that we only > * do this if our peer understands T/TCP. > */ > case 0: > opt[optlen++] = TCPOPT_NOP; > opt[optlen++] = TCPOPT_NOP; > opt[optlen++] = TCPOPT_CC; > opt[optlen++] = TCPOLEN_CC; > *(u_int32_t *)&opt[optlen] = htonl(tp->cc_send); > > optlen += 4; > break; > > /* > * This is our initial SYN, check whether we have to use > * CC or CC.new. > */ > case TH_SYN: > opt[optlen++] = TCPOPT_NOP; > opt[optlen++] = TCPOPT_NOP; > opt[optlen++] = tp->t_flags & TF_SENDCCNEW ? > TCPOPT_CCNEW : TCPOPT_CC; > opt[optlen++] = TCPOLEN_CC; > *(u_int32_t *)&opt[optlen] = htonl(tp->cc_send); > optlen += 4; > break; > > /* > * This is a SYN,ACK; send CC and CC.echo if we received > * CC from our peer. > */ > case (TH_SYN|TH_ACK): > if (tp->t_flags & TF_RCVD_CC) { > opt[optlen++] = TCPOPT_NOP; > opt[optlen++] = TCPOPT_NOP; > opt[optlen++] = TCPOPT_CC; > opt[optlen++] = TCPOLEN_CC; > *(u_int32_t *)&opt[optlen] = > htonl(tp->cc_send); > optlen += 4; > opt[optlen++] = TCPOPT_NOP; > opt[optlen++] = TCPOPT_NOP; > opt[optlen++] = TCPOPT_CCECHO; > opt[optlen++] = TCPOLEN_CC; > *(u_int32_t *)&opt[optlen] = > htonl(tp->cc_recv); > optlen += 4; > } > break; > } > } Please help me to resolve problem. Thank you in advance. -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss