The tcpdump Strings trick:
"
In these cases, speed and convenience reign supreme. The following trick is along these lines and is one of my favorite tcpdump techniques. It works because:
1. TCP segments usually are sent in chronological order.
2. Text-based application protocols produce TCP segments with text payloads.
3. The data surrounding the text payloads, such as packet headers, is usually not text. strings filters out binary data from streams preserving only text (printable characters).
5. When tcpdump is called with -w - it prints raw packets to STDOUT.
Put it all together, and you get a command that dumps real-time HTTP session data:
tcpdump -l -s0 -w - tcp dst port 80 | strings
The -l option above turns on line buffering, which makes sure data gets printed to the screen right away.
What is happening here is tcpdump is printing the raw, binary data to the screen. This uses a twist on the -w option where the special filename - writes to STDOUT instead of a file. Normally, doing this would display all kinds of gibberish, but that’s where the strings command comes in—it allows only data recognized as text through to the screen. There are few caveats to be aware of. First, data from multiple sessions received simultaneously is displayed simultaneously, clobbering your output. The more refined you make the filter expression, the less of a problem this will be. You also should run separate commands (in separate shells) for the client and server side of a session:
tcpdump -l -s0 -w - tcp dst port 80 | strings
tcpdump -l -s0 -w - tcp src port 80 | strings
Also, you should expect to see a few gibberish characters here and there whenever a sequence of binary data also happens to look like text characters. You can cut down on this by increasing min-len (see the strings man page). This trick works just as well for other text-based protocols.
To see websites being accessed in real time:
tcpdump -i eth1 -l -s0 -w - host davepc and port 80 \ | strings | grep 'GET\|Host'
To watch email senders and recipients in real time:
tcpdump -l -s0 -w - tcp dst port 25 | strings \ | grep -i 'MAIL FROM\|RCPT TO'
Debugging Routes and VPN Links
If it’s operating properly, hosts from either network should be able to ping one another. However, if you are not getting replies when pinging host D from host A, for instance, you can use tcpdump to zero in on exactly where the breakdown is occurring:
tcpdump -tn icmp and host 10.0.50.2
In this example, during a ping from 10.0.50.2 to 192.168.5.38, each round trip should show up as a pair of packets like the following, regardless of from which of the four systems the tcpdump command is run:
IP 10.0.50.2 > 192.168.5.38: ICMP echo request, id 46687, seq 1, length 64
IP 192.168.5.38 > 10.0.50.2: ICMP echo reply, id 46687, seq 1, length 64
If the request packets make it to host C (the remote gateway) but not to D, this indicates that the VPN itself is working, but there could be a routing problem. If host D receives the request but doesn’t generate a reply, it probably has ICMP blocked. If it does generate a reply but it doesn’t make it back to C, then D might not have the right gateway configured to get back to 10.0.50.0/24.
Using tcpdump, you can follow the ping through all eight possible points of failure as it makes its way across the network and back again."
4. The UNIX command
