New guy - the return
Explanation:
There are two types of encapsulation:
1) LLC/SNAP encaps: this header help to know which
is the protocol that is present in the data
LLC/SNAP llok like
AA AA 03 <- LLC tells that a SNAP is following
00 00 00 08 00 <- SNAP tells (OUI) that following PID is
| OUI | PID | an Ethertype. PID=0x0800 indicates
the payload contains IP packets
With this method, only one connexion is necessary for
all the protocol above.
2) 'null' encaps: no header is added. So you have to pre-define
the different connexion associated with each protocol you
want to support.
Developpers of ATM on Linux have chosen the first approach (I've
checked with the prog atmdump that show you the cells) but
the interface only offers you the IP packet (header has been left in
the driver):
don't know why exactly but I supposed that's because it is obvious
since you are listening on a Classical IP interface.
Why would you keep the header since there no 'interesting info' ?
With an ethernet frame, it is different seeing that you can find
usefull info in header as addresses.
> 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.
> 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'
If you want, I can send a piece of dump on CLIP.
> 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
Hope this help
Bye
--
ANDRY Thierry -- University Of Liege (BELGIUM)
Electrical Engineer Student in Computer Science
http://www.stud.montefiore.ulg.ac.be/~andry/
mailto:Thierry.Andry@xxxxxxxxxxx
