Ethereal-users: RE: [Ethereal-users] Convert Cisco IOS debug packet dumps and showbuffer dump
Thanks Joshua,
I also already tried to get some knowledge from the packet with reading it "manually" and came to same result - the packet (or the dump) is either incomplete or crap. Also this is likely the cause for it to get stuck in the queue (which should although never happen but the big bang last week showed us it actually does happen).
Now getting to the point, as I have only limited access to the end-stations, I wanted to capture the packets on the router where these packets are sourced from with "debug..." and load this into ethereal to track down which packet/communication causes these trashed packets (I think they're fragments..)
Michael
-----Original Message-----
From: Joshua Wright [mailto:Joshua.Wright@xxxxxxx]
Sent: Wednesday, July 23, 2003 2:13 PM
To: Michael Markstaller; ethereal-users@xxxxxxxxxxxx
Subject: RE: [Ethereal-users] Convert Cisco IOS debug packet dumps and
showbuffer dump
Michael,
This isn't an Ethereal answer to your question, but if all you want to do is identify source/dest ports you just need to count the bytes offset to that portion of the embedded protocol. I suggest picking up a copy of Dr. Richard Stevens "TCP/IP Illustrated, volume 1" - it is an invaluable reference.
> I understood I have to convert this first to change the
> sequence number or smthg like that (I found a perl-script
> somewhere on the list archives) which outputs something like this:
> 00000000 45 00 00 2F FF 7E 00 B9 7E 11 F9 30 AC 17 29 6E
> 00000010 95 CC D8 03 A8 19 30 17 02 01 17 02 02 FF 7B 02
> 00000020 01 80 02 01 03 02 01 01 02 01 18 02 02 FF 79 01
Embedded protocol is 11 (9th byte offset). This is a UDP packet. Since the low-order nibble of the 0 byte offset is 5, we know the IP header length is 20 bytes, and there are no IP options set.
The UDP header starts at the 20th byte offset, giving us the source port of 0xa819 (43033), and dest port of 0x3017 (12311).
The information from the Cisco router only gave you a partial packet capture. The 4th and 5th bytes offset indicate the total length of the packet in bytes, including headers. This tells us that there 0x0201 bytes (513) in the packet. This is probably what is causing your router to beef about the packet - it is larger than the maximum UDP packet size of 512 bytes.
I believe you aren't able to convert this packet with text2pcap since there is no Ethernet link-type, only embedded IP Protocol shown. I'm not positive about this though, perhaps someone else can chime in here.
-Joshua Wright
Senior Network and Security Architect
Johnson & Wales University
Joshua.Wright@xxxxxxx
http://home.jwu.edu/jwright/
pgpkey: http://home.jwu.edu/jwright/pgpkey.htm
fingerprint: FDA5 12FC F391 3740 E0AE BDB6 8FE2 FC0A D44B 4A73
