On Wed, 1 Jan 2003, Antonio I. wrote: > I found this website on the net: > http://www.robertgraham.com/pubs/sniffing-faq.html > Take a look at it. Go to section 5.1 and look at one of the example > packets. Well, the author mentions that packets may be as large as 1500 > bytes or more. Although the data of the packet displayed there is not > 1500 bytes long, it does contain many more things that I am not seeing > in my dumps, including the http data. One thing I noticed was that the > beginning of his packet was very similar to what I get. Then I thought > that maybe the method I am using to dump is only giving me the first > part of the packet data, maybe only the tcp and ip header information > (I'm guessing here). Well I assume that our method of dumping: tcpdump > -X -i en0 is not giving us the whole thing. Is there a way to get the > rest of the data from the packet using tcpdump? I sent an email to the > author of the paper asking the same question. I doubt I will get an > answer because it seems he wrote this paper back in 2000, so he may not > keep track of his messages.
Have a look at the man pages. By default, tcpdump captures about 68 bytes of each frame. You want: tcpdump -s <some-larger-frame-size> ... It's all in the man pages. > [EMAIL PROTECTED] wrote: > > >On Mon, Dec 30, 2002 at 09:07:23PM -0500, Antonio I. wrote: > > > >>I think we are moving forward. The output from putting -X is quite > >>peculiar. I see data, just plain data, but I don't see a way to > >>interpret it. Let me give you an example of what I get on my terminal: > >> > >>20:41:02.760587 205.188.7.140.5190 > 192.168.2.8.49682: . ack 1 win > >>16384 (DF) > >>0x0000 4500 0028 dd37 4000 2b06 da9f cdbc 078c E..(.7@.+....... > >>0x0010 c0a8 0208 1446 c212 6932 51e8 a91e 4860 .....F..i2Q...H` > >>0x0020 5010 4000 54e9 0000 0000 0000 0000 4944 [email protected] > >>0x0030 0057 .W > >> > > > >Well, the "45" is the first byte of the IP header. To see a way to > >interpret it, and the rest of the IP header, read RFC 791. > > > >You're assuming here that there's more ASCII in network traffic than > >there really is. In, for example, an Ethernet packet containing an HTTP > >reply, there is an Ethernet header (not normally shown by "-X"), an IP > >header, a TCP header, and then, *after* the IP and TCP header, the HTTP > >reply header and data. > > > >The HTTP reply header is ASCII, and, *IF* the stuff being fetched over > >HTTP is text (e.g., HTML text), the HTTP reply data is ASCII as well. > > > >>Ok, so then let me ask you this, is it possible at all to obtain html > >>data from a tcpdump? > >> > > > >Yes, but that packet isn't a packet containing any HTML data. It's a > >TCP acknowledgment with no data in it. Read RFC 793 to understand > >what's in a TCP packet. > > > >Furthermore, tcpdump won't extract *just* the HTML data; it's not an > >HTML-data-extraction program, it's a network traffic analysis program. > > > > > - > This is the TCPDUMP workers list. It is archived at > http://www.tcpdump.org/lists/workers/index.html > To unsubscribe use mailto:[EMAIL PROTECTED]?body=unsubscribe > -- Regards ----- Richard Sharpe, rsharpe[at]ns.aus.com, rsharpe[at]samba.org, sharpe[at]ethereal.com, http://www.richardsharpe.com - This is the TCPDUMP workers list. It is archived at http://www.tcpdump.org/lists/workers/index.html To unsubscribe use mailto:[EMAIL PROTECTED]?body=unsubscribe
