Go Premium for a chance to win a PS4. Enter to Win

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 1440
  • Last Modified:

Tcpdump output -- need interpretation

Hello All,

I need to understand what is going on in this tcpdump output. Its from a simple http request from a vpn'd client to an FC2 box:

19:49:33.516582 IP 192.168.2.21.2085 > 192.168.1.240.http: S 1753009426:1753009426(0) win 65535 <mss 1260,nop,nop,sackOK>
19:49:33.552420 IP 192.168.1.240.http > 192.168.2.21.2085: S 2686314030:2686314030(0) ack 1753009427 win 5840 <mss 1460,nop,nop,sackOK>
19:49:36.487145 IP 192.168.2.21.2085 > 192.168.1.240.http: S 1753009426:1753009426(0) win 65535 <mss 1260,nop,nop,sackOK>
19:49:36.487191 IP 192.168.1.240.http > 192.168.2.21.2085: S 2686314030:2686314030(0) ack 1753009427 win 5840 <mss 1460,nop,nop,sackOK>
19:49:37.115512 IP 192.168.1.240.http > 192.168.2.21.2085: S 2686314030:2686314030(0) ack 1753009427 win 5840 <mss 1460,nop,nop,sackOK>
19:49:42.495742 IP 192.168.2.21.2085 > 192.168.1.240.http: S 1753009426:1753009426(0) win 65535 <mss 1260,nop,nop,sackOK>
19:49:42.495785 IP 192.168.1.240.http > 192.168.2.21.2085: S 2686314030:2686314030(0) ack 1753009427 win 5840 <mss 1460,nop,nop,sackOK>
19:49:43.121442 IP 192.168.1.240.http > 192.168.2.21.2085: S 2686314030:2686314030(0) ack 1753009427 win 5840 <mss 1460,nop,nop,sackOK>


The client is unable to complete http session (timesout), I have tried this using same vpn client to another Linux box (RH9)in the same internal net, but the session is completed and the tcpdump out looks normal. Any ideas?


Thanks,
GR
0
GR999
Asked:
GR999
  • 3
  • 2
1 Solution
 
pablouruguayCommented:
i think this log is ok. check the errors in the NIC with ifconfig
0
 
de2ZotjesCommented:
On which box did you take this tcpdump? I would say on the FC2?

What is happening is that the connection does not come up completely, you see a syn and a syn/ack. This sort of "half" connected problem normally indicates a routing problem.
0
 
GR999Author Commented:
Do you guys know of anything on the internet to help decipher some of the output? I have no idea what mss, nop and sack (syn/ack?) is. I probably won't go into detail on the network as this is probably wrong forum for that, was just wondering on how to understand more of this ouput.


Thanks,
GR
0
Technology Partners: We Want Your Opinion!

We value your feedback.

Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!

 
GR999Author Commented:
Sorry, yes this was taken on the FC2 box. Another note is the FC2 is actually NAT'd to a different public ip off the router all others are running PAT off the router ip. I'm thinking that my be the issue but not sure why.

Thanks,
GR
0
 
de2ZotjesCommented:
If you are looking for deciphering of the actual letters: rtfm for tcpdump.

If you want to understand more of what this bit of output is telling us:

first of all the same pattern of lines repeats 3 times, with increasing intervals (the very first field is capturetime). That is the first clue that the connection is not established because the tcp protocol will retry sending packets with a "exponential backoff"

Second all the packets that we see here have the syn flag set (the capital S in the output, if no flags then that spot would have a . ) The syn flag is what is used to set up a connection between to machines.
If you are looking for exact details on how tcp does that I can suggest some good books :) Basically there are 3 packets needed to setup a connection:
syn ->
syn/ack <-
ack ->

You see that the last does not have the syn flag set, this means you can easily spot the point where actual data exchange between machines starts: when the syn flag is no longer set! Since in your dump all packets have the syn flag it is clear that the connection is never established.

Next step is just experience: this pattern of packets is consistent with a routing problem. Or in other words: packets can travel in one direction but not the other, whether that is caused by a faulty routing entry or by a malfunctioning nat rule remains to be seen...
0
 
GR999Author Commented:
Ok gotcha. I'm pretty sure it would not be a routing issue as I can ping back and forth:

05:27:33.353643 IP 192.168.2.21 > 192.168.1.240: icmp 40: echo request seq 256
05:27:33.354417 IP 192.168.1.240 > 192.168.2.21: icmp 40: echo reply seq 256
05:27:34.362542 IP 192.168.2.21 > 192.168.1.240: icmp 40: echo request seq 512
05:27:34.362591 IP 192.168.1.240 > 192.168.2.21: icmp 40: echo reply seq 512
05:27:35.363961 IP 192.168.2.21 > 192.168.1.240: icmp 40: echo request seq 768
05:27:35.364010 IP 192.168.1.240 > 192.168.2.21: icmp 40: echo reply seq 768
05:27:36.365449 IP 192.168.2.21 > 192.168.1.240: icmp 40: echo request seq 1024
05:27:36.365498 IP 192.168.1.240 > 192.168.2.21: icmp 40: echo reply seq 1024

Well either way I appreciate the help clearing up the original tcpdump question.

Thanks,
GR
0

Featured Post

Important Lessons on Recovering from Petya

In their most recent webinar, Skyport Systems explores ways to isolate and protect critical databases to keep the core of your company safe from harm.

  • 3
  • 2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now