Re: [ECOS] Can't Connect,TCP CHECKSUM INCORRECT

["ariga masahiro" <ariga@link-lab.co.jp>]

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=="<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 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