Hi,
Throughout the libpcap code the assumption is made that bridged ip/atm is
routed and no provision is made to handled the bridged flavor of atm.

I have made changes to my version but I am interested in how you would
propose the direction going for the ATM interface.

In particular, one might claim that the a driver which would allow
promiscuous mode would allow all data on all VCs to be dup'ed up to the
promiscuous listener.   In order to do this correctly then then
tcpdump/print-atm would have to handle at minimum signalling and ilmi
traffic decode as well as CLIP and Bridged ip/atm data.  Filtering out the
ilmi and signalling traffic would be desirable.

Short term, however, the handling of both bridged and routed rfc1483
(which is obsoleted by rfc2684 btw) is clearly desirable.  Based on the
code in libpcap/gencode.c a new flag would be required to fix the
constants for off_linktype and off_nl used by the filtering code which
suggests the definition of a new DLT flag, such as:
        case DLT_ATM_RFC2684:
                /*
                 * assume bridged pdus
                 * (i.e., LLC = 0xAA-AA-03, OUI = 0x00-80-c2)
                 */
                off_linktype = 22;
                off_nl = 24;
                return;
        case DLT_ATM_RFC1483:
                /*
                 * assume routed, non-ISO PDUs
                 * (i.e., LLC = 0xAA-AA-03, OUT = 0x00-00-00)
                 */
                off_linktype = 6;
                off_nl = 8;
                return;

Although clearly it would be better to handle both flexibly as is possible
under tcpdump/print-atm.c by examining the 
LLC and the OUI
if ! LLC == 0xaa-aa-03
  dump this strange packet
if OUI == 0x00-00-00
  then routed
else if OUI == 0x00-80-c2
  then bridged

The identification of signalling and ilmi traffic, without a priori
knowledge of the VC's for the traffic, would be difficult but perhaps
possible?
ilmi enterprise/ display string/object type  (rfc1155-smi,rfc1213-mib/rfc1212) 
and signalling using AFI == 
 39 dcc atm format
 47 icd atm format
 45 e.164 atm format 
see ftp://ftp.atmforum.com/pub/approved-specs/af-unit-0010.002.pdf.tar.Z

Do you have any thoughts on the direction for this area of tcpdump?
danc
Dan L. Clark       [EMAIL PROTECTED]    503/531-6432
nCUBE, 1825 NW 167th Place, Beaverton, OR  97006


-
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

Reply via email to