This wiki has been migrated to https://gitlab.com/wireshark/wireshark/-/wikis/home and is now deprecated. Please use that site instead.
Differences between revisions 1 and 6 (spanning 5 versions)
Revision 1 as of 2005-04-09 19:24:22
Size: 1807
Editor: dsl-084-056-118-127
Comment: first content
Revision 6 as of 2006-06-05 03:19:26
Size: 3072
Editor: localhost
Comment:
Deletions are marked like this. Additions are marked like this.
Line 4: Line 4:
This is the pseudo protocol linux uses to capture from the "any" device. 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.)
Line 6: Line 6:
When capturing from the "any" device in linux, the system won't save the real "hardware protocol" like ["Ethernet"], but this pseudo protocol instead. 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.
Line 8: Line 8:
XXX - BTW: Why is the abbreviation SLL? (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.)
Line 16: Line 16:
 * this is a pseudo protocol, so no lower layer (the next upper layer will be IP for example)  * this is a pseudo protocol, so no there's lower layer (the next upper layer will be IP for example)
Line 20: Line 20:
XXX - Add example traffic here (as plain text or Ethereal screenshot). XXX - Add example traffic here (as plain text or Wireshark screenshot).
Line 22: Line 22:
== Ethereal == == Wireshark ==
Line 24: Line 24:
The LLC dissector is (fully functional, partially functional, not existing, ... whatever the current state is). Also add info of additional Ethereal features where appropriate, like special statistics of this protocol. The SLL dissector is fully functional.
Line 28: Line 28:
(XXX add links to preference settings affecting how LLC is dissected). There are no SLL specific preference settings.
Line 32: Line 32:
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. 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 Wireshark can open gzipped files automatically.
Line 34: Line 34:
 * attachment:SampleCaptures/llc.pcap  * attachment:SampleCaptures/sll.pcap
Line 37: Line 37:
A complete list of LLC display filter fields can be found in the [http://www.ethereal.com/docs/dfref/l/llc.html display filter reference] A complete list of SLL display filter fields can be found in the [http://www.wireshark.org/docs/dfref/s/sll.html display filter reference]
Line 39: Line 39:
 Show only the LLC based traffic: {{{
 llc }}}
 Show only the SLL-based traffic: {{{
 sll }}}
Line 44: Line 44:
You cannot directly filter LLC protocols while capturing. 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.
Line 48: Line 48:
 * add link to PROTO specification and where to find additional info on the web about it, e.g.:
 * [http://www.ietf.org/rfc/rfc123.txt RFC 123] ''The RFC title'' - explanation of the RFC content.

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.)

History

XXX - add a brief description of SLL history

Protocol dependencies

  • this is a pseudo protocol, so no there's lower layer (the next upper layer will be IP for example)

Example traffic

XXX - Add example traffic here (as plain text or Wireshark screenshot).

Wireshark

The SLL dissector is fully functional.

Preference Settings

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 Wireshark can open gzipped files automatically.

  • attachment:SampleCaptures/sll.pcap

Display Filter

A complete list of SLL display filter fields can be found in the [http://www.wireshark.org/docs/dfref/s/sll.html display filter reference]

  • Show only the SLL-based traffic:

     sll 

Capture Filter

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.

Discussion

SLL (last edited 2020-01-04 09:26:46 by GuyHarris)