€•²Þ      Œsphinx.addnodes”Œdocument”“”)”}”(Œ	rawsource”Œ ”Œchildren”]”(Œtranslations”ŒLanguagesNode”“”)”}”(hhh]”(h Œpending_xref”“”)”}”(hhh]”Œdocutils.nodes”ŒText”“”ŒChinese (Simplified)”…””}”Œparent”hsbaŒ
attributes”}”(Œids”]”Œclasses”]”Œnames”]”Œdupnames”]”Œbackrefs”]”Œ	refdomain”Œstd”Œreftype”Œdoc”Œ	reftarget”Œ&/translations/zh_CN/networking/udplite”Œmodname”NŒ	classname”NŒrefexplicit”ˆuŒtagname”hhhubh)”}”(hhh]”hŒChinese (Traditional)”…””}”hh2sbah}”(h]”h ]”h"]”h$]”h&]”Œ	refdomain”h)Œreftype”h+Œ	reftarget”Œ&/translations/zh_TW/networking/udplite”Œmodname”NŒ	classname”NŒrefexplicit”ˆuh1hhhubh)”}”(hhh]”hŒItalian”…””}”hhFsbah}”(h]”h ]”h"]”h$]”h&]”Œ	refdomain”h)Œreftype”h+Œ	reftarget”Œ&/translations/it_IT/networking/udplite”Œmodname”NŒ	classname”NŒrefexplicit”ˆuh1hhhubh)”}”(hhh]”hŒJapanese”…””}”hhZsbah}”(h]”h ]”h"]”h$]”h&]”Œ	refdomain”h)Œreftype”h+Œ	reftarget”Œ&/translations/ja_JP/networking/udplite”Œmodname”NŒ	classname”NŒrefexplicit”ˆuh1hhhubh)”}”(hhh]”hŒKorean”…””}”hhnsbah}”(h]”h ]”h"]”h$]”h&]”Œ	refdomain”h)Œreftype”h+Œ	reftarget”Œ&/translations/ko_KR/networking/udplite”Œmodname”NŒ	classname”NŒrefexplicit”ˆuh1hhhubh)”}”(hhh]”hŒPortuguese (Brazilian)”…””}”hh‚sbah}”(h]”h ]”h"]”h$]”h&]”Œ	refdomain”h)Œreftype”h+Œ	reftarget”Œ&/translations/pt_BR/networking/udplite”Œmodname”NŒ	classname”NŒrefexplicit”ˆuh1hhhubh)”}”(hhh]”hŒSpanish”…””}”hh–sbah}”(h]”h ]”h"]”h$]”h&]”Œ	refdomain”h)Œreftype”h+Œ	reftarget”Œ&/translations/sp_SP/networking/udplite”Œmodname”NŒ	classname”NŒrefexplicit”ˆuh1hhhubeh}”(h]”h ]”h"]”h$]”h&]”Œcurrent_language”ŒEnglish”uh1h
hhŒ	_document”hŒsource”NŒline”NubhŒcomment”“”)”}”(hŒ SPDX-License-Identifier: GPL-2.0”h]”hŒ SPDX-License-Identifier: GPL-2.0”…””}”hh·sbah}”(h]”h ]”h"]”h$]”h&]”Œ	xml:space”Œpreserve”uh1hµhhh²hh³Œ@/var/lib/git/docbuild/linux/Documentation/networking/udplite.rst”h´KubhŒsection”“”)”}”(hhh]”(hŒtitle”“”)”}”(hŒ The UDP-Lite protocol (RFC 3828)”h]”hŒ The UDP-Lite protocol (RFC 3828)”…””}”(hhÏh²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hÍhhÊh²hh³hÇh´KubhŒblock_quote”“”)”}”(hX¦  UDP-Lite is a Standards-Track IETF transport protocol whose characteristic
is a variable-length checksum. This has advantages for transport of multimedia
(video, VoIP) over wireless networks, as partly damaged packets can still be
fed into the codec instead of being discarded due to a failed checksum test.

This file briefly describes the existing kernel support and the socket API.
For in-depth information, you can consult:

 - The UDP-Lite Homepage:
   http://web.archive.org/web/%2E/http://www.erg.abdn.ac.uk/users/gerrit/udp-lite/

   From here you can also download some example application source code.

 - The UDP-Lite HOWTO on
   http://web.archive.org/web/%2E/http://www.erg.abdn.ac.uk/users/gerrit/udp-lite/files/UDP-Lite-HOWTO.txt

 - The Wireshark UDP-Lite WiKi (with capture files):
   https://wiki.wireshark.org/Lightweight_User_Datagram_Protocol

 - The Protocol Spec, RFC 3828, http://www.ietf.org/rfc/rfc3828.txt

”h]”(hŒ	paragraph”“”)”}”(hX3  UDP-Lite is a Standards-Track IETF transport protocol whose characteristic
is a variable-length checksum. This has advantages for transport of multimedia
(video, VoIP) over wireless networks, as partly damaged packets can still be
fed into the codec instead of being discarded due to a failed checksum test.”h]”hX3  UDP-Lite is a Standards-Track IETF transport protocol whose characteristic
is a variable-length checksum. This has advantages for transport of multimedia
(video, VoIP) over wireless networks, as partly damaged packets can still be
fed into the codec instead of being discarded due to a failed checksum test.”…””}”(hhåh²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hãh³hÇh´Khhßubhä)”}”(hŒvThis file briefly describes the existing kernel support and the socket API.
For in-depth information, you can consult:”h]”hŒvThis file briefly describes the existing kernel support and the socket API.
For in-depth information, you can consult:”…””}”(hhóh²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hãh³hÇh´KhhßubhÞ)”}”(hXñ  - The UDP-Lite Homepage:
  http://web.archive.org/web/%2E/http://www.erg.abdn.ac.uk/users/gerrit/udp-lite/

  From here you can also download some example application source code.

- The UDP-Lite HOWTO on
  http://web.archive.org/web/%2E/http://www.erg.abdn.ac.uk/users/gerrit/udp-lite/files/UDP-Lite-HOWTO.txt

- The Wireshark UDP-Lite WiKi (with capture files):
  https://wiki.wireshark.org/Lightweight_User_Datagram_Protocol

- The Protocol Spec, RFC 3828, http://www.ietf.org/rfc/rfc3828.txt

”h]”hŒbullet_list”“”)”}”(hhh]”(hŒ	list_item”“”)”}”(hŒ®The UDP-Lite Homepage:
http://web.archive.org/web/%2E/http://www.erg.abdn.ac.uk/users/gerrit/udp-lite/

From here you can also download some example application source code.
”h]”(hä)”}”(hŒfThe UDP-Lite Homepage:
http://web.archive.org/web/%2E/http://www.erg.abdn.ac.uk/users/gerrit/udp-lite/”h]”(hŒThe UDP-Lite Homepage:
”…””}”(hj  h²hh³Nh´NubhŒ	reference”“”)”}”(hŒOhttp://web.archive.org/web/%2E/http://www.erg.abdn.ac.uk/users/gerrit/udp-lite/”h]”hŒOhttp://web.archive.org/web/%2E/http://www.erg.abdn.ac.uk/users/gerrit/udp-lite/”…””}”(hj  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”Œrefuri”j  uh1j  hj  ubeh}”(h]”h ]”h"]”h$]”h&]”uh1hãh³hÇh´Khj  ubhä)”}”(hŒEFrom here you can also download some example application source code.”h]”hŒEFrom here you can also download some example application source code.”…””}”(hj/  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hãh³hÇh´Khj  ubeh}”(h]”h ]”h"]”h$]”h&]”uh1j
  hj  ubj  )”}”(hŒ~The UDP-Lite HOWTO on
http://web.archive.org/web/%2E/http://www.erg.abdn.ac.uk/users/gerrit/udp-lite/files/UDP-Lite-HOWTO.txt
”h]”hä)”}”(hŒ}The UDP-Lite HOWTO on
http://web.archive.org/web/%2E/http://www.erg.abdn.ac.uk/users/gerrit/udp-lite/files/UDP-Lite-HOWTO.txt”h]”(hŒThe UDP-Lite HOWTO on
”…””}”(hjG  h²hh³Nh´Nubj  )”}”(hŒghttp://web.archive.org/web/%2E/http://www.erg.abdn.ac.uk/users/gerrit/udp-lite/files/UDP-Lite-HOWTO.txt”h]”hŒghttp://web.archive.org/web/%2E/http://www.erg.abdn.ac.uk/users/gerrit/udp-lite/files/UDP-Lite-HOWTO.txt”…””}”(hjO  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”Œrefuri”jQ  uh1j  hjG  ubeh}”(h]”h ]”h"]”h$]”h&]”uh1hãh³hÇh´KhjC  ubah}”(h]”h ]”h"]”h$]”h&]”uh1j
  hj  ubj  )”}”(hŒpThe Wireshark UDP-Lite WiKi (with capture files):
https://wiki.wireshark.org/Lightweight_User_Datagram_Protocol
”h]”hä)”}”(hŒoThe Wireshark UDP-Lite WiKi (with capture files):
https://wiki.wireshark.org/Lightweight_User_Datagram_Protocol”h]”(hŒ2The Wireshark UDP-Lite WiKi (with capture files):
”…””}”(hjn  h²hh³Nh´Nubj  )”}”(hŒ=https://wiki.wireshark.org/Lightweight_User_Datagram_Protocol”h]”hŒ=https://wiki.wireshark.org/Lightweight_User_Datagram_Protocol”…””}”(hjv  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”Œrefuri”jx  uh1j  hjn  ubeh}”(h]”h ]”h"]”h$]”h&]”uh1hãh³hÇh´Khjj  ubah}”(h]”h ]”h"]”h$]”h&]”uh1j
  hj  ubj  )”}”(hŒBThe Protocol Spec, RFC 3828, http://www.ietf.org/rfc/rfc3828.txt

”h]”hä)”}”(hŒ@The Protocol Spec, RFC 3828, http://www.ietf.org/rfc/rfc3828.txt”h]”(hŒThe Protocol Spec, RFC 3828, ”…””}”(hj•  h²hh³Nh´Nubj  )”}”(hŒ#http://www.ietf.org/rfc/rfc3828.txt”h]”hŒ#http://www.ietf.org/rfc/rfc3828.txt”…””}”(hj  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”Œrefuri”jŸ  uh1j  hj•  ubeh}”(h]”h ]”h"]”h$]”h&]”uh1hãh³hÇh´Khj‘  ubah}”(h]”h ]”h"]”h$]”h&]”uh1j
  hj  ubeh}”(h]”h ]”h"]”h$]”h&]”Œbullet”Œ-”uh1j  h³hÇh´Khj  ubah}”(h]”h ]”h"]”h$]”h&]”uh1hÝh³hÇh´Khhßubeh}”(h]”h ]”h"]”h$]”h&]”uh1hÝh³hÇh´KhhÊh²hubhÉ)”}”(hhh]”(hÎ)”}”(hŒ1. Applications”h]”hŒ1. Applications”…””}”(hjÏ  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hÍhjÌ  h²hh³hÇh´KubhÞ)”}”(hXd  Several applications have been ported successfully to UDP-Lite. Ethereal
