^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 1) .. SPDX-License-Identifier: GPL-2.0
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 2)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 3) ================================
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 4) The UDP-Lite protocol (RFC 3828)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 5) ================================
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 6)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 7)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 8) UDP-Lite is a Standards-Track IETF transport protocol whose characteristic
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 9) is a variable-length checksum. This has advantages for transport of multimedia
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 10) (video, VoIP) over wireless networks, as partly damaged packets can still be
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 11) fed into the codec instead of being discarded due to a failed checksum test.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 12)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 13) This file briefly describes the existing kernel support and the socket API.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 14) For in-depth information, you can consult:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 15)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 16) - The UDP-Lite Homepage:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 17) http://web.archive.org/web/%2E/http://www.erg.abdn.ac.uk/users/gerrit/udp-lite/
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 18)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 19) From here you can also download some example application source code.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 20)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 21) - The UDP-Lite HOWTO on
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 22) http://web.archive.org/web/%2E/http://www.erg.abdn.ac.uk/users/gerrit/udp-lite/files/UDP-Lite-HOWTO.txt
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 23)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 24) - The Wireshark UDP-Lite WiKi (with capture files):
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 25) https://wiki.wireshark.org/Lightweight_User_Datagram_Protocol
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 26)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 27) - The Protocol Spec, RFC 3828, http://www.ietf.org/rfc/rfc3828.txt
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 28)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 29)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 30) 1. Applications
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 31) ===============
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 32)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 33) Several applications have been ported successfully to UDP-Lite. Ethereal
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 34) (now called wireshark) has UDP-Litev4/v6 support by default.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 35)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 36) Porting applications to UDP-Lite is straightforward: only socket level and
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 37) IPPROTO need to be changed; senders additionally set the checksum coverage
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 38) length (default = header length = 8). Details are in the next section.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 39)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 40) 2. Programming API
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 41) ==================
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 42)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 43) UDP-Lite provides a connectionless, unreliable datagram service and hence
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 44) uses the same socket type as UDP. In fact, porting from UDP to UDP-Lite is
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 45) very easy: simply add ``IPPROTO_UDPLITE`` as the last argument of the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 46) socket(2) call so that the statement looks like::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 47)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 48) s = socket(PF_INET, SOCK_DGRAM, IPPROTO_UDPLITE);
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 49)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 50) or, respectively,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 51)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 52) ::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 53)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 54) s = socket(PF_INET6, SOCK_DGRAM, IPPROTO_UDPLITE);
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 55)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 56) With just the above change you are able to run UDP-Lite services or connect
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 57) to UDP-Lite servers. The kernel will assume that you are not interested in
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 58) using partial checksum coverage and so emulate UDP mode (full coverage).
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 59)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 60) To make use of the partial checksum coverage facilities requires setting a
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 61) single socket option, which takes an integer specifying the coverage length:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 62)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 63) * Sender checksum coverage: UDPLITE_SEND_CSCOV
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 64)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 65) For example::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 66)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 67) int val = 20;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 68) setsockopt(s, SOL_UDPLITE, UDPLITE_SEND_CSCOV, &val, sizeof(int));
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 69)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 70) sets the checksum coverage length to 20 bytes (12b data + 8b header).
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 71) Of each packet only the first 20 bytes (plus the pseudo-header) will be
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 72) checksummed. This is useful for RTP applications which have a 12-byte
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 73) base header.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 74)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 75)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 76) * Receiver checksum coverage: UDPLITE_RECV_CSCOV
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 77)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 78) This option is the receiver-side analogue. It is truly optional, i.e. not
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 79) required to enable traffic with partial checksum coverage. Its function is
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 80) that of a traffic filter: when enabled, it instructs the kernel to drop
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 81) all packets which have a coverage _less_ than this value. For example, if
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 82) RTP and UDP headers are to be protected, a receiver can enforce that only
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 83) packets with a minimum coverage of 20 are admitted::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 84)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 85) int min = 20;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 86) setsockopt(s, SOL_UDPLITE, UDPLITE_RECV_CSCOV, &min, sizeof(int));
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 87)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 88) The calls to getsockopt(2) are analogous. Being an extension and not a stand-
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 89) alone protocol, all socket options known from UDP can be used in exactly the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 90) same manner as before, e.g. UDP_CORK or UDP_ENCAP.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 91)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 92) A detailed discussion of UDP-Lite checksum coverage options is in section IV.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 93)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 94) 3. Header Files
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 95) ===============
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 96)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 97) The socket API requires support through header files in /usr/include:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 98)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 99) * /usr/include/netinet/in.h
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 100) to define IPPROTO_UDPLITE
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 101)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 102) * /usr/include/netinet/udplite.h
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 103) for UDP-Lite header fields and protocol constants
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 104)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 105) For testing purposes, the following can serve as a ``mini`` header file::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 106)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 107) #define IPPROTO_UDPLITE 136
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 108) #define SOL_UDPLITE 136
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 109) #define UDPLITE_SEND_CSCOV 10
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 110) #define UDPLITE_RECV_CSCOV 11
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 111)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 112) Ready-made header files for various distros are in the UDP-Lite tarball.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 113)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 114) 4. Kernel Behaviour with Regards to the Various Socket Options
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 115) ==============================================================
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 116)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 117)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 118) To enable debugging messages, the log level need to be set to 8, as most
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 119) messages use the KERN_DEBUG level (7).
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 120)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 121) 1) Sender Socket Options
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 122)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 123) If the sender specifies a value of 0 as coverage length, the module
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 124) assumes full coverage, transmits a packet with coverage length of 0
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 125) and according checksum. If the sender specifies a coverage < 8 and
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 126) different from 0, the kernel assumes 8 as default value. Finally,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 127) if the specified coverage length exceeds the packet length, the packet
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 128) length is used instead as coverage length.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 129)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 130) 2) Receiver Socket Options
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 131)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 132) The receiver specifies the minimum value of the coverage length it
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 133) is willing to accept. A value of 0 here indicates that the receiver
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 134) always wants the whole of the packet covered. In this case, all
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 135) partially covered packets are dropped and an error is logged.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 136)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 137) It is not possible to specify illegal values (<0 and <8); in these
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 138) cases the default of 8 is assumed.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 139)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 140) All packets arriving with a coverage value less than the specified
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 141) threshold are discarded, these events are also logged.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 142)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 143) 3) Disabling the Checksum Computation
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 144)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 145) On both sender and receiver, checksumming will always be performed
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 146) and cannot be disabled using SO_NO_CHECK. Thus::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 147)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 148) setsockopt(sockfd, SOL_SOCKET, SO_NO_CHECK, ... );
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 149)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 150) will always will be ignored, while the value of::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 151)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 152) getsockopt(sockfd, SOL_SOCKET, SO_NO_CHECK, &value, ...);
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 153)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 154) is meaningless (as in TCP). Packets with a zero checksum field are
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 155) illegal (cf. RFC 3828, sec. 3.1) and will be silently discarded.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 156)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 157) 4) Fragmentation
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 158)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 159) The checksum computation respects both buffersize and MTU. The size
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 160) of UDP-Lite packets is determined by the size of the send buffer. The
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 161) minimum size of the send buffer is 2048 (defined as SOCK_MIN_SNDBUF
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 162) in include/net/sock.h), the default value is configurable as
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 163) net.core.wmem_default or via setting the SO_SNDBUF socket(7)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 164) option. The maximum upper bound for the send buffer is determined
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 165) by net.core.wmem_max.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 166)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 167) Given a payload size larger than the send buffer size, UDP-Lite will
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 168) split the payload into several individual packets, filling up the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 169) send buffer size in each case.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 170)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 171) The precise value also depends on the interface MTU. The interface MTU,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 172) in turn, may trigger IP fragmentation. In this case, the generated
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 173) UDP-Lite packet is split into several IP packets, of which only the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 174) first one contains the L4 header.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 175)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 176) The send buffer size has implications on the checksum coverage length.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 177) Consider the following example::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 178)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 179) Payload: 1536 bytes Send Buffer: 1024 bytes
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 180) MTU: 1500 bytes Coverage Length: 856 bytes
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 181)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 182) UDP-Lite will ship the 1536 bytes in two separate packets::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 183)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 184) Packet 1: 1024 payload + 8 byte header + 20 byte IP header = 1052 bytes
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 185) Packet 2: 512 payload + 8 byte header + 20 byte IP header = 540 bytes
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 186)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 187) The coverage packet covers the UDP-Lite header and 848 bytes of the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 188) payload in the first packet, the second packet is fully covered. Note
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 189) that for the second packet, the coverage length exceeds the packet
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 190) length. The kernel always re-adjusts the coverage length to the packet
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 191) length in such cases.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 192)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 193) As an example of what happens when one UDP-Lite packet is split into
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 194) several tiny fragments, consider the following example::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 195)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 196) Payload: 1024 bytes Send buffer size: 1024 bytes
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 197) MTU: 300 bytes Coverage length: 575 bytes
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 198)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 199) +-+-----------+--------------+--------------+--------------+
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 200) |8| 272 | 280 | 280 | 280 |
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 201) +-+-----------+--------------+--------------+--------------+
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 202) 280 560 840 1032
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 203) ^
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 204) *****checksum coverage*************
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 205)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 206) The UDP-Lite module generates one 1032 byte packet (1024 + 8 byte
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 207) header). According to the interface MTU, these are split into 4 IP
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 208) packets (280 byte IP payload + 20 byte IP header). The kernel module
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 209) sums the contents of the entire first two packets, plus 15 bytes of
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 210) the last packet before releasing the fragments to the IP module.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 211)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 212) To see the analogous case for IPv6 fragmentation, consider a link
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 213) MTU of 1280 bytes and a write buffer of 3356 bytes. If the checksum
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 214) coverage is less than 1232 bytes (MTU minus IPv6/fragment header
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 215) lengths), only the first fragment needs to be considered. When using
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 216) larger checksum coverage lengths, each eligible fragment needs to be
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 217) checksummed. Suppose we have a checksum coverage of 3062. The buffer
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 218) of 3356 bytes will be split into the following fragments::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 219)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 220) Fragment 1: 1280 bytes carrying 1232 bytes of UDP-Lite data
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 221) Fragment 2: 1280 bytes carrying 1232 bytes of UDP-Lite data
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 222) Fragment 3: 948 bytes carrying 900 bytes of UDP-Lite data
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 223)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 224) The first two fragments have to be checksummed in full, of the last
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 225) fragment only 598 (= 3062 - 2*1232) bytes are checksummed.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 226)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 227) While it is important that such cases are dealt with correctly, they
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 228) are (annoyingly) rare: UDP-Lite is designed for optimising multimedia
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 229) performance over wireless (or generally noisy) links and thus smaller
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 230) coverage lengths are likely to be expected.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 231)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 232) 5. UDP-Lite Runtime Statistics and their Meaning
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 233) ================================================
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 234)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 235) Exceptional and error conditions are logged to syslog at the KERN_DEBUG
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 236) level. Live statistics about UDP-Lite are available in /proc/net/snmp
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 237) and can (with newer versions of netstat) be viewed using::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 238)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 239) netstat -svu
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 240)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 241) This displays UDP-Lite statistics variables, whose meaning is as follows.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 242)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 243) ============ =====================================================
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 244) InDatagrams The total number of datagrams delivered to users.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 245)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 246) NoPorts Number of packets received to an unknown port.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 247) These cases are counted separately (not as InErrors).
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 248)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 249) InErrors Number of erroneous UDP-Lite packets. Errors include:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 250)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 251) * internal socket queue receive errors
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 252) * packet too short (less than 8 bytes or stated
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 253) coverage length exceeds received length)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 254) * xfrm4_policy_check() returned with error
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 255) * application has specified larger min. coverage
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 256) length than that of incoming packet
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 257) * checksum coverage violated
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 258) * bad checksum
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 259)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 260) OutDatagrams Total number of sent datagrams.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 261) ============ =====================================================
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 262)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 263) These statistics derive from the UDP MIB (RFC 2013).
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 264)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 265) 6. IPtables
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 266) ===========
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 267)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 268) There is packet match support for UDP-Lite as well as support for the LOG target.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 269) If you copy and paste the following line into /etc/protocols::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 270)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 271) udplite 136 UDP-Lite # UDP-Lite [RFC 3828]
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 272)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 273) then::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 274)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 275) iptables -A INPUT -p udplite -j LOG
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 276)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 277) will produce logging output to syslog. Dropping and rejecting packets also works.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 278)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 279) 7. Maintainer Address
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 280) =====================
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 281)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 282) The UDP-Lite patch was developed at
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 283)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 284) University of Aberdeen
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 285) Electronics Research Group
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 286) Department of Engineering
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 287) Fraser Noble Building
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 288) Aberdeen AB24 3UE; UK
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 289)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 290) The current maintainer is Gerrit Renker, <gerrit@erg.abdn.ac.uk>. Initial
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 291) code was developed by William Stanislaus, <william@erg.abdn.ac.uk>.
Orange Pi5 kernel
Deprecated Linux kernel 5.10.110 for OrangePi 5/5B/5+ boards
3 Commits
0 Branches
0 Tags