On 13 Aug 2001, "William F. Maton" <wmaton@ryouko.dgim.crc.ca> wrote:> On 13 Aug 2001, Heikki Vatiainen wrote: > > > The rsync daemon we use is plain 2.4.6 patched with KAME rsync patch > > rsync-246-v6-20000907.diff.gz [1]. It looks like there is a good > > possibility to get IPv6 merged in, since just today a rsync developer > > was asking if anyone wants it [2]. If no one objects, I can reply and > > say that Debian IPv6 project has interest in this. > > Please do.OK. (Free software is so good sometimes. :-) So, perhaps I can draw on the expertise of people on this list and ask a few questions: After looking through the KAME rsync patch it seems reasonable. One concern is that its configure.in tests whether the *build* machine has IPv6 in the kernel, and uses that as apparently a gating condition on including IPv6 support. I can imagine distribution-builders who may not have IPv6 in the build machine kernel, but still want to enable it in binary packages. We could easily fix this. rsync supports a fair number of unix-like platforms at the moment, some of which are rather old or idiosyncratic. So, while the new IPv6/v4 sockets API looks quite nice, I think we cannot count on it being present. Any advice here would be welcome. The KAME patch seems to *replace* the old interface by the new one, which is OK for a patch but would probably not be adequate if we want a single tree that will build on old platforms. Is the library support sufficiently stable that Debian would ship with IPv6 support in rsync if it was enabled? Are you confident in supporting it? When I've enabled ipv6 interfaces on a Woody box I found a disturbing number of things broke, most importantly ssh. I'm sure that will improve. -- Martin
On Mon, 13 Aug 2001, Martin Pool wrote:> One concern is that its configure.in tests whether the *build* machine > has IPv6 in the kernel, and uses that as apparently a gating condition > on including IPv6 support. I can imagine distribution-builders who > may not have IPv6 in the build machine kernel, but still want to > enable it in binary packages. We could easily fix this.Check the Apache 2.0 configure, I think that one does some checks differently (haven't looked too deeply at it though).> rsync supports a fair number of unix-like platforms at the moment, > some of which are rather old or idiosyncratic. So, while the new > IPv6/v4 sockets API looks quite nice, I think we cannot count on it > being present. Any advice here would be welcome. The KAME patch > seems to *replace* the old interface by the new one, which is OK for a > patch but would probably not be adequate if we want a single tree that > will build on old platforms.Agreed.> Is the library support sufficiently stable that Debian would ship with > IPv6 support in rsync if it was enabled? Are you confident in > supporting it? When I've enabled ipv6 interfaces on a Woody box I > found a disturbing number of things broke, most importantly ssh. I'm > sure that will improve.I think Debian now ships with glibc 2.1.3, which has an IPv6 API. So far I've been using that library to compile Apache 2.0, and it seems to work. Network connectivity has always been fine too, via IPv6. So now we just need some apps.... wfms
Hi, I'm one of developers from KAME Project.> One concern is that its configure.in tests whether the *build* machine > has IPv6 in the kernel, and uses that as apparently a gating condition > on including IPv6 support. I can imagine distribution-builders who > may not have IPv6 in the build machine kernel, but still want to > enable it in binary packages. We could easily fix this.KAME patch can do it. When desginating --enable-ipv6/--disable-ipv6, configure.in forcingly enable/disable IPv6. Automatically detection works only when ommiting both of them.> rsync supports a fair number of unix-like platforms at the moment, > some of which are rather old or idiosyncratic. So, while the new > IPv6/v4 sockets API looks quite nice, I think we cannot count on it > being present. Any advice here would be welcome. The KAME patch > seems to *replace* the old interface by the new one, which is OK for a > patch but would probably not be adequate if we want a single tree that > will build on old platforms.One idea is providing compatible funcions, getaddrinfo()/getnameinfo() for IPv4 only environment in missing/ directry and detect their existence by AC_CHECK_FUNC. I think my tiny program is good example, please see the below: ftp://ftp.don.to/pub/wmmp3/wmmp3-0.2.tar.gz --- Munechika SUMIKAWA @ KAME Project
> rsync supports a fair number of unix-like platforms at the moment, > some of which are rather old or idiosyncratic. So, while the new > IPv6/v4 sockets API looks quite nice, I think we cannot count on it > being present. Any advice here would be welcome. The KAME patch > seems to *replace* the old interface by the new one, which is OK for a > patch but would probably not be adequate if we want a single tree that > will build on old platforms.sumikawa> One idea is providing compatible funcions, sumikawa> getaddrinfo()/getnameinfo() for IPv4 only environment in sumikawa> missing/ directry and detect their existence by sumikawa> AC_CHECK_FUNC. sumikawa> I think my tiny program is good example, please see the below: sumikawa> ftp://ftp.don.to/pub/wmmp3/wmmp3-0.2.tar.gz oops, this idea was already implemented. lib/getaddrinfo.c and lib/getnameinfo.c in the KAME patch are compatible functions. --- Munechika SUMIKAWA @ KAME Project
On 4 Dec 2001, SUMIKAWA Munechika <sumikawa@ebina.hitachi.co.jp> wrote:> client_addr(), client_name() always fails for IPv6 connection sice in > most of system, > sizeof(struct sockaddr_in) < sizeof(struct sockaddr) < sizeof(struct sockaddr_in6) > > you should use sockaddr_storage for getpeername(). here is the > patch.Yes, I'm aware of that. The problem is that the patch originally used would not compile on a significant number of platforms which are missing sockaddr_storage. Would it be sufficient for us to just read into a byte array large enough to hold all reasonable IPv6 encodings, and then cast it as appropriate? I have not had a chance to follow this idea through yet. Thankyou, -- Martin
In article <20011204164541.B8088@samba.org> (at Tue, 4 Dec 2001 16:45:43 +1100), Martin Pool <mbp@samba.org> says:> Would it be sufficient for us to just read into a byte array large > enough to hold all reasonable IPv6 encodings, and then cast it as > appropriate? I have not had a chance to follow this idea through yet.Put sockaddr_storage{} delaration in appropriate header in rsync distribution and enclose it with #ifdef ... #endif. Then use it on sockaddr_storage{}-missed platforms. Or, if we can give up ipv6 support on a such platform, just do #define sockaddr_storage sockaddr #define ss_family sa_family /* if needed */ or so if it has no sockaddr_storage{}. --yoshfuji