Ethereal-dev: Re: [Ethereal-dev] EtherHelp packets almost readable - to fix -> change one byte
On Dec 16, 2003, at 9:53 PM, Andrew Johns wrote:
[Just banging my head against a wall trying to decode capture files
produced by an old version of etherpeek (called EtherHelp).
A Google search for "etherhelp" found a product datasheet for EtherHelp
on the WildPackets Web site:
http://www.wildpackets.com/elements/EtherHelp.pdf
but it says:
EtherHelp, a subset of EtherPeek(TM), our fullfeatured network and
protocol analysis software,
is a blind-packet capture application specifically
designed to help EtherPeek users who support and troubleshoot networks
to obtain information from
a remote network without having to be on location.
rather than saying it's an old version of EtherPeek. Another page for
EtherHelp:
http://www.wildpackets.com/products/etherhelp
says
For Macintosh
EtherHelp is a powerful and freely distributed remote packet capture
application specifically designed to help people who design, build,
manage and support multi-protocol, multi-topology networks analyze what
is happening on a LAN or WAN without having to visit that location.
EtherHelp works by capturing all network traffic, or a specified
portion of that traffic, in the form of packets. Packets captured are
not displayed in EtherHelp, but can be saved in a file, which can then
be accessed by or forwarded to support personnel for analysis by
EtherPeek, which can display the saved packets.
A quick diff shows that only the first byte of the file changes - and
in a
well-formed manner, in that the first character of the etherhelp file
is
char(135) (135=128+7) vs the first char of the etherpeek file which is
char(7)....
At least according to the Ethereal code to read *Peek captures, the
first byte of the file is a version number; it sounds as if the first
byte of your capture was 0x80|7, and removing the 0x80 leaves 7, which
is a newer version number for *Peek capture files - there's code to
read older versions, so I'm a bit skeptical that EtherHelp was an older
version of EtherPeek (and WildPackets' documentation suggests that it
isn't).
Perhaps the 0x80 bit means "captured by EtherHelp", in which case the
Ethereal code should perhaps strip the 8th bit from the first byte
before checking it, and tread the result of that as the file version
number.
Do you have an EtherHelp capture on which I can test that?
