On Wed, Dec 06, 2000 at 02:27:58PM -0700, jdyal@xxxxxxxxxxxxxx wrote:
> My name is Jim and I work as a Principal Engineer at L-3 Communications in
> Salt Lake City. We're trying to find something that will be able to read
> and analyze the semi-proprietary HDLC encapsulation that comes out of the
> HSSI port of a Cisco router.
Is this the HDLC framing version of the "Cisco Systems point-to-point
protocols" mentioned in RFC 1547:
4.3.1 Cisco Systems point-to-point protocols
The Cisco Systems gateway supports both asynchronous links using SLIP
and synchronous links using either simple HDLC framing, X.25 LAPB or
full X.25. The HDLC framing procedure includes a four byte header.
The first octet (address) is either 0x0F (unicast intent) or 0x8F
(multicast intent). The second octet (control byte) is left zero and
is not checked on reception. The third and fourth octets contain a
standard 16 bit Ethernet protocol type code.
A "keepalive" or "beaconing" protocol is used to ensure the two-way
connectivity of the serial line. Each end of the link periodically
sends two 32 bit sequence numbers to the other side. One sequence
number is the local side's sequence number, the other is the sequence
number received from the other side. Hearing the local sequence
number from the other side indicates that the link is working in both
directions.
The keepalive protocol is extensible. One extension is used to
default IP addresses on serial lines of systems without non-volatile
memory. A request for address is sent to the remote side. The
remote side responds with its own IP address and a subnet mask. When
the querying side receives the reply, it checks if the host portion
of the remote address is either 1 or 2. If so, the opposite address
is chosen for the local address. If not, the protocol cannot be used
and we must rely on other address resolution means. This protocol
assumes that each serial link uses one subnet or network number.
If so, Ethereal doesn't currently analyze it, but it probably wouldn't
be too hard to add support for it.
However, the "read" part is another matter; Ethereal would somehow have
to get access to that data stream, which means either
1) Ethereal would have to be running on a computer with some
form of hardware that can see the data coming out of that
port
or
2) Ethereal would have to have some way of getting the Cisco
router to forward it that data stream over a normal network
or
3) some other piece of equipment would have to arrange to get
that data stream written to a file.
In the case of 1), we'd have to know how to get that hardware to provide
Ethereal with that data stream.
In the case of 2), we'd have to know what network protocols would be
used to get the Cisco to forward that to us, and what network protocols
would be used for the forwarded data stream.
In the case of 3), we'd have to know what the format of that file is, or
have enough files of that type to be able to reverse-engineer its
format.