Give more details on why cooked mode is used.
|Deletions are marked like this.||Additions are marked like this.|
|Line 28:||Line 28:|
|(XXX add links to preference settings affecting how SLL is dissected).||There are no SLL specific preference settings.|
Linux cooked-mode capture (SLL)
This is the pseudo-protocol used by libpcap on Linux to capture from the "any" device and to capture on some devices where the native link layer header isn't available or can't be used. (For example, the Linux PPP code doesn't reliably supply a PPP header to libpcap - it's usually either absent, meaning that the packet type isn't available, or contains extra random gunk in some but not all packets, as happens on some PPP-over-ISDN interfaces - so the SLL pseudo-link-layer is used on PPP interfaces. It's used on the "any" device because not all interfaces on a machine necessarily have the same link-layer type, but, in order for capture filters to work, all packets on an interface must have the same type of link-layer header.)
When capturing from the "any" device, or from one of those other devices, in Linux, the libpcap doesn't supply the link-layer header for the real "hardware protocol" like ["Ethernet"], but instead supplies a fake link-layer header for this pseudo-protocol.
(For those who are curious, "SLL" stands for "sockaddr_ll"; capturing in "cooked mode" is done by reading from a PF_PACKET/SOCK_DGRAM socket rather than the PF_PACKET/SOCK_RAW socket normally used for capturing. Using SOCK_DGRAM rather than SOCK_RAW means that the Linux socket code doesn't supply the packet's link-layer header. This means that information such as the link-layer protocol's packet type field, if any, isn't available, so libpcap constructs a synthetic link-layer header from the address supplied when it does a recvfrom() on the socket. On PF_PACKET sockets, that address is of type sockaddr_ll, where "ll" presumably stands for "link layer"; the fields in that structure begin with sll_. See the packet(7) man page on a Linux system for more details.)
XXX - add a brief description of SLL history
- this is a pseudo protocol, so no there's lower layer (the next upper layer will be IP for example)
XXX - Add example traffic here (as plain text or Ethereal screenshot).
The SLL dissector is fully functional.
There are no SLL specific preference settings.
Example capture file
XXX - Add a simple example capture file to the SampleCaptures page and link from here (see below). Keep this file short, it's also a good idea to gzip it to make it even smaller, as Ethereal can open gzipped files automatically.
A complete list of SLL display filter fields can be found in the [http://www.ethereal.com/docs/dfref/s/sll.html display filter reference]
Show only the SLL-based traffic:
You cannot directly filter SLL protocols while capturing; if you're capturing on the "any" device or on any network interface where libpcap uses cooked mode, all traffic is SLL traffic.