162306a36Sopenharmony_ci.. SPDX-License-Identifier: GPL-2.0 262306a36Sopenharmony_ci 362306a36Sopenharmony_ci================================ 462306a36Sopenharmony_ciThe UDP-Lite protocol (RFC 3828) 562306a36Sopenharmony_ci================================ 662306a36Sopenharmony_ci 762306a36Sopenharmony_ci 862306a36Sopenharmony_ci UDP-Lite is a Standards-Track IETF transport protocol whose characteristic 962306a36Sopenharmony_ci is a variable-length checksum. This has advantages for transport of multimedia 1062306a36Sopenharmony_ci (video, VoIP) over wireless networks, as partly damaged packets can still be 1162306a36Sopenharmony_ci fed into the codec instead of being discarded due to a failed checksum test. 1262306a36Sopenharmony_ci 1362306a36Sopenharmony_ci This file briefly describes the existing kernel support and the socket API. 1462306a36Sopenharmony_ci For in-depth information, you can consult: 1562306a36Sopenharmony_ci 1662306a36Sopenharmony_ci - The UDP-Lite Homepage: 1762306a36Sopenharmony_ci http://web.archive.org/web/%2E/http://www.erg.abdn.ac.uk/users/gerrit/udp-lite/ 1862306a36Sopenharmony_ci 1962306a36Sopenharmony_ci From here you can also download some example application source code. 2062306a36Sopenharmony_ci 2162306a36Sopenharmony_ci - The UDP-Lite HOWTO on 2262306a36Sopenharmony_ci http://web.archive.org/web/%2E/http://www.erg.abdn.ac.uk/users/gerrit/udp-lite/files/UDP-Lite-HOWTO.txt 2362306a36Sopenharmony_ci 2462306a36Sopenharmony_ci - The Wireshark UDP-Lite WiKi (with capture files): 2562306a36Sopenharmony_ci https://wiki.wireshark.org/Lightweight_User_Datagram_Protocol 2662306a36Sopenharmony_ci 2762306a36Sopenharmony_ci - The Protocol Spec, RFC 3828, http://www.ietf.org/rfc/rfc3828.txt 2862306a36Sopenharmony_ci 2962306a36Sopenharmony_ci 3062306a36Sopenharmony_ci1. Applications 3162306a36Sopenharmony_ci=============== 3262306a36Sopenharmony_ci 3362306a36Sopenharmony_ci Several applications have been ported successfully to UDP-Lite. Ethereal 3462306a36Sopenharmony_ci (now called wireshark) has UDP-Litev4/v6 support by default. 3562306a36Sopenharmony_ci 3662306a36Sopenharmony_ci Porting applications to UDP-Lite is straightforward: only socket level and 3762306a36Sopenharmony_ci IPPROTO need to be changed; senders additionally set the checksum coverage 3862306a36Sopenharmony_ci length (default = header length = 8). Details are in the next section. 3962306a36Sopenharmony_ci 4062306a36Sopenharmony_ci2. Programming API 4162306a36Sopenharmony_ci================== 4262306a36Sopenharmony_ci 4362306a36Sopenharmony_ci UDP-Lite provides a connectionless, unreliable datagram service and hence 4462306a36Sopenharmony_ci uses the same socket type as UDP. In fact, porting from UDP to UDP-Lite is 4562306a36Sopenharmony_ci very easy: simply add ``IPPROTO_UDPLITE`` as the last argument of the 4662306a36Sopenharmony_ci socket(2) call so that the statement looks like:: 4762306a36Sopenharmony_ci 4862306a36Sopenharmony_ci s = socket(PF_INET, SOCK_DGRAM, IPPROTO_UDPLITE); 4962306a36Sopenharmony_ci 5062306a36Sopenharmony_ci or, respectively, 5162306a36Sopenharmony_ci 5262306a36Sopenharmony_ci :: 5362306a36Sopenharmony_ci 5462306a36Sopenharmony_ci s = socket(PF_INET6, SOCK_DGRAM, IPPROTO_UDPLITE); 5562306a36Sopenharmony_ci 5662306a36Sopenharmony_ci With just the above change you are able to run UDP-Lite services or connect 5762306a36Sopenharmony_ci to UDP-Lite servers. The kernel will assume that you are not interested in 5862306a36Sopenharmony_ci using partial checksum coverage and so emulate UDP mode (full coverage). 5962306a36Sopenharmony_ci 6062306a36Sopenharmony_ci To make use of the partial checksum coverage facilities requires setting a 6162306a36Sopenharmony_ci single socket option, which takes an integer specifying the coverage length: 6262306a36Sopenharmony_ci 6362306a36Sopenharmony_ci * Sender checksum coverage: UDPLITE_SEND_CSCOV 6462306a36Sopenharmony_ci 6562306a36Sopenharmony_ci For example:: 6662306a36Sopenharmony_ci 6762306a36Sopenharmony_ci int val = 20; 6862306a36Sopenharmony_ci setsockopt(s, SOL_UDPLITE, UDPLITE_SEND_CSCOV, &val, sizeof(int)); 6962306a36Sopenharmony_ci 7062306a36Sopenharmony_ci sets the checksum coverage length to 20 bytes (12b data + 8b header). 7162306a36Sopenharmony_ci Of each packet only the first 20 bytes (plus the pseudo-header) will be 7262306a36Sopenharmony_ci checksummed. This is useful for RTP applications which have a 12-byte 7362306a36Sopenharmony_ci base header. 7462306a36Sopenharmony_ci 7562306a36Sopenharmony_ci 7662306a36Sopenharmony_ci * Receiver checksum coverage: UDPLITE_RECV_CSCOV 7762306a36Sopenharmony_ci 7862306a36Sopenharmony_ci This option is the receiver-side analogue. It is truly optional, i.e. not 7962306a36Sopenharmony_ci required to enable traffic with partial checksum coverage. Its function is 8062306a36Sopenharmony_ci that of a traffic filter: when enabled, it instructs the kernel to drop 8162306a36Sopenharmony_ci all packets which have a coverage _less_ than this value. For example, if 8262306a36Sopenharmony_ci RTP and UDP headers are to be protected, a receiver can enforce that only 8362306a36Sopenharmony_ci packets with a minimum coverage of 20 are admitted:: 8462306a36Sopenharmony_ci 8562306a36Sopenharmony_ci int min = 20; 8662306a36Sopenharmony_ci setsockopt(s, SOL_UDPLITE, UDPLITE_RECV_CSCOV, &min, sizeof(int)); 8762306a36Sopenharmony_ci 8862306a36Sopenharmony_ci The calls to getsockopt(2) are analogous. Being an extension and not a stand- 8962306a36Sopenharmony_ci alone protocol, all socket options known from UDP can be used in exactly the 9062306a36Sopenharmony_ci same manner as before, e.g. UDP_CORK or UDP_ENCAP. 9162306a36Sopenharmony_ci 9262306a36Sopenharmony_ci A detailed discussion of UDP-Lite checksum coverage options is in section IV. 9362306a36Sopenharmony_ci 9462306a36Sopenharmony_ci3. Header Files 9562306a36Sopenharmony_ci=============== 9662306a36Sopenharmony_ci 9762306a36Sopenharmony_ci The socket API requires support through header files in /usr/include: 9862306a36Sopenharmony_ci 9962306a36Sopenharmony_ci * /usr/include/netinet/in.h 10062306a36Sopenharmony_ci to define IPPROTO_UDPLITE 10162306a36Sopenharmony_ci 10262306a36Sopenharmony_ci * /usr/include/netinet/udplite.h 10362306a36Sopenharmony_ci for UDP-Lite header fields and protocol constants 10462306a36Sopenharmony_ci 10562306a36Sopenharmony_ci For testing purposes, the following can serve as a ``mini`` header file:: 10662306a36Sopenharmony_ci 10762306a36Sopenharmony_ci #define IPPROTO_UDPLITE 136 10862306a36Sopenharmony_ci #define SOL_UDPLITE 136 10962306a36Sopenharmony_ci #define UDPLITE_SEND_CSCOV 10 11062306a36Sopenharmony_ci #define UDPLITE_RECV_CSCOV 11 11162306a36Sopenharmony_ci 11262306a36Sopenharmony_ci Ready-made header files for various distros are in the UDP-Lite tarball. 11362306a36Sopenharmony_ci 11462306a36Sopenharmony_ci4. Kernel Behaviour with Regards to the Various Socket Options 11562306a36Sopenharmony_ci============================================================== 11662306a36Sopenharmony_ci 11762306a36Sopenharmony_ci 11862306a36Sopenharmony_ci To enable debugging messages, the log level need to be set to 8, as most 11962306a36Sopenharmony_ci messages use the KERN_DEBUG level (7). 12062306a36Sopenharmony_ci 12162306a36Sopenharmony_ci 1) Sender Socket Options 12262306a36Sopenharmony_ci 12362306a36Sopenharmony_ci If the sender specifies a value of 0 as coverage length, the module 12462306a36Sopenharmony_ci assumes full coverage, transmits a packet with coverage length of 0 12562306a36Sopenharmony_ci and according checksum. If the sender specifies a coverage < 8 and 12662306a36Sopenharmony_ci different from 0, the kernel assumes 8 as default value. Finally, 12762306a36Sopenharmony_ci if the specified coverage length exceeds the packet length, the packet 12862306a36Sopenharmony_ci length is used instead as coverage length. 12962306a36Sopenharmony_ci 13062306a36Sopenharmony_ci 2) Receiver Socket Options 13162306a36Sopenharmony_ci 13262306a36Sopenharmony_ci The receiver specifies the minimum value of the coverage length it 13362306a36Sopenharmony_ci is willing to accept. A value of 0 here indicates that the receiver 13462306a36Sopenharmony_ci always wants the whole of the packet covered. In this case, all 13562306a36Sopenharmony_ci partially covered packets are dropped and an error is logged. 13662306a36Sopenharmony_ci 13762306a36Sopenharmony_ci It is not possible to specify illegal values (<0 and <8); in these 13862306a36Sopenharmony_ci cases the default of 8 is assumed. 13962306a36Sopenharmony_ci 14062306a36Sopenharmony_ci All packets arriving with a coverage value less than the specified 14162306a36Sopenharmony_ci threshold are discarded, these events are also logged. 14262306a36Sopenharmony_ci 14362306a36Sopenharmony_ci 3) Disabling the Checksum Computation 14462306a36Sopenharmony_ci 14562306a36Sopenharmony_ci On both sender and receiver, checksumming will always be performed 14662306a36Sopenharmony_ci and cannot be disabled using SO_NO_CHECK. Thus:: 14762306a36Sopenharmony_ci 14862306a36Sopenharmony_ci setsockopt(sockfd, SOL_SOCKET, SO_NO_CHECK, ... ); 14962306a36Sopenharmony_ci 15062306a36Sopenharmony_ci will always will be ignored, while the value of:: 15162306a36Sopenharmony_ci 15262306a36Sopenharmony_ci getsockopt(sockfd, SOL_SOCKET, SO_NO_CHECK, &value, ...); 15362306a36Sopenharmony_ci 15462306a36Sopenharmony_ci is meaningless (as in TCP). Packets with a zero checksum field are 15562306a36Sopenharmony_ci illegal (cf. RFC 3828, sec. 3.1) and will be silently discarded. 15662306a36Sopenharmony_ci 15762306a36Sopenharmony_ci 4) Fragmentation 15862306a36Sopenharmony_ci 15962306a36Sopenharmony_ci The checksum computation respects both buffersize and MTU. The size 16062306a36Sopenharmony_ci of UDP-Lite packets is determined by the size of the send buffer. The 16162306a36Sopenharmony_ci minimum size of the send buffer is 2048 (defined as SOCK_MIN_SNDBUF 16262306a36Sopenharmony_ci in include/net/sock.h), the default value is configurable as 16362306a36Sopenharmony_ci net.core.wmem_default or via setting the SO_SNDBUF socket(7) 16462306a36Sopenharmony_ci option. The maximum upper bound for the send buffer is determined 16562306a36Sopenharmony_ci by net.core.wmem_max. 16662306a36Sopenharmony_ci 16762306a36Sopenharmony_ci Given a payload size larger than the send buffer size, UDP-Lite will 16862306a36Sopenharmony_ci split the payload into several individual packets, filling up the 16962306a36Sopenharmony_ci send buffer size in each case. 17062306a36Sopenharmony_ci 17162306a36Sopenharmony_ci The precise value also depends on the interface MTU. The interface MTU, 17262306a36Sopenharmony_ci in turn, may trigger IP fragmentation. In this case, the generated 17362306a36Sopenharmony_ci UDP-Lite packet is split into several IP packets, of which only the 17462306a36Sopenharmony_ci first one contains the L4 header. 17562306a36Sopenharmony_ci 17662306a36Sopenharmony_ci The send buffer size has implications on the checksum coverage length. 17762306a36Sopenharmony_ci Consider the following example:: 17862306a36Sopenharmony_ci 17962306a36Sopenharmony_ci Payload: 1536 bytes Send Buffer: 1024 bytes 18062306a36Sopenharmony_ci MTU: 1500 bytes Coverage Length: 856 bytes 18162306a36Sopenharmony_ci 18262306a36Sopenharmony_ci UDP-Lite will ship the 1536 bytes in two separate packets:: 18362306a36Sopenharmony_ci 18462306a36Sopenharmony_ci Packet 1: 1024 payload + 8 byte header + 20 byte IP header = 1052 bytes 18562306a36Sopenharmony_ci Packet 2: 512 payload + 8 byte header + 20 byte IP header = 540 bytes 18662306a36Sopenharmony_ci 18762306a36Sopenharmony_ci The coverage packet covers the UDP-Lite header and 848 bytes of the 18862306a36Sopenharmony_ci payload in the first packet, the second packet is fully covered. Note 18962306a36Sopenharmony_ci that for the second packet, the coverage length exceeds the packet 19062306a36Sopenharmony_ci length. The kernel always re-adjusts the coverage length to the packet 19162306a36Sopenharmony_ci length in such cases. 19262306a36Sopenharmony_ci 19362306a36Sopenharmony_ci As an example of what happens when one UDP-Lite packet is split into 19462306a36Sopenharmony_ci several tiny fragments, consider the following example:: 19562306a36Sopenharmony_ci 19662306a36Sopenharmony_ci Payload: 1024 bytes Send buffer size: 1024 bytes 19762306a36Sopenharmony_ci MTU: 300 bytes Coverage length: 575 bytes 19862306a36Sopenharmony_ci 19962306a36Sopenharmony_ci +-+-----------+--------------+--------------+--------------+ 20062306a36Sopenharmony_ci |8| 272 | 280 | 280 | 280 | 20162306a36Sopenharmony_ci +-+-----------+--------------+--------------+--------------+ 20262306a36Sopenharmony_ci 280 560 840 1032 20362306a36Sopenharmony_ci ^ 20462306a36Sopenharmony_ci *****checksum coverage************* 20562306a36Sopenharmony_ci 20662306a36Sopenharmony_ci The UDP-Lite module generates one 1032 byte packet (1024 + 8 byte 20762306a36Sopenharmony_ci header). According to the interface MTU, these are split into 4 IP 20862306a36Sopenharmony_ci packets (280 byte IP payload + 20 byte IP header). The kernel module 20962306a36Sopenharmony_ci sums the contents of the entire first two packets, plus 15 bytes of 21062306a36Sopenharmony_ci the last packet before releasing the fragments to the IP module. 21162306a36Sopenharmony_ci 21262306a36Sopenharmony_ci To see the analogous case for IPv6 fragmentation, consider a link 21362306a36Sopenharmony_ci MTU of 1280 bytes and a write buffer of 3356 bytes. If the checksum 21462306a36Sopenharmony_ci coverage is less than 1232 bytes (MTU minus IPv6/fragment header 21562306a36Sopenharmony_ci lengths), only the first fragment needs to be considered. When using 21662306a36Sopenharmony_ci larger checksum coverage lengths, each eligible fragment needs to be 21762306a36Sopenharmony_ci checksummed. Suppose we have a checksum coverage of 3062. The buffer 21862306a36Sopenharmony_ci of 3356 bytes will be split into the following fragments:: 21962306a36Sopenharmony_ci 22062306a36Sopenharmony_ci Fragment 1: 1280 bytes carrying 1232 bytes of UDP-Lite data 22162306a36Sopenharmony_ci Fragment 2: 1280 bytes carrying 1232 bytes of UDP-Lite data 22262306a36Sopenharmony_ci Fragment 3: 948 bytes carrying 900 bytes of UDP-Lite data 22362306a36Sopenharmony_ci 22462306a36Sopenharmony_ci The first two fragments have to be checksummed in full, of the last 22562306a36Sopenharmony_ci fragment only 598 (= 3062 - 2*1232) bytes are checksummed. 22662306a36Sopenharmony_ci 22762306a36Sopenharmony_ci While it is important that such cases are dealt with correctly, they 22862306a36Sopenharmony_ci are (annoyingly) rare: UDP-Lite is designed for optimising multimedia 22962306a36Sopenharmony_ci performance over wireless (or generally noisy) links and thus smaller 23062306a36Sopenharmony_ci coverage lengths are likely to be expected. 23162306a36Sopenharmony_ci 23262306a36Sopenharmony_ci5. UDP-Lite Runtime Statistics and their Meaning 23362306a36Sopenharmony_ci================================================ 23462306a36Sopenharmony_ci 23562306a36Sopenharmony_ci Exceptional and error conditions are logged to syslog at the KERN_DEBUG 23662306a36Sopenharmony_ci level. Live statistics about UDP-Lite are available in /proc/net/snmp 23762306a36Sopenharmony_ci and can (with newer versions of netstat) be viewed using:: 23862306a36Sopenharmony_ci 23962306a36Sopenharmony_ci netstat -svu 24062306a36Sopenharmony_ci 24162306a36Sopenharmony_ci This displays UDP-Lite statistics variables, whose meaning is as follows. 24262306a36Sopenharmony_ci 24362306a36Sopenharmony_ci ============ ===================================================== 24462306a36Sopenharmony_ci InDatagrams The total number of datagrams delivered to users. 24562306a36Sopenharmony_ci 24662306a36Sopenharmony_ci NoPorts Number of packets received to an unknown port. 24762306a36Sopenharmony_ci These cases are counted separately (not as InErrors). 24862306a36Sopenharmony_ci 24962306a36Sopenharmony_ci InErrors Number of erroneous UDP-Lite packets. Errors include: 25062306a36Sopenharmony_ci 25162306a36Sopenharmony_ci * internal socket queue receive errors 25262306a36Sopenharmony_ci * packet too short (less than 8 bytes or stated 25362306a36Sopenharmony_ci coverage length exceeds received length) 25462306a36Sopenharmony_ci * xfrm4_policy_check() returned with error 25562306a36Sopenharmony_ci * application has specified larger min. coverage 25662306a36Sopenharmony_ci length than that of incoming packet 25762306a36Sopenharmony_ci * checksum coverage violated 25862306a36Sopenharmony_ci * bad checksum 25962306a36Sopenharmony_ci 26062306a36Sopenharmony_ci OutDatagrams Total number of sent datagrams. 26162306a36Sopenharmony_ci ============ ===================================================== 26262306a36Sopenharmony_ci 26362306a36Sopenharmony_ci These statistics derive from the UDP MIB (RFC 2013). 26462306a36Sopenharmony_ci 26562306a36Sopenharmony_ci6. IPtables 26662306a36Sopenharmony_ci=========== 26762306a36Sopenharmony_ci 26862306a36Sopenharmony_ci There is packet match support for UDP-Lite as well as support for the LOG target. 26962306a36Sopenharmony_ci If you copy and paste the following line into /etc/protocols:: 27062306a36Sopenharmony_ci 27162306a36Sopenharmony_ci udplite 136 UDP-Lite # UDP-Lite [RFC 3828] 27262306a36Sopenharmony_ci 27362306a36Sopenharmony_ci then:: 27462306a36Sopenharmony_ci 27562306a36Sopenharmony_ci iptables -A INPUT -p udplite -j LOG 27662306a36Sopenharmony_ci 27762306a36Sopenharmony_ci will produce logging output to syslog. Dropping and rejecting packets also works. 27862306a36Sopenharmony_ci 27962306a36Sopenharmony_ci7. Maintainer Address 28062306a36Sopenharmony_ci===================== 28162306a36Sopenharmony_ci 28262306a36Sopenharmony_ci The UDP-Lite patch was developed at 28362306a36Sopenharmony_ci 28462306a36Sopenharmony_ci University of Aberdeen 28562306a36Sopenharmony_ci Electronics Research Group 28662306a36Sopenharmony_ci Department of Engineering 28762306a36Sopenharmony_ci Fraser Noble Building 28862306a36Sopenharmony_ci Aberdeen AB24 3UE; UK 28962306a36Sopenharmony_ci 29062306a36Sopenharmony_ci The current maintainer is Gerrit Renker, <gerrit@erg.abdn.ac.uk>. Initial 29162306a36Sopenharmony_ci code was developed by William Stanislaus, <william@erg.abdn.ac.uk>. 292