I've been mucking around a little with the Cisco packet dump format -
as you can imagine, I get asked quite a bit to provide text2pcap
support for that format, being in a unique position of having written
text2pcap and working at Cisco :-)
One of the problems is with the somewhat inconsistent way in which
packets received and packets sent are dumped. There seems to be no
real clean way to determine the set of headers on a packet. I was
thinking of some sort of heuristics; input or advice would be
appreciated.
-Ashok
> On Fri, Jun 21, 2002 at 12:24:50AM +0200, M.C. van den Bovenkamp wrote:
> > The other lines pertaining to that packet are the same as the normal
> > 'debug ip packet detailed' reports, and will contain a timestamp
> > (accurate to milliseconds and with timezone) if the Cisco in question is
> > configured to do so with the 'service timestamps debug datetime msec
> > localtime show-timezone' config command. Leaving out the 'show-timezone'
> > & 'msec' bits does what you'd expect: no timezone and no milliseconds
> > respectively. So a timestamp could be cobbled together from that.
>
> It'd be nice if the script did that, transforming the time stamp, if
> necessary, into a form text2pcap can handle, and ran text2pcap with the
> appropriate "-t" option; from the text2pcap man page:
>
> -t timefmt
> Treats the text before the packet as a date/time code;
> timefmt is a format string of the sort supported by
> strptime(3). Example: The time "10:15:14.5476" has the
> format code "%H:%M:%S."
>
> NOTE: The subsecond component delimiter must be
> specified (.) but no pattern is required; the remaining
> number is assumed to be fractions of a second.
>
> > What the hexdump is if input and/or output interfaces *aren't* Ethernet,
> > I don't know, except that isn't an Ethernet frame to be sure, and it's
> > not just the IP packet either; I have tried that with fake MAC addresses
> > (text2pcap -e).
>
> Perhaps it's a frame for the type of interface you're dumping, e.g.
> FDDI, Token Ring, or some type of WAN interface?
>
> text2pcap defaults to making the capture file an Ethernet file, but the
> "-l" flag can override that:
>
> -l Specify the link-layer type of this packet. Default is
> Ethernet (1). See net/bpf.h for the complete list of
> possible encapsulations. Note that this option should be
> used if your dump is a complete hex dump of an
> encapsulated packet and you wish to specify the exact
> type of encapsulation. Example: -l 7 for ARCNet packets.
>
> If the output of "debug ip packet dump" contains some information to
> identify the link-layer type, perhaps the script should use that; if
> not, perhaps the script should take a command-line argument to tell it
> the value to pass on to text2pcap in a "-l" flag.
>
> _______________________________________________
> Ethereal-dev mailing list
> Ethereal-dev@xxxxxxxxxxxx
> http://www.ethereal.com/mailman/listinfo/ethereal-dev
--- Asok the Intern ----------------------------------------
Ashok Narayanan
IOS Network Protocols, Cisco Systems
250 Apollo Drive, Chelmsford, MA 01824
Ph: 978-497-8387. Fax: 978-497-8513 (Attn: Ashok Narayanan)