Affichage réservations DHCP fixes très lent

[ipipip]

Bonjour,

j'utilise depuis plusieurs années IPCop sans problème.

A l'occasion d'un changement de disque dur, j'ai fait une fresh install à partir d'IPCop 1.4.20 (avec application du patch 1.4.21).

J'ai reconfiguré mon IPCop. Tout fonctionne normalement, exceptée la page d'admin du serveur DHCP : l'affichage des réservations d'adresses fixes met plusieurs minutes à se faire. Cela vaut aussi pour la modification/l'ajout d'adresses fixes.
Au bout de nombreuses minutes, l'affichage/ajout/modification aboutit, mais c'est très long et donc inutilisable... (Je me vois contraint d'apporter les modifications à la main via ssh (dans /var/ipcop), ce qui n'est pas très pratique...)

Je n'ai rien trouvé de spécial dans les logs...

Est-ce que quelqu'un a déjà eu ce problème et l'a résolu?

Merci par avance.

[olivier.s]

oui
j'ai mis le lissage de traffic trop bas
et ca ma fait ce genre de truc: admin tres lent, page admin introuvable etc..
alors que ca continue de marcher sans pb en ssh et autre

[ipipip]

Merci pour l'info.

Cependant, dans mon cas, le lissage de traffic n'est pas en fonction, et cela ne concerne que la page de réservation des adresses fixes DHCP (je n'ai pas de problème de lenteur d'affichage pour les autres pages de l'interface d'admin)...

[Gesp]

Est-ce que tu peux m'envoyer les fichiers sous /var/ipcop/dhcp dans un message privé.
Pour créer un tar.gz avec tous ces fichiers :

Code: Tout sélectionner

tar cvzf /tmp/slow-dhcp.tar.gz /var/ipcop/dhcp

Tu n'es pas le seul à avoir eu ce problème mais nous n'arrivons pas à le reproduire.
Ce serait la première étape pour comprendre ce qu'il se passe

[ipipip]

Je peux t'envoyer les fichiers de configuration mais ils n'ont rien de bien spécial en fait...

En revanche, j'ai regardé d'un peu plus près : j'ai mis des logs dans le dhcp.cgi pour essayer de cibler un peu le problème.

Lorsque j'ajoute une adresse IP fixe, il y a un ralentissement au niveau de la boucle :

Code: Tout sélectionner

       
CHECK:foreach my $line (@current2) {
           my @temp = split(',', $line);
           if($dhcpsettings{'KEY2'} ne $key) {
      # same MAC is OK on different subnets. This test is not complete because
      # if IP are not inside a known subnet, I don't warn.
      # Also it may be needed to put duplicate fixed lease in their right subnet definition..
      foreach my $itf (@ITFs) {
          my $scoped = &General::IpInSubnet($dhcpsettings{'FIX_ADDR'},
                    $netsettings{"${itf}_NETADDRESS"},
                    $netsettings{"${itf}_NETMASK"}) &&
                    $dhcpsettings{"ENABLE_${itf}"} eq 'on';
          if ( $scoped &&
         (lc($dhcpsettings{'FIX_MAC'}) eq lc($temp[0])) &&
         &General::IpInSubnet($temp[1],
                $netsettings{"${itf}_NETADDRESS"},
                $netsettings{"${itf}_NETMASK"})) {
         $errormessage = "$Lang::tr{'mac address in use'} $dhcpsettings{'FIX_MAC'}";
         last CHECK;
          }
      }
       }
       $key++;
   }


En regardant un peu, je me demande si le problème ne viendrait pas du fait que je n'utilise pas l'interface BLEUE (seulement VERTE et ROUGE).
J'ai l'impression que itf contient en particulier des valeurs vierges (interf. bleue(?)) et que l'appel à IpInSubnet avec ces valeurs bloquent 30s avant de rendre la main (le test "on" n'étant pas fait au préalable de l'appel)...

Nota : plus on rajoute d'IP fixes, plus on amplifie le problème car on repasse + de fois par ce genre d'appel.

-> un avis?

[Gesp]

Si tu as vu juste, cela doit être corrigé dans cette version
http://g.esp@free.fr/download/dhcp.cgi

