On Thu, Oct 04, 2001 at 12:06:00AM -0700, kino skin wrote:
> In case one needs to add support for a new
> Link type to pcap, what are the steps that need to be
> taken.
The first step is to figure out how to use that link type on the
platform on which you're adding support.
> On Solaris 8
> Pcap does not currently support
> live capture on an "ATM Classical IP interface"
>
> I looked into pcap-dlpi.c in the function
> pcap_open_loop().
> There is a switch for "infop->dl_mac_type"
> which handles DL_CSMACD, DL_ETHER and DL_FDDI.
The DL_ type for "ATM Classical IP interface" with SunATM appears to be
DL_IPATM, based on some "atmsnoop" capture files I've seen.
So you have to add a case for DL_IPATM.
That case would have to set "p->linktype" and "p->offset".
The link-layer header for DL_IPATM appears, from the "atmsnoop" capture
files, to consist of:
one byte of flags, which includes a "direction" flag (DTE->DCE
vs. DCE->DTE), that being the uppermost (0x80) bit;
one byte of VPI;
two bytes of VCI, in big-endian format.
Following that comes what is presumably an AAL5 frame.
You now have to choose a DLT_ type for this, to assign to "p->linktype".
I'd pick DLT_SUNATM, as other "raw ATM" layers might put a different
type of "pseudo-header" in front of the packet. For example:
The "pseudo-header" used inside at least some parts of some BSD
systems has the same 4 bytes, but the flags don't appear to be
the same; furthermore, there doesn't seem to be any way to get
that "pseudo-header" on BPF-captured frames - you just get the
AAL5 frame, which presumably is a "Classical IP" frame.
The "atmdump/README.ATM" file that comes as part of
ftp://ftp.cs.ndsu.nodak.edu/pub/freebsd/atm/atm-bpf.tgz
says that BPF-captured frames have a header containing
one byte of flags, including a "direction" flag, that
being the uppermost (0x80) bit;
one byte of VPI
two bytes of VCI
one byte of GFC, PT, and CLP, which are presumably the
GFC, Payload Type, and CLP fields from the ATM cells
that make up that AAL5 frame
and the NICStAR driver in
ftp://ftp.cs.ndsu.nodak.edu/pub/freebsd/atm/nicstar.tgz
appears to put that on BPF-captured frames (although it uses
DLT_EN10MB as the DLT_ type, which is bogus).
"p->offset" should be set, ideally, so as to put the IP header on a
4-byte boundary; with a 4-byte ATM pseudo-header, and an 8-byte LLC SNAP
header, if the AAL5 frame is on a 4-byte boundary, the IP header will
also be on a 4-byte boundary, so "p->offset" should be set to 0 for
DL_IPATM.
You now have to add support in the packet filter code generator, with
code to handle DLT_SUNATM.
If it's truly Classical IP, the AAL5 frame would begin with an LLC
header.
However, in the "atmsnoop" capture I've seen, there are also ILMI and
Q.2931 frames, which do *not* begin with an LLC header; the ILMI frames
have a VPI of 0 and a VCI of 16 (which I think may be the usual VPI/VCI
combination for ILMI), and the Q.2931 frames are "signalling AAL" frames
with a VPI of 0 and a VCI of 5.
You therefore would need to have the code in "gen_linktype()" in
"gencode.c" check for the second byte of the link-layer header not being
0 or the third and fourth bytes, treated as a big-endian integer, being
neither 5 nor 16, at least for starters. (If you're running LANE, this
may not help, but if you're running LANE, there's probably an emulated
Ethernet or perhaps Token Ring device on which you can capture, although
you won't see any signalling traffic or LAN Emulation Control traffic.)
So, in "gencode.c", you'd change "init_linktype()" to set "off_linktype"
to 10 (which is the offset of the "protocol ID" field in the LLC+SNAP
header following the ATM pseudo-header) and set "off_ln" to 12 (which is
the offset of the first byte after the LLC+SNAP header), and change
"gen_linktype" to generate code to check the VPI and VCI, generate code
of the same type that's generated for DLT_IEEE802_11, DLT_FDDI,
DLT_IEEE802, and so on, and then do an "and" of those two. (A quick and
dirty shortcut would be to ignore the VPI and VCI checks, and just treat
DLT_SUNATM the same way that DLT_IEEE802_11, DLT_FDDI, DLT_IEEE802, and
so on are treated.)
Now you'd have to add code to "savefile.c" to handle DLT_SUNATM capture
files. You'd add a LINKTYPE_SUNATM value of 118, after LINKTYPE_ECONET,
and add to the "map[]" array an entry
{ DLT_SUNATM, LINKTYPE_SUNATM },
Then add to "bpf/net/bpf.h" a #define of DLT_SUNATM as 118.
*NOTE*: if you're going to do this, please let us know, so we can
reserve DLT_SUNATM as 118 for this purpose; we don't want to have
somebody else grab that value.
Once that's done, you'll have to add support to tcpdump for DLT_SUNATM.
> If one needs to add the handling of another mac type,
> then what are the code changes that one needs to do.
All of the above.
-
This is the TCPDUMP workers list. It is archived at
http://www.tcpdump.org/lists/workers/index.html
To unsubscribe use mailto:[EMAIL PROTECTED]?body=unsubscribe
