The problem shows in the following log snippet. The numeric address of
the peer (localhost in this case) is garbage.
rsyncd[32671]: reverse name lookup failed
rsyncd[32671]: rsync: forward name lookup for failed: Name or service not known
rsyncd[32671]: rsync on debian/ from UNKNOWN (::10fa:ffbf:a426:608%5)
rsyncd[32671]: wrote 616 bytes read 70 bytes total size 143069
I am using linux 2.4.10-pre14 with GNU C lib 2.2.4. To be precise, the
libc comes with Debian unstable distribution and its exact version is
2.2.4-6. The Debian's changelog says for 2.2.4-5:
* Pulled from CVS as of Oct 27, 2001:
- Includes fnmatch fix upstream.
- strxfrm fix.
- dlfcn fix for C++ program usage.
- ENABLE_NLS fixes for various functions (doesn't affect us, sinceit is
mainly meant for non-nls builds).
- IPv6 reverse lookup fixes.
...
However, I think the problem may not be specific to this C lib
version.
I applied this patch to socket.c:client_addr() to experiment a bit:
--- socket.c.orig Tue Nov 27 08:01:05 2001
+++ socket.c Sun Dec 2 21:04:20 2001
@@ -555,7 +555,7 @@
**/
char *client_addr(int fd)
{
- struct sockaddr ss;
+ struct sockaddr_storage ss;
int length = sizeof(ss);
static char addr_buf[100];
static int initialised;
@@ -564,11 +564,14 @@
initialised = 1;
- if (getpeername(fd, &ss, &length)) {
+ if (getpeername(fd, (struct sockaddr *)&ss, &length)) {
exit_cleanup(RERR_SOCKETIO);
}
- getnameinfo(&ss, length,
+ syslog(LOG_INFO, "length %d, sizes: sockaddr %u, sockaddr_storage
%u",
+ length, sizeof (struct sockaddr), sizeof (struct
sockaddr_storage));
+
+ getnameinfo((struct sockaddr *)&ss, length,
addr_buf, sizeof(addr_buf), NULL, 0, NI_NUMERICHOST);
return addr_buf;
}
The patch replaces struct sockaddr with struct sockaddr_storage and
prints some length information into the syslog. The idea of using
struct sockaddr_storage came from KAME's patch for 2.4.6 and Itojun's
AF-independent application paper at
http://www.kame.net/newsletter/19980604/
The results were:
rsyncd[32707]: length 28, sizes: sockaddr 16, sockaddr_storage 128
rsyncd[32707]: reverse name lookup failed
rsyncd[32707]: rsync: forward name lookup for failed: Name or service not known
rsyncd[32707]: rsync on debian/ from UNKNOWN (::ffff:127.0.0.1)
rsyncd[32707]: wrote 616 bytes read 70 bytes total size 143069
The forward name lookup still fails but at least the numeric address
is correct. It looks like the trucation getpeername() has to do goes
unnoticed and this causes problems with output from getnameinfo(). In
message <20010813234035.I1015@wistful.humbug.org.au> Martin wrotes
that:
I have merged the KAME.net IPv6 patch onto the track-kameipv6
branch. It compiles and seems to work but is not yet updated to fit
into HEAD (i.e. 2.4.7pre).
There are some issues that need to be addressed: in particular I
think the patch makes more assumptions about having a modern sockets
interface than we can get away with on all our systems.
I guess this is one of the issues that need addressing?
--
Heikki Vatiainen * hessu@cs.tut.fi
Tampere University of Technology * Tampere, Finland