Peux-tu vérifier cela?

Le diff est le suivant

Code: Tout sélectionner

diff -u -r1.14.2.99 dhcp.cgi
--- html/cgi-bin/dhcp.cgi   16 Aug 2007 22:50:57 -0000   1.14.2.99
+++ html/cgi-bin/dhcp.cgi   13 Sep 2008 08:25:57 -0000
@@ -54,7 +54,17 @@
          .'array of {(,| |boolean|((un)?signed )?integer (8|16|32)|ip-address)+}';

&Header::showhttpheaders();
-our @ITFs=('GREEN','BLUE');
+
+# Read Ipcop settings
+&General::readhash("${General::swroot}/ethernet/settings", \%netsettings);
+&General::readhash("${General::swroot}/main/settings", \%mainsettings);
+&General::readhash("${General::swroot}/time/settings", \%timesettings);
+
+# page is very slow if we probe IpInSubnet for BLUE and BLUE not set
+our @ITFs=('GREEN');
+if ( $netsettings{'CONFIG_TYPE'} =~ /^(4|5|6|7)$/ ) {
+   @ITFs=('GREEN','BLUE');
+}

#Settings1 for the first screen box
foreach my $itf (@ITFs) {
@@ -106,11 +116,6 @@
     unshift (@nosaved, "ADVOPT_SCOPE_${itf}");
}

-# Read Ipcop settings
-&General::readhash("${General::swroot}/ethernet/settings", \%netsettings);
-&General::readhash("${General::swroot}/main/settings", \%mainsettings);
-&General::readhash("${General::swroot}/time/settings", \%timesettings);
-
#Get GUI values
&Header::getcgihash(\%dhcpsettings);


[alomamabobo]

Bonjour,
utilisateur d'IPCop depuis un bout de temps je suis confronté au même problème que ipipip.

J'ai essayé 2 configs complètement différentes niveau hardware : 1 IBM PIV, HP PIV dual core.
Les tests ont étés fait avec des cartes réseau différentes (type realtek, 3c905, Dlink 503, Intel 100 intégrée). Quelque soit le matériel le problème est le même.
Pour la config IPCop: Green+Red static, tests effectués sans addons (en production j'ai Zerina qui marche très bien entre les 2 IPCop).

La chose bizarre: sur un autre site je n'ai absolument aucun problème avec le même type de PC (vieil IBM de bureau).

Les 2 sites ont des baux IP fixe (5 baux fixes par machine), le problème ne se pose que de mon coté. Il semble, comme le fait remarquer ipipip, que plus on ajoute de baux fixe plus le temps d'accès à la page augmente.

Ce n'est pas bloquant donc pas très grave (gestion par WinSCP) mais si mon post aide tant mieux

Bonne continuation et merci pour IPCop qui est simple à utiliser et très pratique

Note: le link vers free n'est plus valide et je ne sais pas si les modifications du script sont toujours d'actualités en version 1.4.21.

Edit: ayant un peu de temps j'ai édité le code de dhcp.cgi à la main (il doit y avoir une astuce pour utiliser un fichier .diff mais je ne l'ai pas ) ça marche très bien, la page s'affiche instantanément, merci
Je posterai si je trouve des bugs

[Gesp]

Merci de la confirmation

Pour appliquer le diff, il faut utiliser la commande patch (en étant au bon niveau de répertoire).

Le correctif n'est pas encore transmis au cvs. Je voulais d'abord inclure la modif en 2.0 mais j'ai eu à l'époque des difficultés d'installation, résolues depuis.
J'ai ralenti la mise à jour en v1.4 pour faire avancer la v2 plus vite.

Il devrait y avoir une nouvelle v1.4 en avril (je sais que j'ai déjà promis cela précédement mais les progrès en v2 ont été plus long que prévu à se mettre en place).

[alomamabobo]

Merci Gesp, la prochaine fois j'appliquerai le .diff dans les règles.
En tout cas tout marche correctement niveau DHCP : ajout d'une nouvelle adresse mac reconnue, ajout de réservation OK, les baux sont bien reconduis.

Bonne continuation dans le dev de la v2 (faisant souvent un tour sur les mailings list j'ai vu la somme de travail effectuée ).