It seems sendto() can return EACCES for UDP as well; the current
man page in git only says it can return EACCES for Unix sockets.
I was able to make sendto() return EACCES if I try to send from
192.168.1.1/24 to 192.168.1.0. I think the relevant code (in
kernel 2.6.38, but also present in 2.6.7 and 2.6.32, the 2 kernels
we use) is this (net/ipv4/udp.c, udp_sendmsg()):
910 err = -EACCES;
911 if ((rt->rt_flags & RTCF_BROADCAST) &&
912 !sock_flag(sk, SOCK_BROADCAST))
913 goto out;
So I guess if the kernel finds a route to the destination and
it's a broadcast route (and the socket doesn't have the broadcast
flag), then it returns EACCES.
I can verify the behavior with a very simple program (attached).
I've run it on my Ubuntu 10.10 (2.6.35 kernel) and got this:
stefan@spuiu-vml2:~/src/test/broadcast$ ./broadcast_test 10.205.20.94
10.205.20.1
sendto() returned 4
stefan@spuiu-vml2:~/src/test/broadcast$ ./broadcast_test 10.205.20.94
10.205.20.0
sendto() returned negative, errno: 13/Permission denied
(10.205.20.94 is my local IP, of course).
=====
#include <stdio.h>
#include <sys/types.h>
#include <sys/socket.h>
#include <netinet/in.h>
#include <arpa/inet.h>
#include <errno.h>
#include <stdlib.h>
int main(int argc, char **argv)
{
int sock;
if (argc < 2) {
printf("Usage: %s local_address destination_address\n", argv[0]);
exit(1);
}
sock = socket(AF_INET, SOCK_DGRAM, 0);
if (sock < 0) {
perror("socket");
return -1;
}
struct sockaddr_in local_addr;
local_addr.sin_family = AF_INET;
local_addr.sin_port = htons(1234);
local_addr.sin_addr.s_addr = inet_addr(argv[1]);
int ret = bind(sock, (struct sockaddr *) &local_addr, sizeof(local_addr));
if (ret < 0) {
perror("bind");
return -1;
}
struct sockaddr_in remote_addr;
remote_addr.sin_family = AF_INET;
remote_addr.sin_port = htons(1234);
remote_addr.sin_addr.s_addr = inet_addr(argv[2]);
ret = sendto(sock, "blah", 4, 0, (struct sockaddr *)&remote_addr, sizeof(remote_addr));
if (ret < 0) {
printf("sendto() returned negative, errno: %d/%m\n", errno);
}
else {
printf("sendto() returned %d\n", ret);
}
return 0;
}
=====
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
glibc stopped providing these interfaces with v2.2.
Nowadays, the user that finds these pages probably wants
the libdb API, so note this in the page.
See http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=337581
Reported-by: Brian M. Carlson <sandals@crustytoothpaste.net>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
POSIX requires that perror() not modify the static storage
returned by strerror(). POSIX 2008 and C99 both require that
strerror() never return NULL (a strerror() that always
returns "" for all inputs is valid for C99, but not for POSIX).
http://sourceware.org/bugzilla/show_bug.cgi?id=12204
documents glibc's change to come into compliance with POSIX
regarding strerror_r() return value. The GNU strerror_r() use
of 'buf' was confusing - I ended up writing a test program that
proves that 'buf' is unused for valid 'errnum', but contains
truncated "unknown message" for out-of-range 'errnum'.
See also http://austingroupbugs.net/view.php?id=382
Reviewed-by: Stefan Puiu <stefan.puiu@gmail.com>
Signed-off-by: Eric Blake <eblake@redhat.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
The XSI-compliant version of strerror_r() doesn't return -1 on
error and set errno. Instead, a positive error number is returned.
That's what POSIX says:
Upon successful completion, strerror_r() shall return 0.
Otherwise, an error number shall be returned to indicate
the error.
I tested with an invalid error number. While some implementations
seem to write "Unknown error xxx" into the supplied buffer, some
others don't and only return EINVAL. The latest glibc 2.14.1 from
Arch Linux belongs to the first category while eglibc 2.13 from
current Debian testing belongs to the second category.
However, both implementation are correct according to POSIX. So I
think the manpage was wrong and POSIX and the implementations are
correct.
Signed-off-by: Signed-off-by: Bernhard Walle <bernhard@bwalle.de>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
An explicit pointer to ptsname(3) is useful, as is a note
of the fact that the slave device pathname exists only as
long as the master device is held open.
Reported-by: Vadim Mikhailov <vadim.mikhailov@gmail.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
For a long time now, glibc's raise(3) didn't yield SI_USER
for the signal receiver, so remove mention of raise(3)
here. The user can deduce the details, if needed, by looking
at the recently updated raise(3) page.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Wording by Aurelien Jarno from Debian glibc's r4701 (2011-06-04).
Addresses http://bugs.debian.org/622385
Reported-by: Reuben Thomas <rrt@sc3d.org>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
For some casual readers of the Makefile, "mkdir -p" is
probably a little easier to read than the equivalent "-make".
Reported-by: Reuben Thomas <rrt@sc3d.org>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Remove some FIXMEs and comment out pieces of text that describe
features not yet merged mainline kernel.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
* Wording improvements
* Addition of some FIXMEs for suspicious points
* Addition of various EINVAL cases
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
"uninstall" is the GNU standard name for the target,
so it'll be the one most users are used to.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
As Simone notes, RETURN VALUE says:
On error, (clock_t) -1 is returned, and errno is set appropriately
but no value for errno is specified. The only error case is
EFAULT, so let's add that.
Reported-by: Simone Piccardi <piccardi@truelite.it>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>