Wireshark · Ethereal-dev: Re: [ethereal-dev] New guy on list

[Guy Harris <guy@xxxxxxxxxx>]

>  Why would you keep the header since there no 'interesting info' ?

Because you might be getting network traces to debug the code that's
doing the encapsulation?

BTW, it appears from the ATM-on-Linux patch to "tcpdump" that the
SOCK_PACKET interface *can* give the LLC/SNAP header on occasion;
"print-clp.c" appears to look for a SNAP header at the beginning of the
frame.  (I didn't see anything in the patch to make "libpcap" use the
packet filter mechanism rather than SOCK_PACKET, so I'm assuming it's
still using SOCK_PACKET to get the raw packets.)

> > I'm tempted to call it WTAP_ENCAP_LINUX_ATM_CLIP or something, to make it > clear that it's the Classical IP encapsulation that at least some Linux > > systems use, as distinct from WTAP_ENCAP_ATM_RFC1483 which is the one the
> > standard "libpcap" does (probably from some flavor of BSD).
> 
>  Explanations above come from RFC1483 so it is the same.

The DLT_ATM_RFC1483 data link type appears to hand up the LLC/SNAP
header, at least if "print-atm.c" from "tcpdump" 3.4 is to be believed;
the Linux SOCK_PACKET stuff for the ATM-on-Linux stuff doesn't always
hand the header up, so the data you get is in a different format, and
thus needs a different Wiretap type.

I.e., whatever code uses DLT_ATM_RFC1483 link type (probably some flavor
of ATM-on-BSD) is doing RFC 1483, not just "Classical IP" - it could
handle non-IP protocols atop 1483.

> > It appears to be able to read your capture file; does that capture
> > consist of 5 ICMP ECHO packets from 132.168.1.104 to 132.168.1.102?  If
> > so, it's reading your capture file correctly.
>   
>  Yes it is. It isn't a self made capture file but one created with
> ethereal.
> 
> > I'll have to see why the patch assumes there's an LLC header, when it
> > appears there's no LLC header in the actual captures....
> 
>  There is ! (because Classical IP) but tcpdump only output the 'data
> field'

"tcpdump" should output whatever it gets from the kernel's "raw packet
access" mechanism; presumably the SOCK_PACKET code is sending up only
the IP datagrams, not the LLC/SNAP header.

>  If you want, I can send a piece of dump on CLIP.

"Piece of dump" in the sense of a "tcpdump" or Ethereal network capture
("tcpdump" and Ethereal's captures should look the same, as they're both
using "libpcap")?

> > What the patch to "tcpdump" appears to do is to see if there's a SNAP
> > LLC header on the packet and, if so, extract the packet type from it;
> > otherwise, it assumes it's an IP packet with no link-layer header.
> > I've no idea why they have a different form of encapsulation than
> > DLT_ATM_RFC1483, but....
> 
>  Because of the two types of encapsulation defined in RFC1483

Wait.

DLT_ATM_RFC1483 apears to be for use with the "multiplexing of multiple
protocols over a single ATM virtual circuit" encapsulation, with an
LLC/SNAP header; it sounds as if you're saying ATM-on-Linux uses the
same encapsulation, but its interface to SOCK_PACKET strips off the
LLC/SNAP header, unlike the putative BSD ATM mechanism, which doesn't
appear to strip off the LLC/SNAP header before handing the frame to BPF.

So this doesn't appear to be an issue of the two types of encapsulation,
as they both appear to be using what RFC 1483 calle "LLC Encapsulation",
i.e.  "multiplexing of multiple protocols over a single ATM virtual
circuit", rather than what RFC 1483 calls "VC Based Multiplexiing", i.e. 
"each protocol is carried over a separate ATM virtual circuit".

(Then again, even if ATM-on-Linux *does*, or *did*, use VC-based
multiplexing, it should arguably put a fake header of some sort on the
frames handed to SOCK_PACKET and the packet filter, in case protocols
*other* than IP are being sent over the network.)