> The problem is, that at attach time you
> don't know what link-level encapsulation is used, because this can be
> select when you establish the VCC (via the parameter 'z' (see en(4))).
> So BPF_DLC_RFC1483 will not work without LLC/SNAP encapsulation.
The current CVS versions of libpcap and tcpdump, and the current
released version of Ethereal, support a DLT_SUNATM DLT_ type. SunATM's
DLPI interface supplies packets with a 4-byte pseudo-header, consisting of:
a 1-byte flag byte;
a 1-byte VPI value;
a 2-byte (big-endian) VCI value;
where the flag byte contains a one-bit "direction" flag (indicating
whether the packet was sent or received) and a 4-bit packet type. After
that comes the raw reassembled PDU.
The packet type can be one of
"raw" - meaning "other"?
LANE
LLC-multiplexed
MARS
IFMP
ILMI
Q.2931
A similar thing could perhaps be done here; that'd allow the driver to
supply signalling traffic to BPF, for example. That way, the
encapsulation type - DLT_BPFATM, or something such as that - wouldn't
depend on the circuit type; it'd be supplied to the application as part
of the packet pseudo-header.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
