Re: using TCPDump

[Guy Harris <gharris () sonic net>]

On Sat, Dec 28, 2002 at 09:15:27PM -0500, Antonio I. wrote:
>     Gharris, thanks for all the answers, I appreciate them a lot. I 
> tried what you told me and got it to work. tcpdump began listening on my 
> ethernet card.

So did you have to use the "-i" flag?  Or did you have to do something
more than that?

> Although this is a step forward, this is not what I was 
> trying to achieve. What I was really trying to get to was sniffing 
> packets going to other machines. Say I would like to listen on all 
> requests on port 23 being made at 147.70.18.33, how would I go about 
> doing this?

Step 1: either make sure the network your machine is on isn't on a
switched network and that it's not plugged into a a dual-speed hub being
used for both 10Mb and 100Mb traffic or, if the network it's on is a
switched network, make the port it's plugged into a "mirrored" port, if
your switch supports it (I don't know anything abou what switches
support it, or how to make a port a mirrored port):

        http://www.tcpdump.org/faq.html#q4

        http://www.tcpdump.org/faq.html#q5

>     And, also, the results that tcpdump spews out is pretty meaningless. 
> What's more, I didn't see any ansi data in the output. ( I did this 
> while doing a traceroute ).

There's not much interesting ASCII (I assume that's what you mean by
"ansi") text in the traffic you get from a traceroute, but, with more
recent versions of tcpdump, if you use the "-X" flag, you'll get a dump
of the raw hex data in the packet and that data shown as ASCII.

> Know of any programs that can make this output more meaningfull?

Well, that depends on what you mean by "meaningless" or "more
meaningful".  The tcpdump output I get from a traceroute is

14:01:43.565701 IP {my machine}.1091 > {my DNS server}.domain:  53754+[|domain]
14:01:43.583839 IP {my DNS server}.domain > {my machine}.1091:  53754 1/4/4 (181) (DF)
14:01:43.584498 IP {my machine}.33142 > {destination machine}.33435: udp 12
14:01:43.584909 IP {my firewall} > {my machine}: icmp 92: time exceeded in-transit
14:01:43.585267 IP {my machine}.33142 > {destination machine}.33436: udp 12
14:01:43.585669 IP {my firewall} > {my machine}: icmp 92: time exceeded in-transit
14:01:43.591624 IP {my machine}.33142 > {destination machine}.33437: udp 12

        ...

(I've replaced the host name of my machine with "{my machine}", the host
name of my machine's DNS server with "{my DNS server}, the host name of
the machine being tracerouted to with "{destination machine}, and the
host name of my firewall box with "{my firewall}") which says that the
first packet is a DNS packet - but not enough of the packet's data was
captured to decode, as, by default, tcpdump captures only the first 68
bytes of the packet - and the second packet was a DNS reply.

Then there was a UDP packet sent from my machine to the machine to which
I was tracerouting, and an ICMP "time exceeded" message, and then that
happened again, and then another UDP packet was sent.  The UDP port
number on my machine was 33142, and various UDP port numbers were used
on the destination machine (traceroute uses UDP rather than ICMP by
default; as I remember, that's because there was no guarantee of ICMP
ECHOs being processed in such a way that traceroute would actually
work).

I removed subsequent packets.

"tcpdump -s 65535", so that the entire packet will be captured, gives

14:10:21.193360 IP {my machine}.1139 > {my DNS server}.domain:  33451+ A? www.sun.com. (29)
14:10:21.211226 IP {my DNS server}.domain > {my machine}.1139:  33451 1/4/4 A {destination machine} (181) (DF)
14:10:21.211860 IP {my machine}.33152 > {destination machine}.33435: udp 12
14:10:21.212271 IP {my firewall} > {my machine}: icmp 92: time exceeded in-transit
14:10:21.212625 IP {my machine}.33152 > {destination machine}.33436: udp 12
14:10:21.213027 IP {my firewall} > {my machine}: icmp 92: time exceeded in-transit
14:10:21.218978 IP {my machine}.33152 > {destination machine}.33437: udp 12
14:10:21.219381 IP {my firewall} > {my machine}: icmp 92: time exceeded in-transit
14:10:21.219680 IP {my machine}.33152 > {destination machine}.33438: udp 12
14:10:21.235832 IP adsl-209-204-185-1.sonic.net > {my machine}: icmp 36: time exceeded in-transit

        ...

which shows some additional data, namely that the first DNS packet was
looking for an A record (IP address) for "www.sun.com" (the machine to
which I was tracerouting), and that the reply gave its IP address.

Some of that might not be meaningful if you don't know the way
traceroute, or DNS, or ICMP, work - but there's no program on the planet
that'd fix that problem.

You could use, for example, Ethereal:

        http://www.ethereal.com/

(it's GPLed free software - it's ".com" because somebody already had
"ethereal.org"), which includes both a GUI sniffer for UNIX+X and
Windows and a tty-oriented sniffer like tcpdump and snoop; they can give
a more detailed description of the contents of the packet, but, again,
that's more detailed but not necessarily more *meaningful* if you're not
familiar with the protocols being used.
-
This is the TCPDUMP workers list. It is archived at
http://www.tcpdump.org/lists/workers/index.html
To unsubscribe use mailto:tcpdump-workers-request () tcpdump org?body=unsubscribe