On Thu, Sep 27, 2007 at 11:39:03AM +0000, [EMAIL PROTECTED] wrote:
> Bonjour,
> 
> Le 26.09.2007 19:16, Pierre Habouzit a écrit  :
> >   Je ne sais pas quelles sont les conditions d'utilisation du programme,
> > donc il est difficile de valider quoi que ce soit. Il y a mille raisons
> > pour lesquelles ça a l'air d'être trié (nscd notamment). Mais:
> >
> >   (1) la rule 9 est à propos des plus longs préfixes, or vu que la
> >       différence entre 165 et 166 est uniquement sur les deux derniers
> >       bits, le test est tout simplement idiot.
> 
> Mon test est probablement idiot, mais il met en évidence un comportement que
> j'ai sur plusieurs dizaines de serveurs et que j'essaye tant bien que mal de
> comprendre depuis plusieurs jours. Avant de venir passer pour un âne sur une
> liste debian-devel archivée sur internet (ce qui n'était pas franchement mon
> rêve je dois bien te l'avouer ;-) ), j'ai parlé du problème à un ami qui a pu 
> le
> reproduire sur ses propres serveurs en Debian etch.

  Disons que la règle 9 met en tete les adresses qui partagent le plus
long préfixe possible avec l'ip de la machine locale. Donc un test où la
variation du préfixe n'est sensible que sur les deux derniers bits
n'aura du sens que si le test est fait sur l'une des deux machines
concernées. Voilà pourquoi le test est mauvais.


> De plus si j'applique ce patch à la glibc 2.3.6 [1], je n'ai plus le problème 
> :
> --- glibc-backup/sysdeps/posix/getaddrinfo.c  2005-10-16 12:15:30.000000000 
> +0200
> +++ glibc-2.3.6/sysdeps/posix/getaddrinfo.c   2007-09-25 11:29:46.000000000 
> +0200
> @@ -1392,7 +1392,7 @@
>        int bit1 = 0;
>        int bit2 = 0;
> 
> -      if (a1->dest_addr->ai_family == PF_INET)
> +      if (a1->dest_addr->ai_family == PF_INET && 0)
>       {
>         assert (a1->source_addr.ss_family == PF_INET);
>         assert (a2->source_addr.ss_family == PF_INET);
> 
> 
> Or ce patch s'applique pile ici dans la fonction getaddrinfo de la glibc 
> 2.3.6 :
>   /* Rule 9: Use longest matching prefix.  */
>   if (a1->got_source_addr
>       && a1->dest_addr->ai_family == a2->dest_addr->ai_family)
>     {
>       int bit1 = 0;
>       int bit2 = 0;
> 
>       if (a1->dest_addr->ai_family == PF_INET)
>       {
>         assert (a1->source_addr.ss_family == PF_INET);
>         assert (a2->source_addr.ss_family == PF_INET);

  Okay bah en effet, le code de tri de la rule 9 est présent depuis bien
plus de temps que ce que Uli dit p/r à la rfc 3484. Aurélien a fait un
patch qui au lien de mettre && 0 à cet endroit, utilise un réglage de
gai.conf pour ce faire, le patch est attaché, et devrait du coup sans
doute s'appliquer directement en glibc 2.3.X (en tout cas sans trop de
grosses difficultés).

  Avec le patch il suffit de mettre dans /etc/gai.conf: sortv4 no

  Désolé d'avoir été vite agacé donc, mais j'en ai un peu marre de me
faire taper dessus pour un changement de comportement de la glibc alors
que je suis qu'un des packagers, et pas l'upstream, donc j'ai tendance à
partir au 1/4 de tour sur ce problème.
-- 
·O·  Pierre Habouzit
··O                                                [EMAIL PROTECTED]
OOO                                                http://www.madism.org
2007-08-16  Aurelien Jarno  <[EMAIL PROTECTED]>

        * sysdeps/posix/getaddrinfo.c (gaiconf_reload_flag): Move
        to the top of the file. 
        (gaiconf_mtime): Likewise.
        (sortv4): New configuration variable.
        (gaiconf_init): Parse the sortv4 option in the configuration
        file.
        (rfc3484_sort): Ignore rule 9 for IPv4 adresses if sortv4
        is false.
        * posix/gai.conf: Add the new sortv4 option.


--- posix/gai.conf      2007-08-16 22:59:03.000000000 +0200
+++ posix/gai.conf      2007-08-16 22:58:48.000000000 +0200
@@ -15,6 +15,11 @@
 #    changed and if necessary reload.  This option should not really be
 #    used.  There are possible runtime problems.  The default is no.
 #
+# sortv4  <yes|no>
+#    If set to no, getaddrinfo(3) will ignore IPv4 adresses in rule 9.  See
+#    section 6 in RFC 3484.  The default is yes.  Setting this option to 
+#    no breaks conformance to RFC 3484.
+#
 # label   <mask>   <value>
 #    Add another rule to the RFC 3484 label table.  See section 2.1 in
 #    RFC 3484.  The default is:
--- sysdeps/posix/getaddrinfo.c 2007-08-16 23:02:34.000000000 +0200
+++ sysdeps/posix/getaddrinfo.c 2007-08-16 22:31:53.000000000 +0200
@@ -79,6 +79,16 @@
 # define UNIX_PATH_MAX  108
 #endif
 
+/* Nozero if we are supposed to reload the config file automatically
+   whenever it changed.  */
+static int gaiconf_reload_flag;
+
+/* Zero if we are supposed to ignore rule 9 for IPv4 addresses */
+static int gaiconf_sortv4_flag = 1;
+
+/* Last modification time.  */
+static struct timespec gaiconf_mtime;
+
 struct gaih_service
   {
     const char *name;
@@ -1344,7 +1354,7 @@
       int bit1 = 0;
       int bit2 = 0;
 
-      if (a1->dest_addr->ai_family == PF_INET)
+      if (a1->dest_addr->ai_family == PF_INET && gaiconf_sortv4_flag)
        {
          assert (a1->source_addr.ss_family == PF_INET);
          assert (a2->source_addr.ss_family == PF_INET);
@@ -1422,14 +1432,6 @@
 #define GAICONF_FNAME "/etc/gai.conf"
 
 
-/* Nozero if we are supposed to reload the config file automatically
-   whenever it changed.  */
-static int gaiconf_reload_flag;
-
-/* Last modification time.  */
-static struct timespec gaiconf_mtime;
-
-
 libc_freeres_fn(fini)
 {
   if (labels != default_labels)
@@ -1608,6 +1610,8 @@
            case 6:
              if (strcmp (cmd, "reload") == 0)
                gaiconf_reload_flag = strcmp (val1, "yes") == 0;
+             else if (strcmp (cmd, "sortv4") == 0)
+               gaiconf_sortv4_flag = strcmp (val1, "no") != 0;
              break;
 
            case 10:

Attachment: pgpY99jpqXNzO.pgp
Description: PGP signature

Répondre à