Improve company productivity with a Business Account.Sign Up

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 1446
  • 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
Free Tool: IP Lookup

Get more info about an IP address or domain name, such as organization, abuse contacts and geolocation.

One of a set of tools we are providing to everyone as a way of saying thank you for being a part of the community.

 
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
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

Join & Write a Comment

Featured Post

Free Tool: Port Scanner

Check which ports are open to the outside world. Helps make sure that your firewall rules are working as intended.

One of a set of tools we are providing to everyone as a way of saying thank you for being a part of the community.

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