Loading ...
Sorry, an error occurred while loading the content.

Re: OUT PUT of TCPDUMP

Expand Messages
  • Vern Paxson
    ... Actually, it is just sending one acknowledgement, which you can tell because the two acks have the same IP ID field. But that single ack is passing by the
    Message 1 of 10 , Nov 5, 1997
    • 0 Attachment
      > 12:30:19.380434 wlan.16065 > ibmh8.3128: . ack 7680 win 31744 (DF) (ttl 64, id 48913)
      > 12:30:19.380434 wlan.16065 > ibmh8.3128: . ack 7680 win 31744 (DF) (ttl 63, id 48913)
      >
      > Now my question is that as I can see my 'wlan' is sending two
      > acknowledgement for every tcp segment it is receiving from the proxy
      > server.

      Actually, it is just sending one acknowledgement, which you can tell because
      the two acks have the same IP ID field.

      But that single ack is passing by the packet filter twice. It is possible
      that the ack is getting replicated by the network - I've observed a similar
      pattern to what you show, with a trace at the receiver showing each packet
      arriving twice. I never was able to identify the mechanism causing this,
      though.

      > Both the acknowledgements are send at the same instant

      That's just an artifact of the limited resolution of the clock used
      by the packet filter (which clearly only advances every 20 msec).

      Vern
    • Chetan Kumar
      The following is the output of tcpdump for connection between wlan- running redhat linux 2.0.30; running netscape to download a file from the proxy server.
      Message 2 of 10 , Nov 6, 1997
      • 0 Attachment
        The following is the output of tcpdump for connection between

        wlan-> running redhat linux 2.0.30; running netscape to download a file
        from the proxy server.

        ibmh8-> IMB AIX Version 4 , proxy server.

        12:30:19.160434 ibmh8.3128 > wlan.16065: P 6144:6656(512) ack 1 win 16060 (ttl 60, id 3134)
        12:30:19.180434 wlan.16065 > ibmh8.3128: . ack 6656 win 31744 (DF) (ttl 64, id 48911)
        12:30:19.180434 wlan.16065 > ibmh8.3128: . ack 6656 win 31744 (DF) (ttl 63, id 48911)
        12:30:19.200434 ibmh8.3128 > wlan.16065: P 6656:7168(512) ack 1 win 16060 (ttl 60, id 3137)
        12:30:19.220434 wlan.16065 > ibmh8.3128: . ack 7168 win 31744 (DF) (ttl 64, id 48912)
        12:30:19.220434 wlan.16065 > ibmh8.3128: . ack 7168 win 31744 (DF) (ttl 63, id 48912)
        12:30:19.360434 ibmh8.3128 > wlan.16065: P 7168:7680(512) ack 1 win 16060 (ttl 60, id 3148)
        12:30:19.380434 wlan.16065 > ibmh8.3128: . ack 7680 win 31744 (DF) (ttl 64, id 48913)
        12:30:19.380434 wlan.16065 > ibmh8.3128: . ack 7680 win 31744 (DF) (ttl 63, id 48913)

        Now my question is that as I can see my 'wlan' is sending two
        acknowledgement for every tcp segment it is receiving from the proxy
        server.

        Both the acknowledgements are send at the same instant, as I can see from
        the time stamp, also the ttl is reduced by one for the second
        acknowledgement.

        Can anybody explain why this is happening.

        Thanks for any response

        chetan . S

        ::::::::::: TREE SAVES THOSE WHO SAVE TREES ::::::::::::


        E-mail chetan@...

        WEB PAGE - http://pclab.ece.iisc.ernet.in/chetan

        Snail mail
        #104 ,East Park Road,
        8 th Cross,Malleshwarm,
        Bangalore,
        Karnataka,India.
        pin 560003.

        Phone
        work place
        (080)3092282
        res.
        (080)3349218
        (080)3347220
      • Chetan Kumar
        On Wed, 5 Nov 1997, Vern Paxson wrote: * 12:30:19.380434 wlan.16065 ibmh8.3128: . ack 7680 win 31744 (DF) (ttl 64, id 48913) * 12:30:19.380434 wlan.16065
        Message 3 of 10 , Nov 6, 1997
        • 0 Attachment
          On Wed, 5 Nov 1997, Vern Paxson wrote:

          *>> 12:30:19.380434 wlan.16065 > ibmh8.3128: . ack 7680 win 31744 (DF) (ttl 64, id 48913)
          *>> 12:30:19.380434 wlan.16065 > ibmh8.3128: . ack 7680 win 31744 (DF) (ttl 63, id 48913)
          *>>
          *>Actually, it is just sending one acknowledgement, which you can tell because
          *>the two acks have the same IP ID field.
          *>
          *>But that single ack is passing by the packet filter twice. It is possible
          *>that the ack is getting replicated by the network - I've observed a similar
          *>pattern to what you show, with a trace at the receiver showing each packet
          *>arriving twice. I never was able to identify the mechanism causing this,
          *>though.
          *>
          *> Vern
          *>

          But what do say about the ttl ? As I can see the ttl is getting reduced by
          one for the second ack.
        • C. Harald Koch
          ... tcpdump -e is very useful in these cases; you often find that the outbound packet is going direct, while the inbound packet is bouncing off a router. This
          Message 4 of 10 , Nov 6, 1997
          • 0 Attachment
            In message <Pine.LNX.3.95.971106144523.8729A-100000@...>, Chetan Kumar writes:
            >
            > But what do say about the ttl ? As I can see the ttl is getting reduced by
            > one for the second ack.

            tcpdump -e is very useful in these cases; you often find that the outbound
            packet is going direct, while the inbound packet is bouncing off a router.
            This is usually caused by routing and/or netmask configuration errors on the
            remote host (in this case wlan).

            --
            Harald
          • Wu-chang Feng
            ... Are you running tcpdump on the same machine (i.e. wlan?) I had a problem similar to this where, on a token ring network, the filter would see the ACK
            Message 5 of 10 , Nov 6, 1997
            • 0 Attachment
              > Now my question is that as I can see my 'wlan' is sending two
              > acknowledgement for every tcp segment it is receiving from the proxy
              > server.

              Are you running tcpdump on the same machine (i.e. wlan?)
              I had a problem similar to this where, on a token ring network,
              the filter would see the ACK initially sent out as well as a copy
              of the ACK as it came back around the token ring. Running
              tcpdump on a different machine on the token ring network,
              eliminated the problem. This wouldn't explain the identical
              timestamp, however. The duplicates I saw in the output had
              different timestamps.

              Wu
            • Vern Paxson
              ... Good point! Here s the trace I mentioned before, as recorded at the sender: 23:21:27.468911 0:0:c0:e5:54:8e 0:0:c:38:a8:2b ip 566: ABC.7505 XYZ.7505: .
              Message 6 of 10 , Nov 6, 1997
              • 0 Attachment
                > tcpdump -e is very useful in these cases ...

                Good point!

                Here's the trace I mentioned before, as recorded at the sender:

                23:21:27.468911 0:0:c0:e5:54:8e 0:0:c:38:a8:2b ip 566:
                ABC.7505 > XYZ.7505: . 91137:91649(512)
                ack 1 win 4096 (ttl 60, id 45658)

                23:21:27.469461 0:0:c0:e5:54:8e 0:0:c:38:a8:2b ip 566:
                ABC.7505 > XYZ.7505: . 91649:92161(512)
                ack 1 win 4096 (ttl 60, id 45659)

                23:21:27.473008 0:0:c0:d2:3e:96 0:0:c:38:a8:2b ip 566:
                ABC.7505 > XYZ.7505: . 91137:91649(512)
                ack 1 win 4096 (ttl 59, id 45658)

                The sender transmits 91137:91649 with IP ID 45658 and TTL 60. Soon
                after it transmits 91649:92161 with IP ID 45659. Then the packet filter
                sees 91137:91649 again, only this time with TTL 59 (but same ID), and
                coming from a different link-layer address (but, surprisingly, headed
                to the same link-layer address, so not a simple case of the first-hop
                router redirecting it).

                Here's the same traffic recorded at the receiver (clocks are not
                closely synchronized):

                23:21:27.370635 0:0:c:d:ff:32 8:0:20:23:19:e1 ip 566:
                ABC.7505 > XYZ.7505: . 91137:91649(512)
                ack 1 win 4096 (ttl 52, id 45658)

                23:21:27.373372 0:0:c:d:ff:32 8:0:20:23:19:e1 ip 566:
                ABC.7505 > XYZ.7505: . 91649:92161(512)
                ack 1 win 4096 (ttl 52, id 45659)

                23:21:27.385453 0:0:c:d:ff:32 8:0:20:23:19:e1 ip 566:
                ABC.7505 > XYZ.7505: . 91137:91649(512)
                ack 1 win 4096 (ttl 51, id 45658)

                Clearly, the packet has been replicated, as it arrives twice.

                Wu-chang Feng writes:

                > The duplicates I saw in the output had different timestamps.

                I think that's a red herring in the case Chetan's describing - in the
                example above, if the clock resolution were 10 msec, then all of the
                sender-side packets would've had the same timestamp too.

                Vern
              • C. Harald Koch
                ... Some Linux boxes will replicate packets like this if an interface gets set to promiscuous mode; I just saw a similar event on our DMZ caused by a Linux
                Message 7 of 10 , Nov 6, 1997
                • 0 Attachment
                  In message <199711062132.NAA25814@...>, Vern Paxson writes:

                  > The sender transmits 91137:91649 with IP ID 45658 and TTL 60. Soon
                  > after it transmits 91649:92161 with IP ID 45659. Then the packet filter
                  > sees 91137:91649 again, only this time with TTL 59 (but same ID), and
                  > coming from a different link-layer address (but, surprisingly, headed
                  > to the same link-layer address, so not a simple case of the first-hop
                  > router redirecting it).

                  Some Linux boxes will replicate packets like this if an interface gets set to
                  promiscuous mode; I just saw a similar event on our DMZ caused by a Linux
                  machine replicating traffic.

                  --
                  Harald Koch <chk@...>
                • Vern Paxson
                  ... Interesting. In this case, neither machine was running Linux (they were BSDI 1.1 and Solaris 2.4). Vern
                  Message 8 of 10 , Nov 6, 1997
                  • 0 Attachment
                    > Some Linux boxes will replicate packets like this if an interface gets set to
                    > promiscuous mode; I just saw a similar event on our DMZ caused by a Linux
                    > machine replicating traffic.

                    Interesting.

                    In this case, neither machine was running Linux (they were BSDI 1.1 and
                    Solaris 2.4).

                    Vern
                  • Chetan Kumar
                    Here is somthing I got with -e option in TCPDUMP 2:60:8c:2c:fc:86 0:40:5:1d:e9:2e ip 566: ibmh8.3128 wlan.3367: P 311296:311808(512) ack 1 win 16060 (ttl 60,
                    Message 9 of 10 , Nov 7, 1997
                    • 0 Attachment
                      Here is somthing I got with -e option in TCPDUMP

                      2:60:8c:2c:fc:86 0:40:5:1d:e9:2e ip 566: ibmh8.3128 > wlan.3367: P
                      311296:311808(512) ack 1 win 16060 (ttl 60, id 5084)

                      0:40:5:1d:e9:2e 0:0:c:19:31:b8 ip 54: wlan.3367 > ibmh8.3128: . ack 311808
                      win 31744 (DF) (ttl 64, id 45844)

                      0:0:c:19:31:b8 2:60:8c:2c:fc:86 ip 60: wlan.3367 > ibmh8.3128: . ack
                      311808 win 31744 (DF) (ttl 63, id 45844)



                      2:60:8c:2c:fc:86 0:40:5:1d:e9:2e ip 566: ibmh8.3128 > wlan.3367: P
                      311808:312320(512) ack 1 win 16060 (ttl 60, id 5086)

                      0:40:5:1d:e9:2e 0:0:c:19:31:b8 ip 54: wlan.3367 > ibmh8.3128: . ack 312320
                      win 31744 (DF) (ttl 64, id 45849)

                      0:0:c:19:31:b8 2:60:8c:2c:fc:86 ip 60: wlan.3367 >ibmh8.3128: . ack
                      312320 win 31744 (DF) (ttl 63, id 45849)


                      In my case it is clearly, the first hop router redirecting. Also,
                      I confirmed that 0:0:c:19:31:b8 is the hardware address of the default
                      router on my 'wlan'. So there is no duplecate of packets (?).

                      chetan . S
                    • Alan Cox
                      Message 10 of 10 , Nov 8, 1997
                      • 0 Attachment
                        > Some Linux boxes will replicate packets like this if an interface gets set to
                        > promiscuous mode; I just saw a similar event on our DMZ caused by a Linux
                        > machine replicating traffic.

                        No.

                        Linux will respond to packets addressed to it but with the wrong MAC address
                        in 2.0.x (probably not 2.0.32 when it appears). It will not however forward
                        frames for others that fall into this category
                      Your message has been successfully submitted and would be delivered to recipients shortly.