updated IPv6 patch

Russ Allbery rra at stanford.edu
Sun Mar 11 12:51:36 UTC 2001


Marco d'Itri <md at Linux.IT> writes:

> http://attila.bofh.it/~md/inn-20010301+IPv6-Md.diff.gz

> I finished merging the original patch and fixed the multiple sockets
> problem in rc.c.  I still have to add PRIORITISE_REMCONN support for
> multiple sockets, but the daemon works fine without it.  Identd support
> is still disabled.

This is excellent.  Thank you!  Some comments on FIXMEs:

--- inn-CURRENT-20010301/include/libinn.h       Thu Mar  1 11:00:42 2001
+++ inn6/include/libinn.h       Tue Mar  6 00:25:00 2001
@@ -371,6 +373,10 @@
 extern bool     fdreserve(int fdnum);
 extern FILE *   Fopen(const char *p, const char *type, int fd);
 extern int      Fclose(FILE *fp);
+/* FIXME this function really takes a struct sockaddr_storage, but the
+ * definition is in <sys/socket.h> which is not included by clibrary.h.
+ * What should I do?  Md */
+extern char *  inet_stoa(const void *ss);
 
 extern int      argify(char *line, char ***argvp);
 extern void     freeargify(char ***argvp);

Just add "struct sockaddr_storage;" to the top of libinn to predeclare it
as a struct.  That's safe; it doesn't conflict with any later definition.
You can then use the correct prototype.

(We may want to use another name for that function eventually, since it
isn't really an inet_ function; it could be either INET or INET6.  Maybe
something clearer and less abbreviated, like sprint_sockaddr or something?
Hm.  Need a good function name.  And since this function is new, we may as
well use a threadsafe interface from the start and pass in the buffer into
which to write the ASCII version and its length as arguments.  Although it
looks like that would complicate the patch, so maybe we should leave the
naming and the prototype for a later revision.)

--- inn-CURRENT-20010301/innd/chan.c    Thu Mar  1 11:00:44 2001
+++ inn6/innd/chan.c    Mon Mar  5 23:11:35 2001
@@ -53,6 +53,8 @@
 
 #define PRIORITISE_REMCONN
 #ifdef PRIORITISE_REMCONN
+/* FIXME I don't fully understand this code.
+ * Should these become arrays too? Md */
 static int     CHANrcfd;
 static CHANNEL *CHANrc;
 #endif /* PRIORITISE_REMCONN */

Yes.  Those need to become arrays as well.  The "remconn" is the listening
socket where new connections come in on; the purpose of that code is to
give priority to new incoming connections so that we get them set up and
send an initial response as fast as possible.  With IPv6, we'll have two
listening sockets, and therefore those need to become arrays, all of which
are checked.

--- inn-CURRENT-20010301/innd/inndstart.c       Thu Mar  1 11:00:45 2001
+++ inn6/innd/inndstart.c       Tue Mar  6 02:21:52 2001
@@ -120,12 +131,22 @@
 
     /* Check for a bind address specified in inn.conf.  "any" or "all" will
        cause inndstart to bind to INADDR_ANY. */
+    /* all and any are checked by lib/getconfig.c.
+     * Are the tests really needed?  -- Md */
     address.s_addr = htonl(INADDR_ANY);
     p = innconf->bindaddress;
     if (p && !EQ(p, "all") && !EQ(p, "any")) {
         if (!inet_aton(p, &address))
             die("invalid bindaddress in inn.conf (%s)", p);
     }

I was being paranoid because this is privileged code, and I wasn't sure
that getconfig.c did all the appropriate checks.  They're probably not
strictly necessary, but they don't hurt.

> TODO:
> - nnrpd -D
> - innd without inndstart

I actually have no problems with always using inndstart.  The alternative
is to put the setup code into some sort of shared function used by both
innd and inndstart, but I can't see any real drawbacks to just requiring
people to always use inndstart... maybe because if one has multiple builds
of innd with different names, one would then need multiple builds of
inndstart?  I guess it could be more annoying for some really odd
configurations.

The patch looks fine so far; I'm willing to throw it in when you think
it's ready.  I can see stuff that I want to fiddle with (mostly breaking a
lot of that #ifdef'd code out into separate functions to reduce the amount
of conditional code clutter), but that can all easily happen at our
leisure since it's cleanup kind of stuff.

-- 
Russ Allbery (rra at stanford.edu)             <http://www.eyrie.org/~eagle/>


More information about the inn-workers mailing list