This happened a while back, but I really can’t stress enough how great a program TCPdump is. A great way to show it is to include it in a real world example where I actually used it at work.
This was yet another simple problem that had to be addressed on one of the simulators at work. Once again, poor documentation left us in the dark with what was actually happening between the different hosts on a network and an environmental control unit sensor, which was supposed to relay information about the current temperature in the box to ultimately be displayed to the user on the IOS host computer.
The problem was that it would display *sometimes* and often erroneously. It would often seem to be “outdated” information, as in, that was what the temperature was a minute or two ago, especially a problem when you are trying to constantly monitor the temperature during a problem that leads to overheating. So, we dove in with TCPdump to find out how often it was updating the hosts, and who it was updating specifically. We already knew the IP address of the unit, as it has a digital display that told us so. We also knew where the information was displayed, on the IOS host, but we wanted to make sure the information didn’t stop somewhere else along the way.
$su
#tcpdump -avvv -i eth0 src 192.168.2.22 |tee ecutcpdump.txt
05:43:38.313916 IP (tos 0x0, ttl 64, id 2, offset 0, flags [none], proto TCP (6), length 40)
192.168.2.22.502 > IOS.local.2770: Flags [.], cksum 0x6d89 (correct), ack 17, win 512, length 0
E..(….@..f……….
….r.;.nP…m………
05:43:38.346370 IP (tos 0x0, ttl 64, id 3, offset 0, flags [none], proto TCP (6), length 63)
192.168.2.22.502 > IOS.local.2770: Flags [P.], cksum 0xc0a0 (correct), seq 1:24, ack 17, win 512, length 23
E..?….@..N……….
….r.;.nP……………. .B…B……..
05:43:38.563462 IP (tos 0x0, ttl 64, id 4, offset 0, flags [none], proto TCP (6), length 40)
192.168.2.22.502 > IOS.local.2770: Flags [.], cksum 0x6d71 (correct), ack 18, win 512, length 0
E..(….@..d……….
……;.oP…mq……..
05:43:39.076462 IP (tos 0x0, ttl 64, id 7, offset 0, flags [none], proto TCP (6), length 40)
192.168.2.22.502 > IOS.local.2771: Flags [.], cksum 0x9427 (correct), ack 17, win 512, length 0
E..(….@..a……….
…B…..P….’……..
05:43:39.106468 IP (tos 0x0, ttl 64, id 8, offset 0, flags [none], proto TCP (6), length 63)
192.168.2.22.502 > IOS.local.2771: Flags [P.], cksum 0xe734 (correct), seq 1:24, ack 17, win 512, length 23
E..?….@..I……….
…B…..P….4………..
Here we see our answers. First, it appears to be communicating with the IOS.local.2771 host, which correlated with the IOS host computer where the information was displayed. This was great to know, as it did not go through several hosts to get to the displaying host for the user. Second, it appears that the unit is communicating frequently. In fact, it seems to be communicating at least 3 times per second, as you can see in this section of the log file that I collected.
Ultimately, the problem turned out to be a software issue with the program that displays the information, but it was a good first step to rule out problems of communication being too sparse or going through multiple hosts on the network to reach the destination. Just another easy real world example of using TCPdump with Linux.
Linux – keep it simple.