(now called wireshark) has UDP-Litev4/v6 support by default.

Porting applications to UDP-Lite is straightforward: only socket level and
IPPROTO need to be changed; senders additionally set the checksum coverage
length (default = header length = 8). Details are in the next section.
”h]”(hä)”}”(hŒ…Several applications have been ported successfully to UDP-Lite. Ethereal
(now called wireshark) has UDP-Litev4/v6 support by default.”h]”hŒ…Several applications have been ported successfully to UDP-Lite. Ethereal
(now called wireshark) has UDP-Litev4/v6 support by default.”…””}”(hjá  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hãh³hÇh´K!hjÝ  ubhä)”}”(hŒÜPorting applications to UDP-Lite is straightforward: only socket level and
IPPROTO need to be changed; senders additionally set the checksum coverage
length (default = header length = 8). Details are in the next section.”h]”hŒÜPorting applications to UDP-Lite is straightforward: only socket level and
IPPROTO need to be changed; senders additionally set the checksum coverage
length (default = header length = 8). Details are in the next section.”…””}”(hjï  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hãh³hÇh´K$hjÝ  ubeh}”(h]”h ]”h"]”h$]”h&]”uh1hÝh³hÇh´K!hjÌ  h²hubeh}”(h]”Œapplications”ah ]”h"]”Œ1. applications”ah$]”h&]”uh1hÈhhÊh²hh³hÇh´KubhÉ)”}”(hhh]”(hÎ)”}”(hŒ2. Programming API”h]”hŒ2. Programming API”…””}”(hj  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hÍhj  h²hh³hÇh´K)ubhÞ)”}”(hX  UDP-Lite provides a connectionless, unreliable datagram service and hence
uses the same socket type as UDP. In fact, porting from UDP to UDP-Lite is
very easy: simply add ``IPPROTO_UDPLITE`` as the last argument of the
socket(2) call so that the statement looks like::

    s = socket(PF_INET, SOCK_DGRAM, IPPROTO_UDPLITE);

or, respectively,

::

    s = socket(PF_INET6, SOCK_DGRAM, IPPROTO_UDPLITE);

With just the above change you are able to run UDP-Lite services or connect
to UDP-Lite servers. The kernel will assume that you are not interested in
using partial checksum coverage and so emulate UDP mode (full coverage).

To make use of the partial checksum coverage facilities requires setting a
single socket option, which takes an integer specifying the coverage length:

  * Sender checksum coverage: UDPLITE_SEND_CSCOV

    For example::

      int val = 20;
      setsockopt(s, SOL_UDPLITE, UDPLITE_SEND_CSCOV, &val, sizeof(int));

    sets the checksum coverage length to 20 bytes (12b data + 8b header).
    Of each packet only the first 20 bytes (plus the pseudo-header) will be
    checksummed. This is useful for RTP applications which have a 12-byte
    base header.


  * Receiver checksum coverage: UDPLITE_RECV_CSCOV

    This option is the receiver-side analogue. It is truly optional, i.e. not
    required to enable traffic with partial checksum coverage. Its function is
    that of a traffic filter: when enabled, it instructs the kernel to drop
    all packets which have a coverage _less_ than this value. For example, if
    RTP and UDP headers are to be protected, a receiver can enforce that only
    packets with a minimum coverage of 20 are admitted::

      int min = 20;
      setsockopt(s, SOL_UDPLITE, UDPLITE_RECV_CSCOV, &min, sizeof(int));

The calls to getsockopt(2) are analogous. Being an extension and not a stand-
alone protocol, all socket options known from UDP can be used in exactly the
same manner as before, e.g. UDP_CORK or UDP_ENCAP.

A detailed discussion of UDP-Lite checksum coverage options is in section IV.
”h]”(hä)”}”(hX  UDP-Lite provides a connectionless, unreliable datagram service and hence
uses the same socket type as UDP. In fact, porting from UDP to UDP-Lite is
very easy: simply add ``IPPROTO_UDPLITE`` as the last argument of the
socket(2) call so that the statement looks like::”h]”(hŒ«UDP-Lite provides a connectionless, unreliable datagram service and hence
uses the same socket type as UDP. In fact, porting from UDP to UDP-Lite is
very easy: simply add ”…””}”(hj   h²hh³Nh´NubhŒliteral”“”)”}”(hŒ``IPPROTO_UDPLITE``”h]”hŒIPPROTO_UDPLITE”…””}”(hj*  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1j(  hj   ubhŒM as the last argument of the
socket(2) call so that the statement looks like:”…””}”(hj   h²hh³Nh´Nubeh}”(h]”h ]”h"]”h$]”h&]”uh1hãh³hÇh´K+hj  ubhŒliteral_block”“”)”}”(hŒ1s = socket(PF_INET, SOCK_DGRAM, IPPROTO_UDPLITE);”h]”hŒ1s = socket(PF_INET, SOCK_DGRAM, IPPROTO_UDPLITE);”…””}”hjD  sbah}”(h]”h ]”h"]”h$]”h&]”hÅhÆuh1jB  h³hÇh´K0hj  ubhä)”}”(hŒor, respectively,”h]”hŒor, respectively,”…””}”(hjR  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hãh³hÇh´K2hj  ubjC  )”}”(hŒ2s = socket(PF_INET6, SOCK_DGRAM, IPPROTO_UDPLITE);”h]”hŒ2s = socket(PF_INET6, SOCK_DGRAM, IPPROTO_UDPLITE);”…””}”hj`  sbah}”(h]”h ]”h"]”h$]”h&]”hÅhÆuh1jB  h³hÇh´K6hj  ubhä)”}”(hŒßWith just the above change you are able to run UDP-Lite services or connect
to UDP-Lite servers. The kernel will assume that you are not interested in
using partial checksum coverage and so emulate UDP mode (full coverage).”h]”hŒßWith just the above change you are able to run UDP-Lite services or connect
to UDP-Lite servers. The kernel will assume that you are not interested in
using partial checksum coverage and so emulate UDP mode (full coverage).”…””}”(hjn  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hãh³hÇh´K8hj  ubhä)”}”(hŒ—To make use of the partial checksum coverage facilities requires setting a
single socket option, which takes an integer specifying the coverage length:”h]”hŒ—To make use of the partial checksum coverage facilities requires setting a
single socket option, which takes an integer specifying the coverage length:”…””}”(hj|  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hãh³hÇh´K<hj  ubhÞ)”}”(hXÄ  * Sender checksum coverage: UDPLITE_SEND_CSCOV

  For example::

    int val = 20;
    setsockopt(s, SOL_UDPLITE, UDPLITE_SEND_CSCOV, &val, sizeof(int));

  sets the checksum coverage length to 20 bytes (12b data + 8b header).
  Of each packet only the first 20 bytes (plus the pseudo-header) will be
  checksummed. This is useful for RTP applications which have a 12-byte
  base header.


* Receiver checksum coverage: UDPLITE_RECV_CSCOV

  This option is the receiver-side analogue. It is truly optional, i.e. not
  required to enable traffic with partial checksum coverage. Its function is
  that of a traffic filter: when enabled, it instructs the kernel to drop
  all packets which have a coverage _less_ than this value. For example, if
  RTP and UDP headers are to be protected, a receiver can enforce that only
  packets with a minimum coverage of 20 are admitted::

    int min = 20;
    setsockopt(s, SOL_UDPLITE, UDPLITE_RECV_CSCOV, &min, sizeof(int));
”h]”j  )”}”(hhh]”(j  )”}”(hXu  Sender checksum coverage: UDPLITE_SEND_CSCOV

For example::

  int val = 20;
  setsockopt(s, SOL_UDPLITE, UDPLITE_SEND_CSCOV, &val, sizeof(int));

sets the checksum coverage length to 20 bytes (12b data + 8b header).
Of each packet only the first 20 bytes (plus the pseudo-header) will be
checksummed. This is useful for RTP applications which have a 12-byte
base header.

”h]”(hä)”}”(hŒ,Sender checksum coverage: UDPLITE_SEND_CSCOV”h]”hŒ,Sender checksum coverage: UDPLITE_SEND_CSCOV”…””}”(hj•  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hãh³hÇh´K?hj‘  ubhä)”}”(hŒFor example::”h]”hŒFor example:”…””}”(hj£  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hãh³hÇh´KAhj‘  ubjC  )”}”(hŒPint val = 20;
setsockopt(s, SOL_UDPLITE, UDPLITE_SEND_CSCOV, &val, sizeof(int));”h]”hŒPint val = 20;
setsockopt(s, SOL_UDPLITE, UDPLITE_SEND_CSCOV, &val, sizeof(int));”…””}”hj±  sbah}”(h]”h ]”h"]”h$]”h&]”hÅhÆuh1jB  h³hÇh´KChj‘  ubhä)”}”(hŒàsets the checksum coverage length to 20 bytes (12b data + 8b header).
Of each packet only the first 20 bytes (plus the pseudo-header) will be
checksummed. This is useful for RTP applications which have a 12-byte
base header.”h]”hŒàsets the checksum coverage length to 20 bytes (12b data + 8b header).
Of each packet only the first 20 bytes (plus the pseudo-header) will be
checksummed. This is useful for RTP applications which have a 12-byte
base header.”…””}”(hj¿  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hãh³hÇh´KFhj‘  ubeh}”(h]”h ]”h"]”h$]”h&]”uh1j
  hjŽ  ubj  )”}”(hX,  Receiver checksum coverage: UDPLITE_RECV_CSCOV

This option is the receiver-side analogue. It is truly optional, i.e. not
required to enable traffic with partial checksum coverage. Its function is
that of a traffic filter: when enabled, it instructs the kernel to drop
all packets which have a coverage _less_ than this value. For example, if
RTP and UDP headers are to be protected, a receiver can enforce that only
packets with a minimum coverage of 20 are admitted::

  int min = 20;
  setsockopt(s, SOL_UDPLITE, UDPLITE_RECV_CSCOV, &min, sizeof(int));
”h]”(hä)”}”(hŒ.Receiver checksum coverage: UDPLITE_RECV_CSCOV”h]”hŒ.Receiver checksum coverage: UDPLITE_RECV_CSCOV”…””}”(hj×  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hãh³hÇh´KLhjÓ  ubhä)”}”(hX¥  This option is the receiver-side analogue. It is truly optional, i.e. not
required to enable traffic with partial checksum coverage. Its function is
that of a traffic filter: when enabled, it instructs the kernel to drop
all packets which have a coverage _less_ than this value. For example, if
RTP and UDP headers are to be protected, a receiver can enforce that only
packets with a minimum coverage of 20 are admitted::”h]”hX¤  This option is the receiver-side analogue. It is truly optional, i.e. not
required to enable traffic with partial checksum coverage. Its function is
that of a traffic filter: when enabled, it instructs the kernel to drop
all packets which have a coverage _less_ than this value. For example, if
RTP and UDP headers are to be protected, a receiver can enforce that only
packets with a minimum coverage of 20 are admitted:”…””}”(hjå  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hãh³hÇh´KNhjÓ  ubjC  )”}”(hŒPint min = 20;
setsockopt(s, SOL_UDPLITE, UDPLITE_RECV_CSCOV, &min, sizeof(int));”h]”hŒPint min = 20;
setsockopt(s, SOL_UDPLITE, UDPLITE_RECV_CSCOV, &min, sizeof(int));”…””}”hjó  sbah}”(h]”h ]”h"]”h$]”h&]”hÅhÆuh1jB  h³hÇh´KUhjÓ  ubeh}”(h]”h ]”h"]”h$]”h&]”uh1j
  hjŽ  ubeh}”(h]”h ]”h"]”h$]”h&]”j¾  Œ*”uh1j  h³hÇh´K?hjŠ  ubah}”(h]”h ]”h"]”h$]”h&]”uh1hÝh³hÇh´K?hj  ubhä)”}”(hŒÍThe calls to getsockopt(2) are analogous. Being an extension and not a stand-
alone protocol, all socket options known from UDP can be used in exactly the
same manner as before, e.g. UDP_CORK or UDP_ENCAP.”h]”hŒÍThe calls to getsockopt(2) are analogous. Being an extension and not a stand-
alone protocol, all socket options known from UDP can be used in exactly the
same manner as before, e.g. UDP_CORK or UDP_ENCAP.”…””}”(hj  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hãh³hÇh´KXhj  ubhä)”}”(hŒMA detailed discussion of UDP-Lite checksum coverage options is in section IV.”h]”hŒMA detailed discussion of UDP-Lite checksum coverage options is in section IV.”…””}”(hj"  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hãh³hÇh´K\hj  ubeh}”(h]”h ]”h"]”h$]”h&]”uh1hÝh³hÇh´K+hj  h²hubeh}”(h]”Œprogramming-api”ah ]”h"]”Œ2. programming api”ah$]”h&]”uh1hÈhhÊh²hh³hÇh´K)ubhÉ)”}”(hhh]”(hÎ)”}”(hŒ3. Header Files”h]”hŒ3. Header Files”…””}”(hjA  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hÍhj>  h²hh³hÇh´K_ubhÞ)”}”(hX  The socket API requires support through header files in /usr/include:

  * /usr/include/netinet/in.h
    to define IPPROTO_UDPLITE

  * /usr/include/netinet/udplite.h
    for UDP-Lite header fields and protocol constants

For testing purposes, the following can serve as a ``mini`` header file::

  #define IPPROTO_UDPLITE       136
  #define SOL_UDPLITE           136
  #define UDPLITE_SEND_CSCOV     10
  #define UDPLITE_RECV_CSCOV     11

Ready-made header files for various distros are in the UDP-Lite tarball.
”h]”(hä)”}”(hŒEThe socket API requires support through header files in /usr/include:”h]”hŒEThe socket API requires support through header files in /usr/include:”…””}”(hjS  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hãh³hÇh´KahjO  ubhÞ)”}”(hŒŽ* /usr/include/netinet/in.h
  to define IPPROTO_UDPLITE

* /usr/include/netinet/udplite.h
  for UDP-Lite header fields and protocol constants
”h]”j  )”}”(hhh]”(j  )”}”(hŒ4/usr/include/netinet/in.h
to define IPPROTO_UDPLITE
”h]”hä)”}”(hŒ3/usr/include/netinet/in.h
to define IPPROTO_UDPLITE”h]”hŒ3/usr/include/netinet/in.h
to define IPPROTO_UDPLITE”…””}”(hjl  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hãh³hÇh´Kchjh  ubah}”(h]”h ]”h"]”h$]”h&]”uh1j
  hje  ubj  )”}”(hŒQ/usr/include/netinet/udplite.h
for UDP-Lite header fields and protocol constants
”h]”hä)”}”(hŒP/usr/include/netinet/udplite.h
for UDP-Lite header fields and protocol constants”h]”hŒP/usr/include/netinet/udplite.h
for UDP-Lite header fields and protocol constants”…””}”(hj„  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hãh³hÇh´Kfhj€  ubah}”(h]”h ]”h"]”h$]”h&]”uh1j
  hje  ubeh}”(h]”h ]”h"]”h$]”h&]”j¾  j  uh1j  h³hÇh´Kchja  ubah}”(h]”h ]”h"]”h$]”h&]”uh1hÝh³hÇh´KchjO  ubhä)”}”(hŒIFor testing purposes, the following can serve as a ``mini`` header file::”h]”(hŒ3For testing purposes, the following can serve as a ”…””}”(hj¤  h²hh³Nh´Nubj)  )”}”(hŒ``mini``”h]”hŒmini”…””}”(hj¬  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1j(  hj¤  ubhŒ header file:”…””}”(hj¤  h²hh³Nh´Nubeh}”(h]”h ]”h"]”h$]”h&]”uh1hãh³hÇh´KihjO  ubjC  )”}”(hŒ‡#define IPPROTO_UDPLITE       136
#define SOL_UDPLITE           136
#define UDPLITE_SEND_CSCOV     10
#define UDPLITE_RECV_CSCOV     11”h]”hŒ‡#define IPPROTO_UDPLITE       136
#define SOL_UDPLITE           136
#define UDPLITE_SEND_CSCOV     10
#define UDPLITE_RECV_CSCOV     11”…””}”hjÄ  sbah}”(h]”h ]”h"]”h$]”h&]”hÅhÆuh1jB  h³hÇh´KkhjO  ubhä)”}”(hŒHReady-made header files for various distros are in the UDP-Lite tarball.”h]”hŒHReady-made header files for various distros are in the UDP-Lite tarball.”…””}”(hjÒ  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hãh³hÇh´KphjO  ubeh}”(h]”h ]”h"]”h$]”h&]”uh1hÝh³hÇh´Kahj>  h²hubeh}”(h]”Œheader-files”ah ]”h"]”Œ3. header files”ah$]”h&]”uh1hÈhhÊh²hh³hÇh´K_ubhÉ)”}”(hhh]”(hÎ)”}”(hŒ>4. Kernel Behaviour with Regards to the Various Socket Options”h]”hŒ>4. Kernel Behaviour with Regards to the Various Socket Options”…””}”(hjñ  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hÍhjî  h²hh³hÇh´KsubhÞ)”}”(hX¯  To enable debugging messages, the log level need to be set to 8, as most
messages use the KERN_DEBUG level (7).

1) Sender Socket Options

If the sender specifies a value of 0 as coverage length, the module
assumes full coverage, transmits a packet with coverage length of 0
and according checksum.  If the sender specifies a coverage < 8 and
different from 0, the kernel assumes 8 as default value.  Finally,
if the specified coverage length exceeds the packet length, the packet
length is used instead as coverage length.

2) Receiver Socket Options

The receiver specifies the minimum value of the coverage length it
is willing to accept.  A value of 0 here indicates that the receiver
always wants the whole of the packet covered. In this case, all
partially covered packets are dropped and an error is logged.

It is not possible to specify illegal values (<0 and <8); in these
cases the default of 8 is assumed.

All packets arriving with a coverage value less than the specified
threshold are discarded, these events are also logged.

3) Disabling the Checksum Computation

On both sender and receiver, checksumming will always be performed
and cannot be disabled using SO_NO_CHECK. Thus::

      setsockopt(sockfd, SOL_SOCKET, SO_NO_CHECK,  ... );

will always will be ignored, while the value of::

      getsockopt(sockfd, SOL_SOCKET, SO_NO_CHECK, &value, ...);

is meaningless (as in TCP). Packets with a zero checksum field are
illegal (cf. RFC 3828, sec. 3.1) and will be silently discarded.

4) Fragmentation

The checksum computation respects both buffersize and MTU. The size
of UDP-Lite packets is determined by the size of the send buffer. The
minimum size of the send buffer is 2048 (defined as SOCK_MIN_SNDBUF
in include/net/sock.h), the default value is configurable as
net.core.wmem_default or via setting the SO_SNDBUF socket(7)
option. The maximum upper bound for the send buffer is determined
by net.core.wmem_max.

Given a payload size larger than the send buffer size, UDP-Lite will
split the payload into several individual packets, filling up the
send buffer size in each case.

The precise value also depends on the interface MTU. The interface MTU,
in turn, may trigger IP fragmentation. In this case, the generated
UDP-Lite packet is split into several IP packets, of which only the
first one contains the L4 header.

The send buffer size has implications on the checksum coverage length.
Consider the following example::

  Payload: 1536 bytes          Send Buffer:     1024 bytes
  MTU:     1500 bytes          Coverage Length:  856 bytes

UDP-Lite will ship the 1536 bytes in two separate packets::

  Packet 1: 1024 payload + 8 byte header + 20 byte IP header = 1052 bytes
  Packet 2:  512 payload + 8 byte header + 20 byte IP header =  540 bytes

The coverage packet covers the UDP-Lite header and 848 bytes of the
payload in the first packet, the second packet is fully covered. Note
that for the second packet, the coverage length exceeds the packet
length. The kernel always re-adjusts the coverage length to the packet
length in such cases.

As an example of what happens when one UDP-Lite packet is split into
several tiny fragments, consider the following example::

  Payload: 1024 bytes            Send buffer size: 1024 bytes
  MTU:      300 bytes            Coverage length:   575 bytes

  +-+-----------+--------------+--------------+--------------+
  |8|    272    |      280     |     280      |     280      |
  +-+-----------+--------------+--------------+--------------+
              280            560            840           1032
                                      ^
  *****checksum coverage*************

The UDP-Lite module generates one 1032 byte packet (1024 + 8 byte
header). According to the interface MTU, these are split into 4 IP
packets (280 byte IP payload + 20 byte IP header). The kernel module
sums the contents of the entire first two packets, plus 15 bytes of
the last packet before releasing the fragments to the IP module.

To see the analogous case for IPv6 fragmentation, consider a link
MTU of 1280 bytes and a write buffer of 3356 bytes. If the checksum
coverage is less than 1232 bytes (MTU minus IPv6/fragment header
lengths), only the first fragment needs to be considered. When using
larger checksum coverage lengths, each eligible fragment needs to be
checksummed. Suppose we have a checksum coverage of 3062. The buffer
of 3356 bytes will be split into the following fragments::

  Fragment 1: 1280 bytes carrying  1232 bytes of UDP-Lite data
  Fragment 2: 1280 bytes carrying  1232 bytes of UDP-Lite data
  Fragment 3:  948 bytes carrying   900 bytes of UDP-Lite data

The first two fragments have to be checksummed in full, of the last
fragment only 598 (= 3062 - 2*1232) bytes are checksummed.

While it is important that such cases are dealt with correctly, they
are (annoyingly) rare: UDP-Lite is designed for optimising multimedia
performance over wireless (or generally noisy) links and thus smaller
coverage lengths are likely to be expected.
”h]”(hä)”}”(hŒoTo enable debugging messages, the log level need to be set to 8, as most
messages use the KERN_DEBUG level (7).”h]”hŒoTo enable debugging messages, the log level need to be set to 8, as most
messages use the KERN_DEBUG level (7).”…””}”(hj  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hãh³hÇh´Kvhjÿ  ubhŒenumerated_list”“”)”}”(hhh]”j  )”}”(hŒSender Socket Options
”h]”hä)”}”(hŒSender Socket Options”h]”hŒSender Socket Options”…””}”(hj  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hãh³hÇh´Kyhj  ubah}”(h]”h ]”h"]”h$]”h&]”uh1j
  hj  ubah}”(h]”h ]”h"]”h$]”h&]”Œenumtype”Œarabic”Œprefix”hŒsuffix”Œ)”uh1j  hjÿ  ubhä)”}”(hX€  If the sender specifies a value of 0 as coverage length, the module
assumes full coverage, transmits a packet with coverage length of 0
and according checksum.  If the sender specifies a coverage < 8 and
different from 0, the kernel assumes 8 as default value.  Finally,
if the specified coverage length exceeds the packet length, the packet
length is used instead as coverage length.”h]”hX€  If the sender specifies a value of 0 as coverage length, the module
assumes full coverage, transmits a packet with coverage length of 0
and according checksum.  If the sender specifies a coverage < 8 and
different from 0, the kernel assumes 8 as default value.  Finally,
if the specified coverage length exceeds the packet length, the packet
length is used instead as coverage length.”…””}”(hj9  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hãh³hÇh´K{hjÿ  ubj  )”}”(hhh]”j  )”}”(hŒReceiver Socket Options
”h]”hä)”}”(hŒReceiver Socket Options”h]”hŒReceiver Socket Options”…””}”(hjN  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hãh³hÇh´K‚hjJ  ubah}”(h]”h ]”h"]”h$]”h&]”uh1j
  hjG  ubah}”(h]”h ]”h"]”h$]”h&]”j4  j5  j6  hj7  j8  Œstart”Kuh1j  hjÿ  ubhä)”}”(hX  The receiver specifies the minimum value of the coverage length it
is willing to accept.  A value of 0 here indicates that the receiver
always wants the whole of the packet covered. In this case, all
partially covered packets are dropped and an error is logged.”h]”hX  The receiver specifies the minimum value of the coverage length it
is willing to accept.  A value of 0 here indicates that the receiver
always wants the whole of the packet covered. In this case, all
partially covered packets are dropped and an error is logged.”…””}”(hji  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hãh³hÇh´K„hjÿ  ubhä)”}”(hŒeIt is not possible to specify illegal values (<0 and <8); in these
cases the default of 8 is assumed.”h]”hŒeIt is not possible to specify illegal values (<0 and <8); in these
cases the default of 8 is assumed.”…””}”(hjw  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hãh³hÇh´K‰hjÿ  ubhä)”}”(hŒyAll packets arriving with a coverage value less than the specified
threshold are discarded, these events are also logged.”h]”hŒyAll packets arriving with a coverage value less than the specified
threshold are discarded, these events are also logged.”…””}”(hj…  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hãh³hÇh´KŒhjÿ  ubj  )”}”(hhh]”j  )”}”(hŒ#Disabling the Checksum Computation
”h]”hä)”}”(hŒ"Disabling the Checksum Computation”h]”hŒ"Disabling the Checksum Computation”…””}”(hjš  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hãh³hÇh´Khj–  ubah}”(h]”h ]”h"]”h$]”h&]”uh1j
  hj“  ubah}”(h]”h ]”h"]”h$]”h&]”j4  j5  j6  hj7  j8  jh  Kuh1j  hjÿ  ubhä)”}”(hŒsOn both sender and receiver, checksumming will always be performed
and cannot be disabled using SO_NO_CHECK. Thus::”h]”hŒrOn both sender and receiver, checksumming will always be performed
and cannot be disabled using SO_NO_CHECK. Thus:”…””}”(hj´  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hãh³hÇh´K‘hjÿ  ubjC  )”}”(hŒ3setsockopt(sockfd, SOL_SOCKET, SO_NO_CHECK,  ... );”h]”hŒ3setsockopt(sockfd, SOL_SOCKET, SO_NO_CHECK,  ... );”…””}”hjÂ  sbah}”(h]”h ]”h"]”h$]”h&]”hÅhÆuh1jB  h³hÇh´K”hjÿ  ubhä)”}”(hŒ1will always will be ignored, while the value of::”h]”hŒ0will always will be ignored, while the value of:”…””}”(hjÐ  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hãh³hÇh´K–hjÿ  ubjC  )”}”(hŒ9getsockopt(sockfd, SOL_SOCKET, SO_NO_CHECK, &value, ...);”h]”hŒ9getsockopt(sockfd, SOL_SOCKET, SO_NO_CHECK, &value, ...);”…””}”hjÞ  sbah}”(h]”h ]”h"]”h$]”h&]”hÅhÆuh1jB  h³hÇh´K˜hjÿ  ubhä)”}”(hŒƒis meaningless (as in TCP). Packets with a zero checksum field are
illegal (cf. RFC 3828, sec. 3.1) and will be silently discarded.”h]”hŒƒis meaningless (as in TCP). Packets with a zero checksum field are
illegal (cf. RFC 3828, sec. 3.1) and will be silently discarded.”…””}”(hjì  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hãh³hÇh´Kšhjÿ  ubj  )”}”(hhh]”j  )”}”(hŒFragmentation
”h]”hä)”}”(hŒFragmentation”h]”hŒFragmentation”…””}”(hj  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hãh³hÇh´Khjý  ubah}”(h]”h ]”h"]”h$]”h&]”uh1j
  hjú  ubah}”(h]”h ]”h"]”h$]”h&]”j4  j5  j6  hj7  j8  jh  Kuh1j  hjÿ  ubhä)”}”(hXŸ  The checksum computation respects both buffersize and MTU. The size
of UDP-Lite packets is determined by the size of the send buffer. The
minimum size of the send buffer is 2048 (defined as SOCK_MIN_SNDBUF
in include/net/sock.h), the default value is configurable as
net.core.wmem_default or via setting the SO_SNDBUF socket(7)
option. The maximum upper bound for the send buffer is determined
by net.core.wmem_max.”h]”hXŸ  The checksum computation respects both buffersize and MTU. The size
of UDP-Lite packets is determined by the size of the send buffer. The
minimum size of the send buffer is 2048 (defined as SOCK_MIN_SNDBUF
in include/net/sock.h), the default value is configurable as
net.core.wmem_default or via setting the SO_SNDBUF socket(7)
option. The maximum upper bound for the send buffer is determined
by net.core.wmem_max.”…””}”(hj  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hãh³hÇh´KŸhjÿ  ubhä)”}”(hŒ¥Given a payload size larger than the send buffer size, UDP-Lite will
split the payload into several individual packets, filling up the
send buffer size in each case.”h]”hŒ¥Given a payload size larger than the send buffer size, UDP-Lite will
split the payload into several individual packets, filling up the
send buffer size in each case.”…””}”(hj)  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hãh³hÇh´K§hjÿ  ubhä)”}”(hŒðThe precise value also depends on the interface MTU. The interface MTU,
in turn, may trigger IP fragmentation. In this case, the generated
UDP-Lite packet is split into several IP packets, of which only the
first one contains the L4 header.”h]”hŒðThe precise value also depends on the interface MTU. The interface MTU,
in turn, may trigger IP fragmentation. In this case, the generated
UDP-Lite packet is split into several IP packets, of which only the
first one contains the L4 header.”…””}”(hj7  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hãh³hÇh´K«hjÿ  ubhä)”}”(hŒgThe send buffer size has implications on the checksum coverage length.
Consider the following example::”h]”hŒfThe send buffer size has implications on the checksum coverage length.
Consider the following example:”…””}”(hjE  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hãh³hÇh´K°hjÿ  ubjC  )”}”(hŒqPayload: 1536 bytes          Send Buffer:     1024 bytes
MTU:     1500 bytes          Coverage Length:  856 bytes”h]”hŒqPayload: 1536 bytes          Send Buffer:     1024 bytes
MTU:     1500 bytes          Coverage Length:  856 bytes”…””}”hjS  sbah}”(h]”h ]”h"]”h$]”h&]”hÅhÆuh1jB  h³hÇh´K³hjÿ  ubhä)”}”(hŒ;UDP-Lite will ship the 1536 bytes in two separate packets::”h]”hŒ:UDP-Lite will ship the 1536 bytes in two separate packets:”…””}”(hja  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hãh³hÇh´K¶hjÿ  ubjC  )”}”(hŒPacket 1: 1024 payload + 8 byte header + 20 byte IP header = 1052 bytes
Packet 2:  512 payload + 8 byte header + 20 byte IP header =  540 bytes”h]”hŒPacket 1: 1024 payload + 8 byte header + 20 byte IP header = 1052 bytes
Packet 2:  512 payload + 8 byte header + 20 byte IP header =  540 bytes”…””}”hjo  sbah}”(h]”h ]”h"]”h$]”h&]”hÅhÆuh1jB  h³hÇh´K¸hjÿ  ubhä)”}”(hX)  The coverage packet covers the UDP-Lite header and 848 bytes of the
payload in the first packet, the second packet is fully covered. Note
that for the second packet, the coverage length exceeds the packet
length. The kernel always re-adjusts the coverage length to the packet
length in such cases.”h]”hX)  The coverage packet covers the UDP-Lite header and 848 bytes of the
payload in the first packet, the second packet is fully covered. Note
that for the second packet, the coverage length exceeds the packet
length. The kernel always re-adjusts the coverage length to the packet
length in such cases.”…””}”(hj}  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hãh³hÇh´K»hjÿ  ubhä)”}”(hŒ}As an example of what happens when one UDP-Lite packet is split into
several tiny fragments, consider the following example::”h]”hŒ|As an example of what happens when one UDP-Lite packet is split into
several tiny fragments, consider the following example:”…””}”(hj‹  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hãh³hÇh´KÁhjÿ  ubjC  )”}”(hX¶  Payload: 1024 bytes            Send buffer size: 1024 bytes
MTU:      300 bytes            Coverage length:   575 bytes

+-+-----------+--------------+--------------+--------------+
|8|    272    |      280     |     280      |     280      |
+-+-----------+--------------+--------------+--------------+
            280            560            840           1032
                                    ^
*****checksum coverage*************”h]”hX¶  Payload: 1024 bytes            Send buffer size: 1024 bytes
MTU:      300 bytes            Coverage length:   575 bytes

+-+-----------+--------------+--------------+--------------+
|8|    272    |      280     |     280      |     280      |
+-+-----------+--------------+--------------+--------------+
            280            560            840           1032
                                    ^
*****checksum coverage*************”…””}”hj™  sbah}”(h]”h ]”h"]”h$]”h&]”hÅhÆuh1jB  h³hÇh´KÄhjÿ  ubhä)”}”(hXN  The UDP-Lite module generates one 1032 byte packet (1024 + 8 byte
header). According to the interface MTU, these are split into 4 IP
packets (280 byte IP payload + 20 byte IP header). The kernel module
sums the contents of the entire first two packets, plus 15 bytes of
the last packet before releasing the fragments to the IP module.”h]”hXN  The UDP-Lite module generates one 1032 byte packet (1024 + 8 byte
header). According to the interface MTU, these are split into 4 IP
packets (280 byte IP payload + 20 byte IP header). The kernel module
sums the contents of the entire first two packets, plus 15 bytes of
the last packet before releasing the fragments to the IP module.”…””}”(hj§  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hãh³hÇh´KÎhjÿ  ubhä)”}”(hXÐ  To see the analogous case for IPv6 fragmentation, consider a link
MTU of 1280 bytes and a write buffer of 3356 bytes. If the checksum
coverage is less than 1232 bytes (MTU minus IPv6/fragment header
lengths), only the first fragment needs to be considered. When using
larger checksum coverage lengths, each eligible fragment needs to be
checksummed. Suppose we have a checksum coverage of 3062. The buffer
of 3356 bytes will be split into the following fragments::”h]”hXÏ  To see the analogous case for IPv6 fragmentation, consider a link
MTU of 1280 bytes and a write buffer of 3356 bytes. If the checksum
coverage is less than 1232 bytes (MTU minus IPv6/fragment header
lengths), only the first fragment needs to be considered. When using
larger checksum coverage lengths, each eligible fragment needs to be
checksummed. Suppose we have a checksum coverage of 3062. The buffer
of 3356 bytes will be split into the following fragments:”…””}”(hjµ  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hãh³hÇh´KÔhjÿ  ubjC  )”}”(hŒ¶Fragment 1: 1280 bytes carrying  1232 bytes of UDP-Lite data
Fragment 2: 1280 bytes carrying  1232 bytes of UDP-Lite data
Fragment 3:  948 bytes carrying   900 bytes of UDP-Lite data”h]”hŒ¶Fragment 1: 1280 bytes carrying  1232 bytes of UDP-Lite data
Fragment 2: 1280 bytes carrying  1232 bytes of UDP-Lite data
Fragment 3:  948 bytes carrying   900 bytes of UDP-Lite data”…””}”hjÃ  sbah}”(h]”h ]”h"]”h$]”h&]”hÅhÆuh1jB  h³hÇh´KÜhjÿ  ubhä)”}”(hŒ~The first two fragments have to be checksummed in full, of the last
fragment only 598 (= 3062 - 2*1232) bytes are checksummed.”h]”hŒ~The first two fragments have to be checksummed in full, of the last
fragment only 598 (= 3062 - 2*1232) bytes are checksummed.”…””}”(hjÑ  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hãh³hÇh´Kàhjÿ  ubhä)”}”(hŒüWhile it is important that such cases are dealt with correctly, they
are (annoyingly) rare: UDP-Lite is designed for optimising multimedia
performance over wireless (or generally noisy) links and thus smaller
coverage lengths are likely to be expected.”h]”hŒüWhile it is important that such cases are dealt with correctly, they
are (annoyingly) rare: UDP-Lite is designed for optimising multimedia
performance over wireless (or generally noisy) links and thus smaller
coverage lengths are likely to be expected.”…””}”(hjß  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hãh³hÇh´Kãhjÿ  ubeh}”(h]”h ]”h"]”h$]”h&]”uh1hÝh³hÇh´Kvhjî  h²hubeh}”(h]”Œ;kernel-behaviour-with-regards-to-the-various-socket-options”ah ]”h"]”Œ>4. kernel behaviour with regards to the various socket options”ah$]”h&]”uh1hÈhhÊh²hh³hÇh´KsubhÉ)”}”(hhh]”(hÎ)”}”(hŒ05. UDP-Lite Runtime Statistics and their Meaning”h]”hŒ05. UDP-Lite Runtime Statistics and their Meaning”…””}”(hjþ  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hÍhjû  h²hh³hÇh´KéubhÞ)”}”(hX   Exceptional and error conditions are logged to syslog at the KERN_DEBUG
level.  Live statistics about UDP-Lite are available in /proc/net/snmp
and can (with newer versions of netstat) be viewed using::

                          netstat -svu

This displays UDP-Lite statistics variables, whose meaning is as follows.

 ============     =====================================================
 InDatagrams      The total number of datagrams delivered to users.

 NoPorts          Number of packets received to an unknown port.
                  These cases are counted separately (not as InErrors).

 InErrors         Number of erroneous UDP-Lite packets. Errors include:

                    * internal socket queue receive errors
                    * packet too short (less than 8 bytes or stated
                      coverage length exceeds received length)
                    * xfrm4_policy_check() returned with error
                    * application has specified larger min. coverage
                      length than that of incoming packet
                    * checksum coverage violated
                    * bad checksum

 OutDatagrams     Total number of sent datagrams.
 ============     =====================================================

 These statistics derive from the UDP MIB (RFC 2013).
”h]”(hä)”}”(hŒÉExceptional and error conditions are logged to syslog at the KERN_DEBUG
level.  Live statistics about UDP-Lite are available in /proc/net/snmp
and can (with newer versions of netstat) be viewed using::”h]”hŒÈExceptional and error conditions are logged to syslog at the KERN_DEBUG
level.  Live statistics about UDP-Lite are available in /proc/net/snmp
and can (with newer versions of netstat) be viewed using:”…””}”(hj  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hãh³hÇh´Këhj  ubjC  )”}”(hŒnetstat -svu”h]”hŒnetstat -svu”…””}”hj  sbah}”(h]”h ]”h"]”h$]”h&]”hÅhÆuh1jB  h³hÇh´Kïhj  ubhä)”}”(hŒIThis displays UDP-Lite statistics variables, whose meaning is as follows.”h]”hŒIThis displays UDP-Lite statistics variables, whose meaning is as follows.”…””}”(hj,  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hãh³hÇh´Kñhj  ubhÞ)”}”(hXÒ  ============     =====================================================
InDatagrams      The total number of datagrams delivered to users.

NoPorts          Number of packets received to an unknown port.
                 These cases are counted separately (not as InErrors).

InErrors         Number of erroneous UDP-Lite packets. Errors include:

                   * internal socket queue receive errors
                   * packet too short (less than 8 bytes or stated
                     coverage length exceeds received length)
                   * xfrm4_policy_check() returned with error
                   * application has specified larger min. coverage
                     length than that of incoming packet
                   * checksum coverage violated
                   * bad checksum

OutDatagrams     Total number of sent datagrams.
============     =====================================================

These statistics derive from the UDP MIB (RFC 2013).
”h]”(hŒtable”“”)”}”(hhh]”hŒtgroup”“”)”}”(hhh]”(hŒcolspec”“”)”}”(hhh]”h}”(h]”h ]”h"]”h$]”h&]”Œcolwidth”Kuh1jH  hjE  ubjI  )”}”(hhh]”h}”(h]”h ]”h"]”h$]”h&]”Œcolwidth”K5uh1jH  hjE  ubhŒtbody”“”)”}”(hhh]”(hŒrow”“”)”}”(hhh]”(hŒentry”“”)”}”(hhh]”hä)”}”(hŒInDatagrams”h]”hŒInDatagrams”…””}”(hjm  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hãh³hÇh´Kôhjj  ubah}”(h]”h ]”h"]”h$]”h&]”uh1jh  hje  ubji  )”}”(hhh]”hä)”}”(hŒ1The total number of datagrams delivered to users.”h]”hŒ1The total number of datagrams delivered to users.”…””}”(hj„  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hãh³hÇh´Kôhj  ubah}”(h]”h ]”h"]”h$]”h&]”uh1jh  hje  ubeh}”(h]”h ]”h"]”h$]”h&]”uh1jc  hj`  ubjd  )”}”(hhh]”(ji  )”}”(hhh]”hä)”}”(hŒNoPorts”h]”hŒNoPorts”…””}”(hj¤  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hãh³hÇh´Köhj¡  ubah}”(h]”h ]”h"]”h$]”h&]”uh1jh  hjž  ubji  )”}”(hhh]”hä)”}”(hŒdNumber of packets received to an unknown port.
These cases are counted separately (not as InErrors).”h]”hŒdNumber of packets received to an unknown port.
These cases are counted separately (not as InErrors).”…””}”(hj»  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hãh³hÇh´Köhj¸  ubah}”(h]”h ]”h"]”h$]”h&]”uh1jh  hjž  ubeh}”(h]”h ]”h"]”h$]”h&]”uh1jc  hj`  ubjd  )”}”(hhh]”(ji  )”}”(hhh]”hä)”}”(hŒInErrors”h]”hŒInErrors”…””}”(hjÛ  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hãh³hÇh´KùhjØ  ubah}”(h]”h ]”h"]”h$]”h&]”uh1jh  hjÕ  ubji  )”}”(hhh]”(hä)”}”(hŒ5Number of erroneous UDP-Lite packets. Errors include:”h]”hŒ5Number of erroneous UDP-Lite packets. Errors include:”…””}”(hjò  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hãh³hÇh´Kùhjï  ubhÞ)”}”(hX0  * internal socket queue receive errors
* packet too short (less than 8 bytes or stated
  coverage length exceeds received length)
* xfrm4_policy_check() returned with error
* application has specified larger min. coverage
  length than that of incoming packet
* checksum coverage violated
* bad checksum
”h]”j  )”}”(hhh]”(j  )”}”(hŒ$internal socket queue receive errors”h]”hä)”}”(hj	  h]”hŒ$internal socket queue receive errors”…””}”(hj  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hãh³hÇh´Kûhj  ubah}”(h]”h ]”h"]”h$]”h&]”uh1j
  hj  ubj  )”}”(hŒVpacket too short (less than 8 bytes or stated
coverage length exceeds received length)”h]”hä)”}”(hŒVpacket too short (less than 8 bytes or stated
coverage length exceeds received length)”h]”hŒVpacket too short (less than 8 bytes or stated
coverage length exceeds received length)”…””}”(hj"  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hãh³hÇh´Kühj  ubah}”(h]”h ]”h"]”h$]”h&]”uh1j
  hj  ubj  )”}”(hŒ(xfrm4_policy_check() returned with error”h]”hä)”}”(hj8  h]”hŒ(xfrm4_policy_check() returned with error”…””}”(hj:  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hãh³hÇh´Kþhj6  ubah}”(h]”h ]”h"]”h$]”h&]”uh1j
  hj  ubj  )”}”(hŒRapplication has specified larger min. coverage
length than that of incoming packet”h]”hä)”}”(hŒRapplication has specified larger min. coverage
length than that of incoming packet”h]”hŒRapplication has specified larger min. coverage
length than that of incoming packet”…””}”(hjQ  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hãh³hÇh´KÿhjM  ubah}”(h]”h ]”h"]”h$]”h&]”uh1j
  hj  ubj  )”}”(hŒchecksum coverage violated”h]”hä)”}”(hjg  h]”hŒchecksum coverage violated”…””}”(hji  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hãh³hÇh´Mhje  ubah}”(h]”h ]”h"]”h$]”h&]”uh1j
  hj  ubj  )”}”(hŒbad checksum
”h]”hä)”}”(hŒbad checksum”h]”hŒbad checksum”…””}”(hj€  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hãh³hÇh´Mhj|  ubah}”(h]”h ]”h"]”h$]”h&]”uh1j
  hj  ubeh}”(h]”h ]”h"]”h$]”h&]”j¾  j  uh1j  h³hÇh´Kûhj   ubah}”(h]”h ]”h"]”h$]”h&]”uh1hÝh³hÇh´Kûhjï  ubeh}”(h]”h ]”h"]”h$]”h&]”uh1jh  hjÕ  ubeh}”(h]”h ]”h"]”h$]”h&]”uh1jc  hj`  ubjd  )”}”(hhh]”(ji  )”}”(hhh]”hä)”}”(hŒOutDatagrams”h]”hŒOutDatagrams”…””}”(hj²  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hãh³hÇh´Mhj¯  ubah}”(h]”h ]”h"]”h$]”h&]”uh1jh  hj¬  ubji  )”}”(hhh]”hä)”}”(hŒTotal number of sent datagrams.”h]”hŒTotal number of sent datagrams.”…””}”(hjÉ  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hãh³hÇh´MhjÆ  ubah}”(h]”h ]”h"]”h$]”h&]”uh1jh  hj¬  ubeh}”(h]”h ]”h"]”h$]”h&]”uh1jc  hj`  ubeh}”(h]”h ]”h"]”h$]”h&]”uh1j^  hjE  ubeh}”(h]”h ]”h"]”h$]”h&]”Œcols”Kuh1jC  hj@  ubah}”(h]”h ]”h"]”h$]”h&]”uh1j>  hj:  ubhä)”}”(hŒ4These statistics derive from the UDP MIB (RFC 2013).”h]”hŒ4These statistics derive from the UDP MIB (RFC 2013).”…””}”(hjö  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hãh³hÇh´Mhj:  ubeh}”(h]”h ]”h"]”h$]”h&]”uh1hÝh³hÇh´Kóhj  ubeh}”(h]”h ]”h"]”h$]”h&]”uh1hÝh³hÇh´Këhjû  h²hubeh}”(h]”Œ-udp-lite-runtime-statistics-and-their-meaning”ah ]”h"]”Œ05. udp-lite runtime statistics and their meaning”ah$]”h&]”uh1hÈhhÊh²hh³hÇh´KéubhÉ)”}”(hhh]”(hÎ)”}”(hŒ6. IPtables”h]”hŒ6. IPtables”…””}”(hj  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hÍhj  h²hh³hÇh´M
