Re: using TCPDump

["Antonio I." <cocoadeveloper () netscape net>]

Maybe I have not explained myself properly. The reason for bringing up 
the example of traceroute was because that was what I initially tried, 
not particularly the only thing I pretended to do with tcpdump. I did 
subsequent dumps on my ethernet card while accessing a web page and the 
output was basically of the same type as when doing the traceroute, a 
lot like the examples you gave. I expected to see ascii data, that is, 
the html data from the server, among other things. But that was not the 
case, in fact I did not see anything at all related to html data. This 
is why I refered to it as meaningless. Maybe I had a different picture 
of what tcpdump was. You see my inital interest in this program was, as 
I thought, its ability to look at information going to or coming out of 
a machine, in plain text form. For example if someone is accessing an 
unsecure service such as telnet ( insecure telnet that is, because as I 
have heard there is now secure telnet ) and I am listening to port 23, I 
would be able to see the username and password information. Or any other 
purpose for that matter. Well, thanks again Harris.
Tony

gharris () sonic net wrote:

> 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