> Folks, I am attempting to build libpcap and tcpdump to support
> an OC-3 ATM interface on a Sun Ultra2 running Solaris 8. The
> /dev/ba driver is being used. I have built both packages from
> the libpcap-0.6.2 & tcpdump-3.6.2 source distributions with
> no configuration changes. The ATM interface is install on the
> Ultra2 that I am using to build the code. The system also has
> an hme interface which works fine with libpcap & tcpdump.
> When I attempt to use the /dev/ba interface, I get unrecognized
> mac type 18 error.
Ethereal can read atmsnoop capture files; they are just snoop capture
files with a non-documented-in-RFC-1761 link-layer types of 18, which is
in
http://www.opengroup.org/onlinepubs/9638599/apdxf.htm
as
#define DL_IPATM 0x12 /* ATM Classical IP interface */
The fact that it speaks of a "Classical IP interface", and that there's
also
#define DL_ATM 0x11 /* ATM */
in there nonwithstanding, the link-layer header is a sort of a raw-ish
ATM header ("raw-ish" because there isn't a standard for "raw ATM
headers" as there is for, say, Ethernet/802.3 headers), rather than,
say, a DLT_ATM_RFC1483-type LLC header.
At
http://mrpink.lerc.nasa.gov/118x/support.html
are, among other thinks, links to
Modified tcpdump and libpcap for SUNatm DLPI support. At least,
a SUNATM-622 SBUS with SUNATM3.x drivers under Solaris2.7. That
is what we are running. V2.x drivers may not work since it
appears DLPI support may not be in there. [Someone tried
tcpdump-sunatm with V2.x drivers and it failed. I don't have
the drivers to test this...] I will try to add atmsnoop file
read support for V2.x drivers after 118x project. Should
relativity[sic] straightforward.....
and the Big Fat Comment I stuck at the beginning of the Ethereal module
for reading snoop capture files says:
* It also has a link to "convert.c", which is a program to convert files
* from the format written by the "atmsnoop" program that comes with the
* SunATM package to regular "snoop" format, claims that "SunATM 2.1 claimed
* to be DL_FDDI (don't ask why). SunATM 3.0 claims to be DL_IPATM, which
* is 0x12".
*
* It also says that "ATM Mac header is 12 bytes long.", and seems to imply
* that in an "atmsnoop" file, the header contains 2 bytes (direction and
* VPI?), 2 bytes of VCI, 6 bytes of something, and 2 bytes of Ethernet
* type; if those 6 bytes are 2 bytes of DSAP, 2 bytes of LSAP, 1 byte
* of LLC control, and 3 bytes of SNAP OUI, that'd mean that an ATM
* pseudo-header in an "atmsnoop" file is probably 1 byte of direction,
* 1 byte of VPI, and 2 bytes of VCI.
*
* The aforementioned page also has a link to some capture files from
* "atmsnoop"; this version of "snoop.c" appears to be able to read them.
*
* Source to an "atmdump" package, which includes a modified version of
* "libpcap" to handle SunATM DLPI and an ATM driver for FreeBSD, and
* also includes "atmdump", which is a modified "tcpdump", says that an
* ATM packet handed up from the Sun driver for the Sun SBus ATM card on
* Solaris 2.5.1 has 1 byte of direction, 1 byte of VPI, 2 bytes of VCI,
* and then the ATM PDU, and suggests that the direction byte is 0x80 for
* "transmitted" (presumably meaning DTE->DCE) and presumably not 0x80 for
* "received" (presumably meaning DCE->DTE).
*
* In fact, the "direction" byte appears to have some other stuff, perhaps
* a traffic type, in the lower 7 bits, with the 8th bit indicating the
* direction.
*
* I don't know what the encapsulation of any of the other types is, so I
* leave them all as WTAP_ENCAP_UNKNOWN. I also don't know whether "snoop"
* can handle any of them (it presumably can't handle ATM, otherwise Sun
* wouldn't have supplied "atmsnoop"; even if it can't, this may be useful
* reference information for anybody doing code to use DLPI to do raw packet
* captures on those network types.
("it", in "It also has a link", refers to the page at
mrpink.lerc.nasa.gov).
Some of the information needed may be in header files distributed with
SunATM; I think I saw those headers on some machine around here,
although, as I remember, Sun stamped them out the wazoo with "THIS IS
PROPRIETARY TO SUN" copyright notices.
> I've installed Sun's ATM drivers with support
> for their ATM API. Their atmsnoop program seems to work.
> However, I would like to use libpcap & tcpdump because
> of the generic support for other platforms such as Linux and
> because of the higher level applications that require libpcap/tcpdump.
> These would include ethereal and ntop.
>
> Can you give me some suggestions as to an appropriate approach
> to this problem?
I'd be inclined to grab the patched tcpdump/libpcap sources in question
and see whether the changes could be made to a more modern flavor of
libpcap/tcpdump. Unfortunately, those changes might also be compilable
only if you have SunATM installed; if so, there'd have to be some
configure-script checks for the relevant header files and #ifdefs.
-
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