ubhÞ)”}”(hXV  There is packet match support for UDP-Lite as well as support for the LOG target.
If you copy and paste the following line into /etc/protocols::

  udplite 136     UDP-Lite        # UDP-Lite [RFC 3828]

then::

            iptables -A INPUT -p udplite -j LOG

will produce logging output to syslog. Dropping and rejecting packets also works.
”h]”(hä)”}”(hŒThere is packet match support for UDP-Lite as well as support for the LOG target.
If you copy and paste the following line into /etc/protocols::”h]”hŒThere is packet match support for UDP-Lite as well as support for the LOG target.
If you copy and paste the following line into /etc/protocols:”…””}”(hj-  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hãh³hÇh´Mhj)  ubjC  )”}”(hŒ5udplite 136     UDP-Lite        # UDP-Lite [RFC 3828]”h]”hŒ5udplite 136     UDP-Lite        # UDP-Lite [RFC 3828]”…””}”hj;  sbah}”(h]”h ]”h"]”h$]”h&]”hÅhÆuh1jB  h³hÇh´Mhj)  ubhä)”}”(hŒthen::”h]”hŒthen:”…””}”(hjI  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hãh³hÇh´Mhj)  ubjC  )”}”(hŒ#iptables -A INPUT -p udplite -j LOG”h]”hŒ#iptables -A INPUT -p udplite -j LOG”…””}”hjW  sbah}”(h]”h ]”h"]”h$]”h&]”hÅhÆuh1jB  h³hÇh´Mhj)  ubhä)”}”(hŒQwill produce logging output to syslog. Dropping and rejecting packets also works.”h]”hŒQwill produce logging output to syslog. Dropping and rejecting packets also works.”…””}”(hje  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hãh³hÇh´Mhj)  ubeh}”(h]”h ]”h"]”h$]”h&]”uh1hÝh³hÇh´Mhj  h²hubeh}”(h]”Œiptables”ah ]”h"]”Œ6. iptables”ah$]”h&]”uh1hÈhhÊh²hh³hÇh´M
ubhÉ)”}”(hhh]”(hÎ)”}”(hŒ7. Maintainer Address”h]”hŒ7. Maintainer Address”…””}”(hj„  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hÍhj  h²hh³hÇh´MubhÞ)”}”(hX†  The UDP-Lite patch was developed at

                  University of Aberdeen
                  Electronics Research Group
                  Department of Engineering
                  Fraser Noble Building
                  Aberdeen AB24 3UE; UK

The current maintainer is Gerrit Renker, <gerrit@erg.abdn.ac.uk>. Initial
code was developed by William  Stanislaus, <william@erg.abdn.ac.uk>.”h]”(hä)”}”(hŒ#The UDP-Lite patch was developed at”h]”hŒ#The UDP-Lite patch was developed at”…””}”(hj–  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hãh³hÇh´Mhj’  ubhÞ)”}”(hŒxUniversity of Aberdeen
Electronics Research Group
Department of Engineering
Fraser Noble Building
Aberdeen AB24 3UE; UK
”h]”hä)”}”(hŒwUniversity of Aberdeen
Electronics Research Group
Department of Engineering
Fraser Noble Building
Aberdeen AB24 3UE; UK”h]”hŒwUniversity of Aberdeen
Electronics Research Group
Department of Engineering
Fraser Noble Building
Aberdeen AB24 3UE; UK”…””}”(hj¨  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hãh³hÇh´Mhj¤  ubah}”(h]”h ]”h"]”h$]”h&]”uh1hÝh³hÇh´Mhj’  ubhä)”}”(hŒŽThe current maintainer is Gerrit Renker, <gerrit@erg.abdn.ac.uk>. Initial
code was developed by William  Stanislaus, <william@erg.abdn.ac.uk>.”h]”(hŒ*The current maintainer is Gerrit Renker, <”…””}”(hj¼  h²hh³Nh´Nubj  )”}”(hŒgerrit@erg.abdn.ac.uk”h]”hŒgerrit@erg.abdn.ac.uk”…””}”(hjÄ  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”Œrefuri”Œmailto:gerrit@erg.abdn.ac.uk”uh1j  hj¼  ubhŒ7>. Initial
code was developed by William  Stanislaus, <”…””}”(hj¼  h²hh³Nh´Nubj  )”}”(hŒwilliam@erg.abdn.ac.uk”h]”hŒwilliam@erg.abdn.ac.uk”…””}”(hjØ  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”Œrefuri”Œmailto:william@erg.abdn.ac.uk”uh1j  hj¼  ubhŒ>.”…””}”(hj¼  h²hh³Nh´Nubeh}”(h]”h ]”h"]”h$]”h&]”uh1hãh³hÇh´M"hj’  ubeh}”(h]”h ]”h"]”h$]”h&]”uh1hÝh³hÇh´Mhj  h²hubeh}”(h]”Œmaintainer-address”ah ]”h"]”Œ7. maintainer address”ah$]”h&]”uh1hÈhhÊh²hh³hÇh´Mubeh}”(h]”Œthe-udp-lite-protocol-rfc-3828”ah ]”h"]”Œ the udp-lite protocol (rfc 3828)”ah$]”h&]”uh1hÈhhh²hh³hÇh´Kubeh}”(h]”h ]”h"]”h$]”h&]”Œsource”hÇuh1hŒcurrent_source”NŒcurrent_line”NŒsettings”Œdocutils.frontend”ŒValues”“”)”}”(hÍNŒ	generator”NŒ	datestamp”NŒsource_link”NŒ
source_url”NŒtoc_backlinks”jh  Œfootnote_backlinks”KŒsectnum_xform”KŒstrip_comments”NŒstrip_elements_with_classes”NŒstrip_classes”NŒreport_level”KŒ
halt_level”KŒexit_status_level”KŒdebug”NŒwarning_stream”NŒ	traceback”ˆŒinput_encoding”Œ	utf-8-sig”Œinput_encoding_error_handler”Œstrict”Œoutput_encoding”Œutf-8”Œoutput_encoding_error_handler”j*	  Œerror_encoding”Œutf-8”Œerror_encoding_error_handler”Œbackslashreplace”Œlanguage_code”Œen”Œrecord_dependencies”NŒconfig”NŒ	id_prefix”hŒauto_id_prefix”Œid”Œdump_settings”NŒdump_internals”NŒdump_transforms”NŒdump_pseudo_xml”NŒexpose_internals”NŒstrict_visitor”NŒ_disable_config”NŒ_source”hÇŒ_destination”NŒ_config_files”]”Œ7/var/lib/git/docbuild/linux/Documentation/docutils.conf”aŒfile_insertion_enabled”ˆŒraw_enabled”KŒline_length_limit”M'Œpep_references”NŒpep_base_url”Œhttps://peps.python.org/”Œpep_file_url_template”Œpep-%04d”Œrfc_references”NŒrfc_base_url”Œ&https://datatracker.ietf.org/doc/html/”Œ	tab_width”KŒtrim_footnote_reference_space”‰Œsyntax_highlight”Œlong”Œsmart_quotes”ˆŒsmartquotes_locales”]”Œcharacter_level_inline_markup”‰Œdoctitle_xform”‰Œdocinfo_xform”KŒsectsubtitle_xform”‰Œimage_loading”Œlink”Œembed_stylesheet”‰Œcloak_email_addresses”ˆŒsection_self_link”‰Œenv”NubŒreporter”NŒindirect_targets”]”Œsubstitution_defs”}”Œsubstitution_names”}”Œrefnames”}”Œrefids”}”Œnameids”}”(j	  j	  j  j  j;  j8  jë  jè  jø  jõ  j  j  j~  j{  jý  jú  uŒ	nametypes”}”(j	  ‰j  ‰j;  ‰jë  ‰jø  ‰j  ‰j~  ‰jý  ‰uh}”(j	  hÊj  jÌ  j8  j  jè  j>  jõ  jî  j  jû  j{  j  jú  j  uŒfootnote_refs”}”Œcitation_refs”}”Œautofootnotes”]”Œautofootnote_refs”]”Œsymbol_footnotes”]”Œsymbol_footnote_refs”]”Œ	footnotes”]”Œ	citations”]”Œautofootnote_start”KŒsymbol_footnote_start”K Œ
id_counter”Œcollections”ŒCounter”“”}”…”R”Œparse_messages”]”(hŒsystem_message”“”)”}”(hhh]”hä)”}”(hŒ:Enumerated list start value not ordinal-1: "2" (ordinal 2)”h]”hŒ>Enumerated list start value not ordinal-1: â€œ2â€ (ordinal 2)”…””}”(hj‘	  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hãhjŽ	  ubah}”(h]”h ]”h"]”h$]”h&]”Œlevel”KŒtype”ŒINFO”Œsource”hÇŒline”Kuh1jŒ	  hjÿ  ubj	  )”}”(hhh]”hä)”}”(hŒ:Enumerated list start value not ordinal-1: "3" (ordinal 3)”h]”hŒ>Enumerated list start value not ordinal-1: â€œ3â€ (ordinal 3)”…””}”(hj­	  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hãhjª	  ubah}”(h]”h ]”h"]”h$]”h&]”Œlevel”KŒtype”j§	  Œsource”hÇŒline”Kuh1jŒ	  hjÿ  ubj	  )”}”(hhh]”hä)”}”(hŒ:Enumerated list start value not ordinal-1: "4" (ordinal 4)”h]”hŒ>Enumerated list start value not ordinal-1: â€œ4â€ (ordinal 4)”…””}”(hjÈ	  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hãhjÅ	  ubah}”(h]”h ]”h"]”h$]”h&]”Œlevel”KŒtype”j§	  Œsource”hÇŒline”Kuh1jŒ	  hjÿ  ubeŒtransform_messages”]”Œtransformer”NŒinclude_log”]”Œ
decoration”Nh²hub.