Ethereal-users: Re: [Ethereal-users] Ethereal for HSSI

Note: This archive is from the project's previous web site, ethereal.com. This list is no longer active.

From: Guy Harris <gharris@xxxxxxxxx>
Date: Wed, 4 Sep 2002 11:44:09 -0700
On Wed, Sep 04, 2002 at 11:06:35PM +0800, darren wrote:
> I would like to use Ethereal to analyze a HSSI link.
> 
> I have got a PC with a HSSI card installed. But every time I capture
> traffic, I get a "Linux Cooked Socket" as my Layer-2 protocol.
> 
> Anyone know how I can solve this?

That depends on whether you're using PPP, Cisco HDLC, or some other
encapsulation on the serial line.

If it's PPP, you solve it by convincing the developers of Linux's
various PPP implementations to fix them so that they don't suck, in
various ways, when you use them with raw sockets, *and* to allow libpcap
to query whether the PPP implementation for the device on which it's
sniffing sucks with raw sockets or not.

The problem is that:

	some PPP implementations completely strip off the link-layer
	header, so that it's *completely unavailable* to libpcap, and
	thus the actual packet type is unavailable - if you capture in
	cooked mode, however, the packet type is available, even though
	the raw link-layer header isn't;

	some PPP implementations appear (at least from some captures
	people have sent us) to supply, at least for some packets
	(outgoing packets, I suspect), some mysterious junk at the
	beginning of the packet as part of the link-layer header - if
	you capture in cooked mode, however, the raw link-layer header
	is removed, so libpcap and libpcap-based programs can actually
	handle the packets sanely.

Therefore, libpcap, on Linux, captures in cooked mode on PPP.

Note that the only difference between cooked mode, and raw mode with a
PPP implementation that doesn't suck, is whether you get the real
link-layer header or a fake link-layer header.  In both cases, you get
the packet type, which is the only field in an RFC 1661 PPP header, and
the only field in an RFC 1662+RFC 1661 PPP header that doesn't have a
fixed value.  In *neither* case do you get packets for various PPP
control protocols, as the PPP implementations don't supply them.

If it's Cisco HDLC, it might work if libpcap were to map ARPHRD_CISCO to
DLT_CHDLC.

If it's some other encapsulation, I don't know how to solve it as I
don't know the encapsulation or what ARPHRD_ type Linux uses for it.

> Also, can the latest version of libpcap (0.7.1) handle this?

0.7.1 doesn't handle Linux PPP any better than earlier versions, as the
problem is with the Linux kernel's PPP implementations.

It also doesn't handle Cisco HDLC any better.