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

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

From: Guy Harris <guy@xxxxxxxxxx>
Date: Wed, 6 Feb 2002 13:53:21 -0800 (PST)
> Can we use Ethereal for POS interfaces as well?

(That's Packet Over SONET, not Point Of Sale, or Piece Of ****, right?)

You could, *if* libpcap supports it.  Ethereal supports capturing on a
network interface *only* if libpcap/WinPcap supports capturing on it;
the same applies to the many other programs that use libpcap.

Whether libpcap supports it is likely to depend on

	1) the operating system running on the machine into which the
	   POS interface is plugged - if its networking mechanism, and
	   its packet capture mechanism (or, in the case of Windows, its
	   networking mechanism and the WinPcap packet capture
	   mechanism) doesn't support it, libpcap/WinPcap can't support
	   it;

	2) the driver for the POS interface - if the driver doesn't work
	   with the packet capture mechanism, libpcap/WinPcap won't
	   support it, *and* if the driver doesn't properly handle the
	   stuff libpcap/WinPcap asks it to do (e.g., binding to a SAP
	   of 0 and turning on "SAP promiscuous" mode on systems using
	   DLPI), libpcap/WinPcap might need to be changed to support
	   it.

The next issue would be the type of link-layer header that received and
transmitted packets have when handed to the packet capture mechanism.

If they have, for example, PPP headers (or Cisco HDLC headers), then no
new link-layer type ("DLT_" value) would need to be added to
libpcap/WinPcap, and Ethereal wouldn't need to be changed at all.

If, however, they have additional headers before the PPP/Cisco HDLC
header, or if they use a link-layer header type that libpcap/WinPcap
doesn't already support, a new DLT_ value would have to be added to
libpcap *and* support for that type would have to be added to Ethereal.

I have no idea whether

	1) any operating systems allow POS interfaces to work with the
	   packet capture mechanism (they *probably* do, but I can't
	   guarantee that);

	2) any drivers work without problems (somebody asked about that
	   here, and the problem was that the driver they had *didn't*
	   properly handle the stuff libpcap asked it to do);

and also have no idea what link-layer type would be appropriate.