TCPDUMP to x.x.x.x results from server: need detail explanation...

Posted on 2001-06-15
Medium Priority
Last Modified: 2012-06-27
My server AAAAA recently had a problem routing packets to x.x.x.x (a remote internet site) from AAAA through the local gateway. The problem lies in the local gateway because of some routing rules to this destination.
I used TCPDUMP to trace packets from server AAAAA to this destination and there were many packets (refer to PART A below) which does NOT appear if there are NO problems during normal operation... PART B comes from a traceroute to x.x.x.x.

what does the result mean below (PART A and PART B)...?
Is it trying to do a SYN but keeps on failing (PART A)?
Please explain in as much detail as possible. :)

Is there also any good online tutorial for "tcpdump" besides the "man".


AAAAA# tcpdump -n -i fxp0 host x.x.x.x (PROBLEM IP)
tcpdump: listening on fxp0

>>>>>>>>> PART A result >>>>>>>>
11:58:39.271607 172.17.7.x.25807 > x.x.x.x.80: S 4188981893:4188981893(0) win 16384 <mss 1460> (DF)
11:58:39.571609 172.17.7.x.25812 > x.x.x.x.80: S 4197969350:4197969350(0) win 16384 <mss 1460> (DF)
11:58:39.751609 172.17.7.x.25810 > x.x.x.x.80: S 4194147698:4194147698(0) win 16384 <mss 1460> (DF)
11:58:43.191664 172.17.7.x.25811 > x.x.x.x.80: S 4197359568:4197359568(0) win 16384 <mss 1460> (DF)
>>>>>> END OF PART A >>>>>>

11:58:43.505905 172.17.7.x.38038 > x.x.x.x.33435:  udp 12 [ttl 1]
11:58:43.511176 172.17.7.x.38038 > x.x.x.x.33436:  udp 12 [ttl 1]
11:58:43.518859 172.17.7.x.38038 > x.x.x.x.33437:  udp 12 [ttl 1]
11:58:43.526274 172.17.7.x.38038 > x.x.x.x.33438:  udp 12
11:58:43.530802 172.17.7.x.38038 > x.x.x.x.33439:  udp 12
11:58:43.534002 172.17.7.x.38038 > x.x.x.x.33440:  udp 12
11:58:43.538140 172.17.7.x.38038 > x.x.x.x.33441:  udp 12
>>>>>>> END OF  PART B
552 packets received by filter
0 packets dropped by kernel
Question by:thiamwah
  • 2

Author Comment

ID: 6197508
also, what does "<mss 1460>" and "(DF)" mean?

Accepted Solution

jbuda earned 400 total points
ID: 6199802
For Part A:
The first line says that tcp port 25807 on fxp0 (172.17.7.X) sent a packet ?to x.x.x.x.80:  

The S indicates that the SYN flag was set.

The packet sequence number was 4188981893:4188981893(0) and it contained no data. (The notation is `first:last(nbytes)' which means `sequence numbers first up to but not including last which is (0) bytes of user data'.)

The available receive window (buffer availablity of the sender) was 16384 bytes and there was a max-segment-size option requesting an "mss" of 1460 bytes (ethernet).

NOTE NOTE NOTE: The DF bit (don't fragment) is set. This means if your packet crosses a  router port with a "mss" (max-segment-size) less than 1460 the router must discard the packet as the DF bit tells the router
"do not fragment" this packet into smaller packets. ie Do not break up the packet into two (or more) smaller packets. (This could be why the packet never reached its destination).

Normally the router that discards a packet for this reason will generate an ICMP error message back to the sending workstation. But the 172.17.7.X indicates your using private internal IP addressing, this means that a NAT gateway (router) must translate this private IP to a public IP. The ICMP error may not get back through the NAT. Depends on router configuration/capabilities.

Part B
The same host sent a UDP packet payload of 12 bytes with a TTL (time-to-live) of 1, you removed all the IP addressing for the destinations so further explanation of the trace will be how traceroute works.
TTL is the mechanism that ages out packets on the netwroks so they do not endlessy get forwarded in the vent of a routing loop.

Traceroutes function is to determine how many hops (or routers) are being crossed to reach a destination.
With a list of router IP addresses you then know the path a packet took to reach the destination.
To accomplish this traceroute starts be sending a packet (typically and ICMP "echo request" (commonly reffered to as Ping) to the destination IP with a TTL of 1. Routers look at the TTL field of every packet and decrement it each time they forward a packet. If the TTL reaches zero the packet is discarded (and another ICMP error message is sent to the sending workstation saying TTL expired). This error message contains the IP address of the router interface that discarded the packet. Traceroute will then increment the TTL (to 2, then 3, then 4 etc..) you will (hopefully) get a list of router IP's crossed to reach the destination. Please note not all router will respond to traceroutes, some are configured to not generate ICMP errors, this is for security reasons.

Anyway the TTL is incremented until the destination reponds to the Ping.



Expert Comment

ID: 6204597
thanks thiamwah..appreciate the points..
was the DF bit your problem??? just curios..
I've seen some software set this before, its ok on local ethernets, but
once you hit data circuits lookout..

Featured Post

Free Tool: SSL Checker

Scans your site and returns information about your SSL implementation and certificate. Helpful for debugging and validating your SSL configuration.

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.

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

I have seen several blogs and forum entries elsewhere state that because NTFS volumes do not support linux ownership or permissions, they cannot be used for anonymous ftp upload through the vsftpd program.   IT can be done and here's how to get i…
Note: for this to work properly you need to use a Cross-Over network cable. 1. Connect both servers S1 and S2 on the second network slots respectively. Note that you can use the 1st slots but usually these would be occupied by the Service Provide…
If you're a developer or IT admin, you’re probably tasked with managing multiple websites, servers, applications, and levels of security on a daily basis. While this can be extremely time consuming, it can also be frustrating when systems aren't wor…
Stellar Phoenix SQL Database Repair software easily fixes the suspect mode issue of SQL Server database. It is a simple process to bring the database from suspect mode to normal mode. Check out the video and fix the SQL database suspect mode problem.
Suggested Courses
Course of the Month4 days, 10 hours left to enroll

601 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question