In IPv4,IP_MTU is only supported by getsockopt.
In IPv6, we can use IPV6_MTU to set socket's MTU,
but the return value of getsockopt() is the path MTU.
Signed-off-by: Gao feng <gaofeng@cn.fujitsu.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
The example uses sendmmsg() to send out a string "onetwo"
on a first datagram, where both halves originate from
distinct buffers and a second datagram contains "three",
coming from a single buffer.
Tested with netcat listening:
root@ubuntu:~# nc -l -u -p 1234
onetwothree
And tcpdump peeking:
root@ubuntu:~# tcpdump -c 2 -s 0 -X -ni lo tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on lo, link-type EN10MB (Ethernet), capture size 65535 bytes
18:45:16.632134 IP 127.0.0.1.34715 > 127.0.0.1.1234: UDP, length 6
0x0000: 4500 0022 c21c 4000 4011 7aac 7f00 0001 E.."..@.@.z.....
0x0010: 7f00 0001 879b 04d2 000e fe21 6f6e 6574 ...........!onet
0x0020: 776f wo
18:45:16.633267 IP 127.0.0.1.34715 > 127.0.0.1.1234: UDP, length 5
0x0000: 4500 0021 c21d 4000 4011 7aac 7f00 0001 E..!..@.@.z.....
0x0010: 7f00 0001 879b 04d2 000d fe20 7468 7265 ............thre
0x0020: 65 e
2 packets captured
4 packets received by filter
0 packets dropped by kernel
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
SYSLOG_ACTION_SIZE_UNREAD returns the number of bytes
available for reading via SYSLOG_ACTION_READ.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
The SYSLOG_ACTION_CLEAR command (5) does not really clear
the ring buffer; rather it affects the semantics of what
is returned by commands 3 (SYSLOG_ACTION_READ_ALL) and
4 (SYSLOG_ACTION_READ_CLEAR).
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Note that sign of result equals sign of difference between
first two bytes that differ (treated as "unsigned char")."
Reported-by: Jon Grant <jg@jguk.org>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Note that sign of result equals sign of difference between
first two bytes that differ (treated as "unsigned char")."
Reported-by: Jon Grant <jg@jguk.org>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Upon encountering the RLIMIT_CPU soft limit when a SIGXCPU handler
has been installed, Linux invokes the signal handler *and* raises
the soft limit by one second. This behavior repeats until the
limit is encountered. No other implementation that I tested
(Solaris 10, FreeBSD 9.0, OpenBSD 5.0) does this, and it seems
unlikely to be POSIX-conformant. The (Linux-specific)
RLIMIT_RTTIME soft limit exhibits similar behavior.
Reported-by: Trevor Woerner <twoerner@gmail.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
The existing text suggested that the ERRORS applied
only for ttyname_r(). However, 2 of the 3 errors
can occur for ttyname().
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
The EOVERFLOW error is not only for st_size, but also
inode and block size fields. See glibc source file
sysdeps/unix/sysv/linux/xstatconv.c and kernel source
file fs/stat.c. Also, fix bit/byte confusion
See http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=604928
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Michael Kerrisk