Découverte réseau, SNMP et Wyses ...

Azlo · 2021-07-13 16:33:08

Bonjour à tous,

Avant tout je veux remercier tous ceux qui ont créé ces logiciels et tous ceux qui aident sur les forums/githubs et autre.
Même si vous avez l'impression de n'aider qu'une personne, beaucoup d'âmes silencieuse passent derrière et sont aidés à leur tour.

Voici mon problème, pour faire simple je ne parviens pas à faire remonter mes Wyses (client léger DELL) via la découverte réseau de FusionInventory.
J’ai écumé beaucoup de forum et de postes mais rien ne semble correspondre à mon souci.

Concernant la configuration de mes Wyses, aucun souci côté SNMP, le « snmpwalk » fonctionne bien depuis le serveur GLPI et remonte bien les infos dont j’ai besoin – c’est-à-dire le nom d’hôte et le numéro de série.
Pour infos, les Wyses ne fonctionne qu’en SNMP v1 :

# snmpwalk -v 1 -c macommunaute 192.168.105.72
iso.3.6.1.2.1.1.1.0 = STRING: "3010-T10  8.1_027"
iso.3.6.1.2.1.1.2.0 = OID: iso.3.6.1.4.1.714.1.2.6
iso.3.6.1.2.1.1.3.0 = Timeticks: (261361) 0:43:33.61
iso.3.6.1.2.1.1.4.0 = ""
iso.3.6.1.2.1.1.5.0 = STRING: "WT000000000000"
iso.3.6.1.2.1.1.6.0 = ""
iso.3.6.1.2.1.1.7.0 = INTEGER: 79
iso.3.6.1.2.1.2.1.0 = INTEGER: 2
etc …

J’ai deux souci :

Le premier, c’est qu’en utilisant l’interface web cette erreur apparait :
« L'agent demande une configuration qui lui a déjà été envoyée par le serveur. L'agent est susceptible d'avoir rencontré une erreur critique »

J’ai trouvé quelques posts à ce sujet mais rien qui m’a aidé.
J’ai eu beau retourner la configuration dans tous les sens, rien n’y a fait.
J’ai recréé/supprimé/mis à jour :
- Les Agents
- Les plages IP
- Les tâches
- Les rôles
- Les jobs

J’ai suivi ce qui était marqué ici :
htt ps://fo rum.g lpi-pr oject.org/view topic.php?i d=10760 7
Aucun changement.

Il ne s’agit pas non plus d’un soucis de mémoire PHP comme indiqué ici :
ht tps://gith ub.co m/fusioninven tory/fus ioninventory-for-g lpi/is sues/1735

Mais bon à la rigueur c’est pas trop grave encore car je pense que mon deuxième problème est plus important.
J’ai donc décidé de passer via la ligne de commande pour avoir plus d’infos sur ce qu’il se passe.

Je précise aussi que j’ai testé avec 3 modèles de Wyse, donc ce n’est pas spécifique à un modèle.

Dans l’exemple suivant, je scan entre les adresses 192.168.105.71 ET 192.168.105.73 car j’ai une Wyse en test à l’adresse 192.168.105.72 :
(Faites pas attention au timeout je sais qu’il est pas bon)

# fusioninventory-netdiscovery --debug --first 192.168.105.71 --last 192.168.105.73 --port 161 --community maCommunauté --timeout 3600 --entity MonEntité --threads 5 -i
[debug] scanning block 192.168.105.71-192.168.105.73
[debug] creating 3 worker threads
[debug] [thread 1] creation
[debug] [thread 2] creation
[debug] [thread 3] creation
[debug] [thread 1] #1, scanning 192.168.105.71
[debug] [thread 1] #1, - scanning 192.168.105.71:161 with SNMP, credentials 1: no result, The timeout value 3600 is out of range (1..60)
[debug] [thread 2] #2, scanning 192.168.105.72
[debug] [thread 2] #2, - scanning 192.168.105.72:161 with SNMP, credentials 1: no result, The timeout value 3600 is out of range (1..60)
[debug] [thread 3] #3, scanning 192.168.105.73
[debug] [thread 3] #3, - scanning 192.168.105.73:161 with SNMP, credentials 1: no result, The timeout value 3600 is out of range (1..60)
[debug] [thread 1] #1, - scanning 192.168.105.71 with netbios: no result
[debug] [thread 2] #2, - scanning 192.168.105.72 with netbios: no result
[debug] [thread 1] #1, - scanning 192.168.105.71 with echo ping: success
[debug] [thread 1] #1, - scanning 192.168.105.71 in arp table: no result
<?xml version="1.0" encoding="UTF-8" ?>
<REQUEST>
  <CONTENT>
    <DEVICE>
      <DNSHOSTNAME>192.168.105.71</DNSHOSTNAME>
      <IP>192.168.105.71</IP>
    </DEVICE>
    <MODULEVERSION>4.0</MODULEVERSION>
    <PROCESSNUMBER>1</PROCESSNUMBER>
  </CONTENT>
  <DEVICEID>foo</DEVICEID>
  <QUERY>NETDISCOVERY</QUERY>
</REQUEST>
[info] [thread 1] #1, Skipping inventory for 192.168.105.71 on not recognized device type
[debug] [thread 2] #2, - scanning 192.168.105.72 with echo ping: success
[debug] [thread 2] #2, - scanning 192.168.105.72 in arp table: no result
<?xml version="1.0" encoding="UTF-8" ?>
<REQUEST>
  <CONTENT>
    <DEVICE>
      <DNSHOSTNAME>192.168.105.72</DNSHOSTNAME>
      <IP>192.168.105.72</IP>
    </DEVICE>
    <MODULEVERSION>4.0</MODULEVERSION>
    <PROCESSNUMBER>1</PROCESSNUMBER>
  </CONTENT>
  <DEVICEID>foo</DEVICEID>
  <QUERY>NETDISCOVERY</QUERY>
</REQUEST>
[info] [thread 2] #2, Skipping inventory for 192.168.105.72 on not recognized device type
[debug] [thread 2] termination
[debug] [thread 1] termination
[debug] [thread 3] #3, - scanning 192.168.105.73 with netbios: no result
[debug] [thread 3] #3, - scanning 192.168.105.73 with echo ping: no result
[debug] [thread 3] #3, - scanning 192.168.105.73 in arp table: no result
[debug] [thread 3] termination
[debug] All netdiscovery threads terminated

Au moins il détecte bien le périphérique, il sait qu’il y a quelques chose sur cette adresse.
J’ai toutes mes imprimantes et switchs qui sont remontés sans soucis aussi, donc j’imagine que la configuration de base est pas mal.

Et là contrairement à ce que j’ai pu voir sur d’autre forums où les gens ils ont plein d’infos de référencées dans les parties XML. Moi j’ai rien, juste l’adresse IP.

L’OID du hostname est commune à tout le monde de ce que j’ai vu => 1.3.6.1.2.1.1.5.0, et quand je tape dessus sur un Wyse j’ai bien un WT’trucmachin’ qui remonte.
Comment cela se fait-ce ? Keskispasse ? Oukilé mon hostname (le minimum) ?

Tout ceci suivi du « Skipping inventory for 192.168.105.72 on not recognized device type », normal vu que y’a rien dans le XML (enfin je crois comprendre que c’est ça).

Du coup dans l’interface Web dans les imports refusés j’ai ça ? :

Après s’il sont refusés c’est pas bien grave faudra juste que je modifie mes règles, mais j’aimerais qu’on remonte le nom d’hôte et non pas le début d’une adresse IP, sinon pas d’unicité au niveau de l’information (la base d’une BDD en fait).

J’ai enquêté un peu partout et j’ai appris l’existence de ce fichier :

/usr/share/fusioninventory/lib/FusionInventory/Agent/SNMP/Device.pm

Je n’y connais rien du tout en Perl, je comprend pas tout ce qu’il se passe mais j’ai quand même rajouté ma ligne dans la fonction « setSerial », j’me dis que ça servira (j’espère juste que ça dépend pas d’une autre info ailleurs) :

sub setSerial {
    my ($self) = @_;

    my $serial =
        # First try MIB Support mechanism
        $self->getSerialByMibSupport()                         ||
        # Entity-MIB::entPhysicalSerialNum
        $self->{snmp}->get_first('.1.3.6.1.2.1.47.1.1.1.1.11') ||
        # Printer-MIB::prtGeneralSerialNumber
        $self->{snmp}->get_first('.1.3.6.1.2.1.43.5.1.1.17');

    if ( not defined $serial ) {
        # vendor specific OIDs
        my @oids = (
            '.1.3.6.1.4.1.2636.3.1.3.0',             # Juniper-MIB
            '.1.3.6.1.4.1.248.14.1.1.9.1.10.1',      # Hirschman MIB
            '.1.3.6.1.4.1.253.8.53.3.2.1.3.1',       # Xerox-MIB
            '.1.3.6.1.4.1.367.3.2.1.2.1.4.0',        # Ricoh-MIB
            '.1.3.6.1.4.1.641.2.1.2.1.6.1',          # Lexmark-MIB
            '.1.3.6.1.4.1.1602.1.2.1.4.0',           # Canon-MIB
            '.1.3.6.1.4.1.2435.2.3.9.4.2.1.5.5.1.0', # Brother-MIB
            '.1.3.6.1.4.1.318.1.1.4.1.5.0',          # MasterSwitch-MIB
            '.1.3.6.1.4.1.6027.3.8.1.1.5.0',         # F10-C-SERIES-CHASSIS-MIB
            '.1.3.6.1.4.1.6027.3.10.1.2.2.1.12.1',   # FORCE10-SMI
            '.1.3.6.1.4.1.3417.2.11.1.4.0',          # BLUECOAT-SG-PROXY-MIB
            '.1.3.6.1.4.1.232.2.2.2.1.0',            # CPQSINFO-MIB
            '.1.3.6.1.4.1.232.11.2.10.3.0',          # CPQHOST-MIB
            '.1.3.6.1.4.1.714.1.2.6.2.1.0',          # Wyse-MIB
        );

J’ai également vu ce fichier :

/usr/share/fusioninventory/sysobject.ids

Même si je sais que ce n’est pas de là que vient le problème (sinon j’aurais eu des remontés dans les imprimantes j’imagine), j’ai modifié la ligne :

714     Wyse    PRINTER

En :

714     Wyse    COMPUTER

Et enfin ce fichier, je pense que c’est là que mon information n’est pas prise, mais comme je l’ai dis plus haut, je n’y connais rien en Perl alors …. :

/sur/bin/fusioninventory-netdiscovery

J’imagine que c’est la fonction « send » qui doit définir la variable $device qui est refusée un peu plus loin ce qui donne le fameux :
“Skipping inventory for $ip on not recognized device type”

Voilà, je pense que j’ai tout dit, j’ai vu plusieurs personne sur le net pour qui il n’y avait pas de problème avec les Wyses, qu’elles remontaient bien et tout donc j’imagine qu’il ne devrait pas avoir besoin de toucher au code, mais moi impossible.
Je fais sûrement quelque chose de travers mais je ne vois pas quoi.

gbougard · 2021-07-21 11:16:13

Salut Azlo,

déjà, il faut savoir que l'inventaire ordinateur par SNMP n'est absolument pas supporté. Donc si tu veux quand même avoir un inventaire SNMP de tes Wyses, il faudra accepter qu'ils passent dans les équipements réseaux et donc créer une ligne dans ton sysobject.ids du genre:

714.1.2	Wyse	NETWORKING

et en faisant bien attention d'utiliser un seul caractère tabulation entre les champs.

Sur la modification du fichier "/usr/share/fusioninventory/lib/FusionInventory/Agent/SNMP/Device.pm", c'est la méthode old school et dangereuse que tu tentes. A priori ça devrait marcher mais il aurait été plus judicieux de créer un "plugin" dédié dans le dossier "SNMP/MibSupport".

Si ça n'aide pas, peux-tu ajouter un niveau de debug dans l'exécution de ta commande fusioninventory-netdiscovery en rajoutant un "--debug" ?

gbougard · 2021-07-23 13:12:34

Sinon, sur la base des infos trouvées ici et là, j'ai préparé un module dédié pour l'agent glpi dans une branche dédiée.
Tu peux télécharger le fichier WyseThinOS.pm et le copier dans le sous-dossier FusionInventory/Agent/SNMP/MibSupport dans ton installation de l'agent FusionInventory (l'agent GLPI et l'agent FusionInventory 2.6 sont compatibles pour le support de ces modules).
Le module tente de récupérer le numéro de série, le modèle et la version de ThinOS notamment.

Azlo · 2021-08-03 14:13:08

gbougard, merci beaucoup de ta réponse !
Désolé du temps de réponse, j'ai pas pu retravailler dessus avant cette semaine.

gbougard wrote:

Salut Azlo,
déjà, il faut savoir que l'inventaire ordinateur par SNMP n'est absolument pas supporté.

Ok, donc c'est surtout pour tout ce qui est routeur, switch borne wi-fi etc ..., mais j'en fais une utilisation "détourné" pour remonter mes Wyses si j'ai bien compris ?

gbougard wrote:

Donc si tu veux quand même avoir un inventaire SNMP de tes Wyses, il faudra accepter qu'ils passent dans les équipements réseaux et donc créer une ligne dans ton sysobject.ids du genre:
714.1.2	Wyse	NETWORKING

Pourtant dans le "sysobject.ids" il existe bien un champ "COMPUTER", ne sera-t-il pas placé dans "Parc > Ordinateurs" ?
Sinon peu importe, tant que je peux les inventorier.

gbougard wrote:

et en faisant bien attention d'utiliser un seul caractère tabulation entre les champs.

Oui j'avais remarqué la syntaxe particulière

gbougard wrote:

Si ça n'aide pas, peux-tu ajouter un niveau de debug dans l'exécution de ta commande fusioninventory-netdiscovery en rajoutant un "--debug" ?

Tu l'as peut-être vu suite à ton deuxième post mais j'ai déjà mis le "--debug" dans mes commandes.

gbougard wrote:

Sur la modification du fichier "/usr/share/fusioninventory/lib/FusionInventory/Agent/SNMP/Device.pm", c'est la méthode old school et dangereuse que tu tentes. A priori ça devrait marcher mais il aurait été plus judicieux de créer un "plugin" dédié dans le dossier "SNMP/MibSupport".

gbougard wrote:

Sinon, sur la base des infos trouvées ici et là, j'ai préparé un module dédié pour l'agent glpi dans une branche dédiée.
Tu peux télécharger le fichier WyseThinOS.pm et le copier dans le sous-dossier FusionInventory/Agent/SNMP/MibSupport dans ton installation de l'agent FusionInventory (l'agent GLPI et l'agent FusionInventory 2.6 sont compatibles pour le support de ces modules).
Le module tente de récupérer le numéro de série, le modèle et la version de ThinOS notamment.

Je te remercie infiniment pour ce module il va m'être extrêmement utile ! J'ai vu une sorte de modèle en commentaire dans un des fichier mais je ne pense pas que j'aurais su le faire tout seul.

Sinon, j'ai pu revoir un peu mes commandes et j'ai fais un bêtise bien débile.
Dans mon premier post je cite :

Azlo wrote:

(Faites pas attention au timeout je sais qu’il est pas bon)

Et bah si fallait faire attention, c'est ce fameux timeout qui bloquait tout !
La machine n'avait pas le temps de répondre que mon serveur considérait le timeout vu que je l'avais mal saisi.

# fusioninventory-netdiscovery --debug --first 192.168.105.8 --last 192.168.105.8 --port 161 --community macommunauté --timeout 7 --entity monentité --threads 5
[debug] scanning block 192.168.105.8-192.168.105.8
[debug] creating 1 worker threads
[debug] [thread 1] creation
[debug] [thread 1] #1, scanning 192.168.105.8
[debug] [thread 1] #1, full match for sysobjectID .1.3.6.1.4.1.714.1.2.6 in database
[debug] [thread 1] #1, - scanning 192.168.105.8:161 with SNMP, credentials 1: success
[debug] [thread 1] #1, - scanning 192.168.105.8 with netbios: no result
[debug] [thread 1] #1, - scanning 192.168.105.8 with echo ping: success
[debug] [thread 1] #1, - scanning 192.168.105.8 in arp table: no result
<?xml version="1.0" encoding="UTF-8" ?>
<REQUEST>
  <CONTENT>
    <DEVICE>
      <AUTHSNMP>1</AUTHSNMP>
      <DESCRIPTION>C10  7.1_122</DESCRIPTION>
      <DNSHOSTNAME>192.168.105.8</DNSHOSTNAME>
      <IP>192.168.105.8</IP>
      <IPS>
        <IP>192.168.105.8</IP>
      </IPS>
      <MAC>00:80:64:bd:bd:39</MAC>
      <MANUFACTURER>Dell</MANUFACTURER>
      <MODEL>Wyse C10</MODEL>
      <SERIAL>2ELDMC01500</SERIAL>
      <SNMPHOSTNAME>WT008064bdbd39</SNMPHOSTNAME>
      <TYPE>NETWORKING</TYPE>
      <UPTIME>7 days, 02:58:55.04</UPTIME>
    </DEVICE>
    <MODULEVERSION>4.0</MODULEVERSION>
    <PROCESSNUMBER>1</PROCESSNUMBER>
  </CONTENT>
  <DEVICEID>foo</DEVICEID>
  <QUERY>NETDISCOVERY</QUERY>
</REQUEST>
[debug] [thread 1] termination
[debug] All netdiscovery threads terminated

Donc là j'ai bien toutes les infos qui remontent.
MAIS ... (bah oui y'a un "mais" évidemment) ... Mais lorsque je rajoute l'argument "-i" qui permet d'inventorier derrière la découverte, une erreur SNMP apparaît :

# fusioninventory-netdiscovery --debug --first 192.168.105.8 --last 192.168.105.8 --port 161 --community macommunauté--timeout 7 --entity monentité --threads 5 -i
[debug] scanning block 192.168.105.8-192.168.105.8
[debug] creating 1 worker threads
[debug] [thread 1] creation
[debug] [thread 1] #1, scanning 192.168.105.8
[debug] [thread 1] #1, full match for sysobjectID .1.3.6.1.4.1.714.1.2.6 in database
[debug] [thread 1] #1, - scanning 192.168.105.8:161 with SNMP, credentials 1: success
[debug] [thread 1] #1, - scanning 192.168.105.8 with netbios: no result
[debug] [thread 1] #1, - scanning 192.168.105.8 with echo ping: success
[debug] [thread 1] #1, - scanning 192.168.105.8 in arp table: no result
<?xml version="1.0" encoding="UTF-8" ?>
<REQUEST>
  <CONTENT>
    <DEVICE>
      <AUTHSNMP>1</AUTHSNMP>
      <DESCRIPTION>C10  7.1_122</DESCRIPTION>
      <DNSHOSTNAME>192.168.105.8</DNSHOSTNAME>
      <IP>192.168.105.8</IP>
      <IPS>
        <IP>192.168.105.8</IP>
      </IPS>
      <MAC>00:80:64:bd:bd:39</MAC>
      <MANUFACTURER>Dell</MANUFACTURER>
      <MODEL>Wyse C10</MODEL>
      <SERIAL>2ELDMC01500</SERIAL>
      <SNMPHOSTNAME>WT008064bdbd39</SNMPHOSTNAME>
      <TYPE>NETWORKING</TYPE>
      <UPTIME>7 days, 03:07:42.77</UPTIME>
    </DEVICE>
    <MODULEVERSION>4.0</MODULEVERSION>
    <PROCESSNUMBER>1</PROCESSNUMBER>
  </CONTENT>
  <DEVICEID>foo</DEVICEID>
  <QUERY>NETDISCOVERY</QUERY>
</REQUEST>
[debug] creating 1 worker threads
[debug] 2 really running: [1 2]
[debug] 1 started: [2]
[debug] [thread 2] creation
[debug] [thread 2] #1, scanning 0: 192.168.105.8 on port ARRAY(0x7feb456cc3b8)
[error] [thread 2] #1, [thread 2] SNMP communication error: Unable to resolve the UDP/IPv4 service name "ARRAY(0x7feb456cc550)"
<?xml version="1.0" encoding="UTF-8" ?>
<REQUEST>
  <CONTENT>
    <DEVICE>
      <ERROR>
        <ID>0</ID>
        <MESSAGE>SNMP communication error: Unable to resolve the UDP/IPv4 service name &quot;ARRAY(0x7feb456cc550)&quot;</MESSAGE>
      </ERROR>
    </DEVICE>
    <MODULEVERSION>4.0</MODULEVERSION>
    <PROCESSNUMBER>1</PROCESSNUMBER>
  </CONTENT>
  <DEVICEID>foo</DEVICEID>
  <QUERY>SNMPQUERY</QUERY>
</REQUEST>
[debug] [thread 2] termination
[debug] [thread 1] termination
[debug] All netdiscovery threads terminated

Je vous épargne les étapes mon diagnostic mais en gros c'est comme si la variable dans la tableau contenant le protocole à utiliser pour la requête snmp n'était pas initialisé (ou un truc du genre je comprends pas bien).
Par conséquent snmp ne comprend pas ce qu'on lui envoi en argument, d'où l'erreur.

J'ai donc modifié ma commande pour ajouter le protocole en argument :

fusioninventory-netdiscovery --debug --first 192.168.105.8 --last 192.168.105.8 --port 161 --protocol udp/ipv4 --community macommunauté --timeout 7 --entity monentité --threads 5 -i

J'ai ensuite modifié le fichier "/usr/share/fusioninventory/lib/FusionInventory/Agent/Task/NetInventory.pm" pour faire apparaître mon propre debuggage :

sub _queryDevice {
    my ($self, $params) = @_;

    my $credentials = $params->{credentials};
    my $device      = $params->{device};
    my $logger      = $self->{logger};
    my $id          = threads->tid();
    $logger->{prefix} = "[thread $id] $params->{jid}, ";
    $logger->debug(
        "scanning $device->{ID}: $device->{IP}" .
        ( $device->{PORT} ? ' on port ' . $device->{PORT} : '' ) .
        ( $device->{PROTOCOL} ? ' via ' . $device->{PROTOCOL} : '' )
    );
        #Ici mon debug custom
        $self->{logger}->debug("Le debug custom d'Azlo ===>>> PORT : $device->{PORT} ET PROTOCOL : $device->{PROTOCOL}");

Et voici le résultat lors de la même commande :

[debug] creating 1 worker threads
[debug] 2 really running: [1 2]
[debug] 1 started: [2]
[debug] [thread 2] creation
[debug] [thread 2] #1, scanning 0: 192.168.105.8 on port ARRAY(0x7f09496cb340) via ARRAY(0x7f09496cb460)
[debug] [thread 2] #1, Le debug custom d'Azlo ===>>> PORT : ARRAY(0x7f09496cb238) ET PROTOCOL : ARRAY(0x7f09496cb2b0)
[error] [thread 2] #1, [thread 2] SNMP communication error: The transport domain "ARRAY(0x7f09496cb538)" is unknown

J'ai essayé de mettre d'autres protocoles pour voir mais j'ai toujours ces "ARRAY(0x9999999999)" qui apparaissent.

Bon, ptête que je creuse trop et que c'est un autre truc très bête mais là je ne vois pas.

Dans tous les cas je continue de chercher, je finirais bien par les inventorier ces satanés Wyse !

EDIT : Ah oui et j'ai toujours l'erreur « L'agent demande une configuration qui lui a déjà été envoyée par le serveur. L'agent est susceptible d'avoir rencontré une erreur critique » dans l'interface graphique, je sais pas si c'est dû au même problème.

Last edited by Azlo (2021-08-03 14:15:01)

gbougard · 2021-08-03 18:19:44

Salut Azlo,

le support COMPUTER dans la découverte et l'inventaire réseau était une vieille envie mais n'a jamais été concrétisée et ne le sera probablement jamais comme ce protocole n'est absolument pas adapté à l'inventaire d'ordinateur (uniquement parce que personne ne s'est donné suffisament de mal pour fournir une implémentation solide pour ce qu'on entend par inventaire ordinateur).

Donc avoir tes Wyses comme équipement réseau restera un "petit" détournement sémantique mais sans conséquence pour tes besoins.

On peut effectivement indiquer COMPUTER dans le sysobject.ids, mais la valeur n'est pas supportée dans le plugin FusionInventory.

Content de voir que tu aies corrigé le problème en ayant un timeout adapté.

Je suis un peu moins content que tu aies trouvé ce bogue sur le port avec l'option "--inventory" ;-) mais ce n'est pas bien méchant. En tout cas, dans ton cas, ça ne sert à rien d'indiquer un port si c'est pour utiliser le port par défaut. Donc supprime simplement l'option de ta ligne de commande et pareil pour le protocole.

En fait, tu dois être la première personne à avoir tenter cette expérience d'utiliser "--port" avec l'option "--inventory"... ça a au moins le mérite de mettre en évidence un bogue ;-) que je vais devoir corriger... même si personne n'utilisera jamais ces options :-D
Je corrigerai ça pour l'agent GLPI.

Azlo · 2021-08-04 17:42:59

gbougard wrote:

Salut Azlo,
le support COMPUTER dans la découverte et l'inventaire réseau était une vieille envie mais n'a jamais été concrétisée et ne le sera probablement jamais comme ce protocole n'est absolument pas adapté à l'inventaire d'ordinateur (uniquement parce que personne ne s'est donné suffisament de mal pour fournir une implémentation solide pour ce qu'on entend par inventaire ordinateur).
Donc avoir tes Wyses comme équipement réseau restera un "petit" détournement sémantique mais sans conséquence pour tes besoins.
On peut effectivement indiquer COMPUTER dans le sysobject.ids, mais la valeur n'est pas supportée dans le plugin FusionInventory.
Content de voir que tu aies corrigé le problème en ayant un timeout adapté.

Je vois, merci pour les infos, je laisse tout en "NETWORKING" alors.

gbougard wrote:

Je suis un peu moins content que tu aies trouvé ce bogue sur le port avec l'option "--inventory" ;-) mais ce n'est pas bien méchant. En tout cas, dans ton cas, ça ne sert à rien d'indiquer un port si c'est pour utiliser le port par défaut. Donc supprime simplement l'option de ta ligne de commande et pareil pour le protocole.
En fait, tu dois être la première personne à avoir tenter cette expérience d'utiliser "--port" avec l'option "--inventory"... ça a au moins le mérite de mettre en évidence un bogue ;-) que je vais devoir corriger... même si personne n'utilisera jamais ces options :-D
Je corrigerai ça pour l'agent GLPI.

Y'a peut-être eu quiproquo mais le fait que je mette l'option "--protocol" c'était juste pour tester ce que je pouvais faire, j'ai une erreur avec ou sans cette option, je préfère préciser.
Mais oui c'est sûr ça ne sert à rien de préciser l'option si on n'utilise pas IPV6 ou si on passe pas par TCP.

D'ailleurs au cas où j'ai tenté de mettre un

$device->{PORT} = "udp";

au cas où dans le fichier mais j'ai l'erreur

SNMP communication error: Unable to resolve the UDP/IPv4 service name "udp"

qui apparaît donc je ne sais pas ce qu'il attends dans cette variable.

Last edited by Azlo (2021-08-04 17:44:46)

gbougard · 2021-08-05 10:44:36

La valeur par défaut est simplement "161". Je me demande pourquoi tu t'es mis en tête d'y mettre "udp" qui est un protocole réseau et qui doit aller dans "$device->{PROTOCOL}".

Pour info, j'ai appliqué un patch sur l'agent GLPI qui corrige ce problème:
https://github.com/glpi-project/glpi-ag … a9c3073fa4

Tu peux le tester sur l'agent FusionInventory mais tu as juste à faire attention, la partie sur glpi-netdiscovery s'applique bien à fusioninventory-netdiscovery.

Azlo · 2021-08-12 16:12:18

Mais oui ! Exact je fais n'importe quoi, j'ai confondu les deux et c'est pour ça que je comprenais pas ton post.

Merci pour la correction, même si en effet elle n'était pas nécessaire et que y'a que moi qui l'utilisais comme tu l'a fais remarqué (quand ça fonctionne pas j'essaye toutes les options au cas où ).

Du coup "tout semble bien aller", ma commande scan les matériels par SNMP et fait l'inventaire... mais toujours rien qui remonte dans l'application ! Et aucune erreur nulle part.
N'est-ce pas censé inscrire le nouveau matériel en base de donnée ? surtout que je n'ai pas d'erreur alors je ne comprend pas très bien.
A moins que les règles de création rentrent en compte et ne font pas de retour dans le shell peut-être ?
J'ai tenté de supprimé un switch de la base pour le scanner via le shell et il n'est pas remonté non plus, il remonte seulement quand j'utilise l'interface graphique.

Cependant ! J'ai du mouvement dans l'interface graphique (qui est censé utiliser le même code que dans le shell j'imagine).
J'ai toujours l'erreur suivante :

2021-08-12 11:31:14	Erreur	L'agent demande une configuration qui lui a déjà été envoyée par le serveur. L'agent est susceptible d'avoir rencontré une erreur critique

Mais cette erreur arrive toujours en fin de parcours de ma tranche réseau, donc pas de grande incidence mais je le signal quand même.
De plus, j'ai une ligne qui apparaît à chaque appareil trouvé, là où avant ne n'avais qu'une ou deux ligne voire pas du tout :

2021-08-12 12:08:48	En cours d'exécution	Import refusé [ip]:192.168.104.6, [name]:192, [entities_id]:0
2021-08-12 12:08:48	En cours d'exécution	1 périphériques trouvés

Donc là on voit bien que l'import est refusé à cause des règles. Pas grave suffira de les changer/activer/modifier.
Ce qui m'inquiète c'est que dans "[name]" j'ai toujours "192", alors que je devrais avoir le nom d'hôte.

Le fichier "WyseThinOS.pm" que tu as codé n'était-il pas censé corrigé ça ? Ou peut-être sert-il d'intermédiaire ailleurs ? Désolé j'ai du mal à comprendre le flux de données ici.

Toutes mes Wyses semble donc pouvoir être importé mais avec un nom pas du tout parlant et sans aucune unicité.
(C'est quoi ce nom d'ailleurs ? il prend les trois premier caractère de l'adresse ip ?)

Quand il scan un switch ou un borne wi-fi en revanche, il me met bien le nom correctement.

Bref, y'a du mieux mais c'est pas encore ça. Je continue de triturer.

gbougard · 2021-08-13 13:33:51

Salut Azlo,

la première erreur peut arriver si tu as lancé entre temps un agent qui récupère une conf de tâche avant l'agent en cours le fasse lui même. C'est un erreur en principe exceptionnelle mais qui peut arriver donc lors de tests si tu mélanges les genres ;-) C'est pas bien grave tant que tu es en phase de test. Mais c'est plus gênant si tu as l'erreur en prod sans que tu aies rien fait par ailleurs. Mais généralement ça indique qu'un autre agent a probablement déjà fait le job. Est-ce que par hasard tu as plusieurs agents définis pour une même tâche ? C'est un point à vérifier peut-être et là il pourrait y avoir un problème d'accès concurrent aux tâches à effectuer.

Sur les imports refusés, déjà, tu devrais finir par les voir dans la page "matériels ignorés à l'import" dans le plugin fusion. N'hésites pas à nettoyer cette zone de temps en temps pour voir si tu as encore bcp de matériels ignorés.

Pour l'histoire du nom défini à "192", c'est un peu plus gênant. Dans le module que j'ai écrit, je ne gère pas spécifiquement le nom en lui-même, ce qui signifie que le nom est déterminé par la procédure standard du scan snmp. J'imagine qu'il trouve l'ip est qu'il considère "192" comme étant le nom d'hôte et "168.104.6" comme étant le domaine... ça devient clairement gênant pour avoir un nom d'équipement unique. Est-ce qu'au niveau de tes wyses tu as moyen de changer le nom justement ? et si oui, est-ce que le nom par défaut ne serait pas simplement l'ip... si c'est le cas, il te suffit peut-être de mettre à jour la conf de tes wyses pour qu'ils aient un nom défini et si possible unique. Sinon, il faudra déterminer pourquoi on arrive à cette situation. Eventuellement, si tu peux me fournir un walk snmp d'un de tes équipements Wyse, je pourrai peut-être identifier un autre problème. Pour faire un walk, il nous faut un format standard mais tout est expliqué là: snmpwalk in fusioninventory bug report

Pour info, je vais être en congès 2 semaines, donc si tu as du neuf, je n'y répondrais probablement pas avant la rentrée. Bon courage d'ici là ;-)

Azlo · 2021-08-13 16:29:22

gbougard wrote:

Salut Azlo,
la première erreur peut arriver si tu as lancé entre temps un agent qui récupère une conf de tâche avant l'agent en cours le fasse lui même. C'est un erreur en principe exceptionnelle mais qui peut arriver donc lors de tests si tu mélanges les genres ;-) C'est pas bien grave tant que tu es en phase de test. Mais c'est plus gênant si tu as l'erreur en prod sans que tu aies rien fait par ailleurs. Mais généralement ça indique qu'un autre agent a probablement déjà fait le job. Est-ce que par hasard tu as plusieurs agents définis pour une même tâche ? C'est un point à vérifier peut-être et là il pourrait y avoir un problème d'accès concurrent aux tâches à effectuer.

Ahh ok ok, donc oui j'avais deux agents qui scannaient la même plage. J'ai pris l'agent de mon propre PC et celui du serveur, c'était pour vérifier que l'un ne soit pas défaillant par rapport à l'autre. Le message n'était pas clair du tout pour moi, mais oui tout s'explique.
Mais en effet c'était pas important.

gbougard wrote:

Sur les imports refusés, déjà, tu devrais finir par les voir dans la page "matériels ignorés à l'import" dans le plugin fusion. N'hésites pas à nettoyer cette zone de temps en temps pour voir si tu as encore bcp de matériels ignorés.

Oui j'avais mis un screen de cette page dans mon premier post et j'ai juste du "192" partout ça n'a pas changé , je le vide régulièrement.
En parlant de log ce matin mon serveur était down, j'ai très vite compris que le disque était plein et avec un bon "du" j'ai vu qu'un fichier de log était énorme (20Go+). Je prends ça comme un bon signe parce qu'au moins il fait quelque chose par rapport à avant. Je fais un ptit "rm -rf /var/www/glpi/files/_log/pluginFusioninventory-tasks.log" de temps en temps et ca passe. Au passage ce log est pas intéressant, je sais pas s'il te serait utile ? Il ne semble contenir qu'un amas de requête vers mes wyses.

gbougard wrote:

Pour l'histoire du nom défini à "192", c'est un peu plus gênant. Dans le module que j'ai écrit, je ne gère pas spécifiquement le nom en lui-même, ce qui signifie que le nom est déterminé par la procédure standard du scan snmp. J'imagine qu'il trouve l'ip est qu'il considère "192" comme étant le nom d'hôte et "168.104.6" comme étant le domaine... ça devient clairement gênant pour avoir un nom d'équipement unique.

Oui tu en viens donc à la même conclusion que moi, et clairement c'est pas pratique. Mais c'est bizarre du coup car de ce que j'ai vu l'OID du hostname est universel à tous les matériels, pourquoi prendrait-il autre chose ?

gbougard wrote:

Est-ce qu'au niveau de tes wyses tu as moyen de changer le nom justement ? et si oui, est-ce que le nom par défaut ne serait pas simplement l'ip... si c'est le cas, il te suffit peut-être de mettre à jour la conf de tes wyses pour qu'ils aient un nom défini et si possible unique. Sinon, il faudra déterminer pourquoi on arrive à cette situation. Eventuellement, si tu peux me fournir un walk snmp d'un de tes équipements Wyse, je pourrai peut-être identifier un autre problème. Pour faire un walk, il nous faut un format standard mais tout est expliqué là: snmpwalk in fusioninventory bug report

Toutes les Wyse ont bien déjà un nom d'hôte que je vois très bien sur notre serveur DHCP par exemple. Il est aussi présent sur l'OID "1.3.6.1.2.1.1.5.0". Quand on fait un "netdiscovery" dans le shell il apparaît également sans soucis dans le XML qui est généré. Donc je pense bien que c'est un souci de transfert de données.

Ci-dessous le snmpwalk selon ton lien.
Au passage c'est bizarre - mais ça doit être les arguments de la commande qui changent ça - toutes les chaines de caractères passent en héxadécimal du coup. Je te met le même avec une commande "classique" pour voir la différence.

# snmpwalk -v 1 -c macommunauté -t 15 -Cc -On -Ox 192.168.105.9
.1.3.6.1.2.1.1.1.0 = Hex-STRING: 43 31 30 20 20 37 2E 31 5F 31 32 32
.1.3.6.1.2.1.1.2.0 = OID: .1.3.6.1.4.1.714.1.2.6
.1.3.6.1.2.1.1.3.0 = Timeticks: (244364686) 28 days, 6:47:26.86
.1.3.6.1.2.1.1.4.0 = ""
.1.3.6.1.2.1.1.5.0 = Hex-STRING: 57 54 30 30 38 30 36 34 62 64 31 62 32 30
.1.3.6.1.2.1.1.6.0 = ""
.1.3.6.1.2.1.1.7.0 = INTEGER: 79
.1.3.6.1.2.1.2.1.0 = INTEGER: 11
.1.3.6.1.2.1.2.2.1.1.1 = INTEGER: 1
.1.3.6.1.2.1.2.2.1.1.2 = INTEGER: 2
.1.3.6.1.2.1.2.2.1.1.3 = INTEGER: 3
.1.3.6.1.2.1.2.2.1.1.4 = INTEGER: 4
.1.3.6.1.2.1.2.2.1.1.5 = INTEGER: 5
.1.3.6.1.2.1.2.2.1.1.6 = INTEGER: 6
.1.3.6.1.2.1.2.2.1.1.7 = INTEGER: 7
.1.3.6.1.2.1.2.2.1.1.8 = INTEGER: 8
.1.3.6.1.2.1.2.2.1.1.9 = INTEGER: 9
.1.3.6.1.2.1.2.2.1.1.10 = INTEGER: 10
.1.3.6.1.2.1.2.2.1.1.11 = INTEGER: 11
.1.3.6.1.2.1.2.2.1.2.1 = Hex-STRING: 6C 6F 6F 70 30
.1.3.6.1.2.1.2.2.1.2.2 = Hex-STRING: 65 6E 65 74 30
.1.3.6.1.2.1.2.2.1.2.3 = Hex-STRING: 70 70 70 30
.1.3.6.1.2.1.2.2.1.2.4 = Hex-STRING: 70 70 70 31
.1.3.6.1.2.1.2.2.1.2.5 = Hex-STRING: 70 70 70 32
.1.3.6.1.2.1.2.2.1.2.6 = Hex-STRING: 70 70 70 33
.1.3.6.1.2.1.2.2.1.2.7 = Hex-STRING: 70 70 70 34
.1.3.6.1.2.1.2.2.1.2.8 = Hex-STRING: 70 70 70 35
.1.3.6.1.2.1.2.2.1.2.9 = Hex-STRING: 70 70 70 36
.1.3.6.1.2.1.2.2.1.2.10 = Hex-STRING: 70 70 70 37
.1.3.6.1.2.1.2.2.1.2.11 = Hex-STRING: 70 70 70 38
.1.3.6.1.2.1.2.2.1.3.1 = INTEGER: 24
.1.3.6.1.2.1.2.2.1.3.2 = INTEGER: 6
.1.3.6.1.2.1.2.2.1.3.3 = INTEGER: 23
.1.3.6.1.2.1.2.2.1.3.4 = INTEGER: 23
.1.3.6.1.2.1.2.2.1.3.5 = INTEGER: 23
.1.3.6.1.2.1.2.2.1.3.6 = INTEGER: 23
.1.3.6.1.2.1.2.2.1.3.7 = INTEGER: 23
.1.3.6.1.2.1.2.2.1.3.8 = INTEGER: 23
.1.3.6.1.2.1.2.2.1.3.9 = INTEGER: 23
.1.3.6.1.2.1.2.2.1.3.10 = INTEGER: 23
.1.3.6.1.2.1.2.2.1.3.11 = INTEGER: 23
.1.3.6.1.2.1.2.2.1.4.1 = INTEGER: 1200
.1.3.6.1.2.1.2.2.1.4.2 = INTEGER: 1500
.1.3.6.1.2.1.2.2.1.4.3 = INTEGER: 1400
.1.3.6.1.2.1.2.2.1.4.4 = INTEGER: 1400
.1.3.6.1.2.1.2.2.1.4.5 = INTEGER: 1400
.1.3.6.1.2.1.2.2.1.4.6 = INTEGER: 1400
.1.3.6.1.2.1.2.2.1.4.7 = INTEGER: 1400
.1.3.6.1.2.1.2.2.1.4.8 = INTEGER: 1300
.1.3.6.1.2.1.2.2.1.4.9 = INTEGER: 1300
.1.3.6.1.2.1.2.2.1.4.10 = INTEGER: 1300
.1.3.6.1.2.1.2.2.1.4.11 = INTEGER: 1300
.1.3.6.1.2.1.2.2.1.5.1 = Gauge32: 1
.1.3.6.1.2.1.2.2.1.5.2 = Gauge32: 1000000000
.1.3.6.1.2.1.2.2.1.5.3 = Gauge32: 9600
.1.3.6.1.2.1.2.2.1.5.4 = Gauge32: 9600
.1.3.6.1.2.1.2.2.1.5.5 = Gauge32: 9600
.1.3.6.1.2.1.2.2.1.5.6 = Gauge32: 9600
.1.3.6.1.2.1.2.2.1.5.7 = Gauge32: 0
.1.3.6.1.2.1.2.2.1.5.8 = Gauge32: 0
.1.3.6.1.2.1.2.2.1.5.9 = Gauge32: 0
.1.3.6.1.2.1.2.2.1.5.10 = Gauge32: 0
.1.3.6.1.2.1.2.2.1.5.11 = Gauge32: 0
.1.3.6.1.2.1.2.2.1.6.1 = Hex-STRING: 00 00 00 00 00 00
.1.3.6.1.2.1.2.2.1.6.2 = Hex-STRING: 00 80 64 BD 1B 20
.1.3.6.1.2.1.2.2.1.6.3 = Hex-STRING: 00 00 00 00 00 00
.1.3.6.1.2.1.2.2.1.6.4 = Hex-STRING: 00 00 00 00 00 00
.1.3.6.1.2.1.2.2.1.6.5 = Hex-STRING: 00 00 00 00 00 00
.1.3.6.1.2.1.2.2.1.6.6 = Hex-STRING: 00 00 00 00 00 00
.1.3.6.1.2.1.2.2.1.6.7 = Hex-STRING: 00 00 00 00 00 00
.1.3.6.1.2.1.2.2.1.6.8 = Hex-STRING: 00 00 00 00 00 00
.1.3.6.1.2.1.2.2.1.6.9 = Hex-STRING: 00 00 00 00 00 00
.1.3.6.1.2.1.2.2.1.6.10 = Hex-STRING: 00 00 00 00 00 00
.1.3.6.1.2.1.2.2.1.6.11 = Hex-STRING: 00 00 00 00 00 00
.1.3.6.1.2.1.2.2.1.7.1 = INTEGER: 2
.1.3.6.1.2.1.2.2.1.7.2 = INTEGER: 1
.1.3.6.1.2.1.2.2.1.7.3 = INTEGER: 2
.1.3.6.1.2.1.2.2.1.7.4 = INTEGER: 2
.1.3.6.1.2.1.2.2.1.7.5 = INTEGER: 2
.1.3.6.1.2.1.2.2.1.7.6 = INTEGER: 2
.1.3.6.1.2.1.2.2.1.7.7 = INTEGER: 2
.1.3.6.1.2.1.2.2.1.7.8 = INTEGER: 2
.1.3.6.1.2.1.2.2.1.7.9 = INTEGER: 2
.1.3.6.1.2.1.2.2.1.7.10 = INTEGER: 2
.1.3.6.1.2.1.2.2.1.7.11 = INTEGER: 2
.1.3.6.1.2.1.2.2.1.8.1 = INTEGER: 1
.1.3.6.1.2.1.2.2.1.8.2 = INTEGER: 1
.1.3.6.1.2.1.2.2.1.8.3 = INTEGER: 2
.1.3.6.1.2.1.2.2.1.8.4 = INTEGER: 2
.1.3.6.1.2.1.2.2.1.8.5 = INTEGER: 2
.1.3.6.1.2.1.2.2.1.8.6 = INTEGER: 2
.1.3.6.1.2.1.2.2.1.8.7 = INTEGER: 2
.1.3.6.1.2.1.2.2.1.8.8 = INTEGER: 2
.1.3.6.1.2.1.2.2.1.8.9 = INTEGER: 2
.1.3.6.1.2.1.2.2.1.8.10 = INTEGER: 2
.1.3.6.1.2.1.2.2.1.8.11 = INTEGER: 2
.1.3.6.1.2.1.2.2.1.9.1 = Timeticks: (0) 0:00:00.00
.1.3.6.1.2.1.2.2.1.9.2 = Timeticks: (0) 0:00:00.00
.1.3.6.1.2.1.2.2.1.9.3 = Timeticks: (0) 0:00:00.00
.1.3.6.1.2.1.2.2.1.9.4 = Timeticks: (0) 0:00:00.00
.1.3.6.1.2.1.2.2.1.9.5 = Timeticks: (0) 0:00:00.00
.1.3.6.1.2.1.2.2.1.9.6 = Timeticks: (0) 0:00:00.00
.1.3.6.1.2.1.2.2.1.9.7 = Timeticks: (0) 0:00:00.00
.1.3.6.1.2.1.2.2.1.9.8 = Timeticks: (0) 0:00:00.00
.1.3.6.1.2.1.2.2.1.9.9 = Timeticks: (0) 0:00:00.00
.1.3.6.1.2.1.2.2.1.9.10 = Timeticks: (0) 0:00:00.00
.1.3.6.1.2.1.2.2.1.9.11 = Timeticks: (0) 0:00:00.00
.1.3.6.1.2.1.2.2.1.10.1 = Counter32: 0
.1.3.6.1.2.1.2.2.1.10.2 = Counter32: 0
.1.3.6.1.2.1.2.2.1.10.3 = Counter32: 0
.1.3.6.1.2.1.2.2.1.10.4 = Counter32: 0
.1.3.6.1.2.1.2.2.1.10.5 = Counter32: 0
.1.3.6.1.2.1.2.2.1.10.6 = Counter32: 0
.1.3.6.1.2.1.2.2.1.10.7 = Counter32: 0
.1.3.6.1.2.1.2.2.1.10.8 = Counter32: 0
.1.3.6.1.2.1.2.2.1.10.9 = Counter32: 0
.1.3.6.1.2.1.2.2.1.10.10 = Counter32: 0
.1.3.6.1.2.1.2.2.1.10.11 = Counter32: 0
.1.3.6.1.2.1.2.2.1.11.1 = Counter32: 0
.1.3.6.1.2.1.2.2.1.11.2 = Counter32: 28051759
.1.3.6.1.2.1.2.2.1.11.3 = Counter32: 0
.1.3.6.1.2.1.2.2.1.11.4 = Counter32: 0
.1.3.6.1.2.1.2.2.1.11.5 = Counter32: 0
.1.3.6.1.2.1.2.2.1.11.6 = Counter32: 0
.1.3.6.1.2.1.2.2.1.11.7 = Counter32: 0
.1.3.6.1.2.1.2.2.1.11.8 = Counter32: 0
.1.3.6.1.2.1.2.2.1.11.9 = Counter32: 0
.1.3.6.1.2.1.2.2.1.11.10 = Counter32: 0
.1.3.6.1.2.1.2.2.1.11.11 = Counter32: 0
.1.3.6.1.2.1.2.2.1.12.1 = Counter32: 0
.1.3.6.1.2.1.2.2.1.12.2 = Counter32: 0
.1.3.6.1.2.1.2.2.1.12.3 = Counter32: 0
.1.3.6.1.2.1.2.2.1.12.4 = Counter32: 0
.1.3.6.1.2.1.2.2.1.12.5 = Counter32: 0
.1.3.6.1.2.1.2.2.1.12.6 = Counter32: 0
.1.3.6.1.2.1.2.2.1.12.7 = Counter32: 0
.1.3.6.1.2.1.2.2.1.12.8 = Counter32: 0
.1.3.6.1.2.1.2.2.1.12.9 = Counter32: 0
.1.3.6.1.2.1.2.2.1.12.10 = Counter32: 0
.1.3.6.1.2.1.2.2.1.12.11 = Counter32: 0
.1.3.6.1.2.1.2.2.1.13.1 = Counter32: 0
.1.3.6.1.2.1.2.2.1.13.2 = Counter32: 0
.1.3.6.1.2.1.2.2.1.13.3 = Counter32: 0
.1.3.6.1.2.1.2.2.1.13.4 = Counter32: 0
.1.3.6.1.2.1.2.2.1.13.5 = Counter32: 0
.1.3.6.1.2.1.2.2.1.13.6 = Counter32: 0
.1.3.6.1.2.1.2.2.1.13.7 = Counter32: 0
.1.3.6.1.2.1.2.2.1.13.8 = Counter32: 0
.1.3.6.1.2.1.2.2.1.13.9 = Counter32: 0
.1.3.6.1.2.1.2.2.1.13.10 = Counter32: 0
.1.3.6.1.2.1.2.2.1.13.11 = Counter32: 0
.1.3.6.1.2.1.2.2.1.14.1 = Counter32: 0
.1.3.6.1.2.1.2.2.1.14.2 = Counter32: 0
.1.3.6.1.2.1.2.2.1.14.3 = Counter32: 0
.1.3.6.1.2.1.2.2.1.14.4 = Counter32: 0
.1.3.6.1.2.1.2.2.1.14.5 = Counter32: 0
.1.3.6.1.2.1.2.2.1.14.6 = Counter32: 0
.1.3.6.1.2.1.2.2.1.14.7 = Counter32: 0
.1.3.6.1.2.1.2.2.1.14.8 = Counter32: 0
.1.3.6.1.2.1.2.2.1.14.9 = Counter32: 0
.1.3.6.1.2.1.2.2.1.14.10 = Counter32: 0
.1.3.6.1.2.1.2.2.1.14.11 = Counter32: 0
.1.3.6.1.2.1.2.2.1.15.1 = Counter32: 0
.1.3.6.1.2.1.2.2.1.15.2 = Counter32: 15185194
.1.3.6.1.2.1.2.2.1.15.3 = Counter32: 0
.1.3.6.1.2.1.2.2.1.15.4 = Counter32: 0
.1.3.6.1.2.1.2.2.1.15.5 = Counter32: 0
.1.3.6.1.2.1.2.2.1.15.6 = Counter32: 0
.1.3.6.1.2.1.2.2.1.15.7 = Counter32: 0
.1.3.6.1.2.1.2.2.1.15.8 = Counter32: 0
.1.3.6.1.2.1.2.2.1.15.9 = Counter32: 0
.1.3.6.1.2.1.2.2.1.15.10 = Counter32: 0
.1.3.6.1.2.1.2.2.1.15.11 = Counter32: 0
.1.3.6.1.2.1.2.2.1.16.1 = Counter32: 0
.1.3.6.1.2.1.2.2.1.16.2 = Counter32: 0
.1.3.6.1.2.1.2.2.1.16.3 = Counter32: 0
.1.3.6.1.2.1.2.2.1.16.4 = Counter32: 0
.1.3.6.1.2.1.2.2.1.16.5 = Counter32: 0
.1.3.6.1.2.1.2.2.1.16.6 = Counter32: 0
.1.3.6.1.2.1.2.2.1.16.7 = Counter32: 0
.1.3.6.1.2.1.2.2.1.16.8 = Counter32: 0
.1.3.6.1.2.1.2.2.1.16.9 = Counter32: 0
.1.3.6.1.2.1.2.2.1.16.10 = Counter32: 0
.1.3.6.1.2.1.2.2.1.16.11 = Counter32: 0
.1.3.6.1.2.1.2.2.1.17.1 = Counter32: 0
.1.3.6.1.2.1.2.2.1.17.2 = Counter32: 2496292
.1.3.6.1.2.1.2.2.1.17.3 = Counter32: 0
.1.3.6.1.2.1.2.2.1.17.4 = Counter32: 0
.1.3.6.1.2.1.2.2.1.17.5 = Counter32: 0
.1.3.6.1.2.1.2.2.1.17.6 = Counter32: 0
.1.3.6.1.2.1.2.2.1.17.7 = Counter32: 0
.1.3.6.1.2.1.2.2.1.17.8 = Counter32: 0
.1.3.6.1.2.1.2.2.1.17.9 = Counter32: 0
.1.3.6.1.2.1.2.2.1.17.10 = Counter32: 0
.1.3.6.1.2.1.2.2.1.17.11 = Counter32: 0
.1.3.6.1.2.1.2.2.1.18.1 = Counter32: 0
.1.3.6.1.2.1.2.2.1.18.2 = Counter32: 0
.1.3.6.1.2.1.2.2.1.18.3 = Counter32: 0
.1.3.6.1.2.1.2.2.1.18.4 = Counter32: 0
.1.3.6.1.2.1.2.2.1.18.5 = Counter32: 0
.1.3.6.1.2.1.2.2.1.18.6 = Counter32: 0
.1.3.6.1.2.1.2.2.1.18.7 = Counter32: 0
.1.3.6.1.2.1.2.2.1.18.8 = Counter32: 0
.1.3.6.1.2.1.2.2.1.18.9 = Counter32: 0
.1.3.6.1.2.1.2.2.1.18.10 = Counter32: 0
.1.3.6.1.2.1.2.2.1.18.11 = Counter32: 0
.1.3.6.1.2.1.2.2.1.19.1 = Counter32: 0
.1.3.6.1.2.1.2.2.1.19.2 = Counter32: 0
.1.3.6.1.2.1.2.2.1.19.3 = Counter32: 0
.1.3.6.1.2.1.2.2.1.19.4 = Counter32: 0
.1.3.6.1.2.1.2.2.1.19.5 = Counter32: 0
.1.3.6.1.2.1.2.2.1.19.6 = Counter32: 0
.1.3.6.1.2.1.2.2.1.19.7 = Counter32: 0
.1.3.6.1.2.1.2.2.1.19.8 = Counter32: 0
.1.3.6.1.2.1.2.2.1.19.9 = Counter32: 0
.1.3.6.1.2.1.2.2.1.19.10 = Counter32: 0
.1.3.6.1.2.1.2.2.1.19.11 = Counter32: 0
.1.3.6.1.2.1.2.2.1.20.1 = Counter32: 0
.1.3.6.1.2.1.2.2.1.20.2 = Counter32: 0
.1.3.6.1.2.1.2.2.1.20.3 = Counter32: 0
.1.3.6.1.2.1.2.2.1.20.4 = Counter32: 0
.1.3.6.1.2.1.2.2.1.20.5 = Counter32: 0
.1.3.6.1.2.1.2.2.1.20.6 = Counter32: 0
.1.3.6.1.2.1.2.2.1.20.7 = Counter32: 0
.1.3.6.1.2.1.2.2.1.20.8 = Counter32: 0
.1.3.6.1.2.1.2.2.1.20.9 = Counter32: 0
.1.3.6.1.2.1.2.2.1.20.10 = Counter32: 0
.1.3.6.1.2.1.2.2.1.20.11 = Counter32: 0
.1.3.6.1.2.1.2.2.1.21.1 = Gauge32: 0
.1.3.6.1.2.1.2.2.1.21.2 = Gauge32: 0
.1.3.6.1.2.1.2.2.1.21.3 = Gauge32: 0
.1.3.6.1.2.1.2.2.1.21.4 = Gauge32: 0
.1.3.6.1.2.1.2.2.1.21.5 = Gauge32: 0
.1.3.6.1.2.1.2.2.1.21.6 = Gauge32: 0
.1.3.6.1.2.1.2.2.1.21.7 = Gauge32: 0
.1.3.6.1.2.1.2.2.1.21.8 = Gauge32: 0
.1.3.6.1.2.1.2.2.1.21.9 = Gauge32: 0
.1.3.6.1.2.1.2.2.1.21.10 = Gauge32: 0
.1.3.6.1.2.1.2.2.1.21.11 = Gauge32: 0
.1.3.6.1.2.1.2.2.1.22.1 = OID: .0.0
.1.3.6.1.2.1.2.2.1.22.2 = OID: .0.0
.1.3.6.1.2.1.2.2.1.22.3 = OID: .1.3.6.1.2.1.10.33.2.1.1.3
.1.3.6.1.2.1.2.2.1.22.4 = OID: .1.3.6.1.2.1.10.33.2.1.1.4
.1.3.6.1.2.1.2.2.1.22.5 = OID: .1.3.6.1.2.1.10.33.2.1.1.5
.1.3.6.1.2.1.2.2.1.22.6 = OID: .1.3.6.1.2.1.10.33.2.1.1.6
.1.3.6.1.2.1.2.2.1.22.7 = OID: .1.3.6.1.2.1.10.33.2.1.1.7
.1.3.6.1.2.1.2.2.1.22.8 = OID: .1.3.6.1.2.1.10.33.2.1.1.8
.1.3.6.1.2.1.2.2.1.22.9 = OID: .1.3.6.1.2.1.10.33.2.1.1.9
.1.3.6.1.2.1.2.2.1.22.10 = OID: .1.3.6.1.2.1.10.33.2.1.1.10
.1.3.6.1.2.1.2.2.1.22.11 = OID: .1.3.6.1.2.1.10.33.2.1.1.11
.1.3.6.1.2.1.4.1.0 = INTEGER: 0
.1.3.6.1.2.1.4.2.0 = INTEGER: 128
.1.3.6.1.2.1.4.3.0 = Counter32: 9735182
.1.3.6.1.2.1.4.4.0 = Counter32: 0
.1.3.6.1.2.1.4.5.0 = Counter32: 26710
.1.3.6.1.2.1.4.6.0 = Counter32: 0
.1.3.6.1.2.1.4.7.0 = Counter32: 0
.1.3.6.1.2.1.4.8.0 = Counter32: 0
.1.3.6.1.2.1.4.9.0 = Counter32: 9735188
.1.3.6.1.2.1.4.10.0 = Counter32: 0
.1.3.6.1.2.1.4.11.0 = Counter32: 0
.1.3.6.1.2.1.4.12.0 = Counter32: 26710
.1.3.6.1.2.1.4.13.0 = INTEGER: 60
.1.3.6.1.2.1.4.14.0 = Counter32: 0
.1.3.6.1.2.1.4.15.0 = Counter32: 0
.1.3.6.1.2.1.4.16.0 = Counter32: 0
.1.3.6.1.2.1.4.17.0 = Counter32: 0
.1.3.6.1.2.1.4.18.0 = Counter32: 0
.1.3.6.1.2.1.4.19.0 = Counter32: 0
.1.3.6.1.2.1.4.20.1.1.192.168.105.9 = IpAddress: 192.168.105.9
.1.3.6.1.2.1.4.20.1.2.192.168.105.9 = INTEGER: 2
.1.3.6.1.2.1.4.20.1.3.192.168.105.9 = IpAddress: 255.255.254.0
.1.3.6.1.2.1.4.20.1.4.192.168.105.9 = INTEGER: 0
.1.3.6.1.2.1.4.20.1.5.192.168.105.9 = INTEGER: 8192
.1.3.6.1.2.1.4.20.1.5.192.168.105.9 = INTEGER: 8192
.1.3.6.1.2.1.4.20.1.5.192.168.105.9 = INTEGER: 8192
.1.3.6.1.2.1.4.20.1.5.192.168.105.9 = INTEGER: 8192

Et là après ça boucle à l'infini sur ce même OID je sais pas trop pourquoi.

Et l'autre snmpwalk plus clair :

# snmpwalk -v1 -c macommunauté 192.168.105.9
iso.3.6.1.2.1.1.1.0 = STRING: "C10  7.1_122"
iso.3.6.1.2.1.1.2.0 = OID: iso.3.6.1.4.1.714.1.2.6
iso.3.6.1.2.1.1.3.0 = Timeticks: (244429924) 28 days, 6:58:19.24
iso.3.6.1.2.1.1.4.0 = ""
iso.3.6.1.2.1.1.5.0 = STRING: "WT008064bd1b20"
iso.3.6.1.2.1.1.6.0 = ""
iso.3.6.1.2.1.1.7.0 = INTEGER: 79
iso.3.6.1.2.1.2.1.0 = INTEGER: 11
iso.3.6.1.2.1.2.2.1.1.1 = INTEGER: 1
iso.3.6.1.2.1.2.2.1.1.2 = INTEGER: 2
iso.3.6.1.2.1.2.2.1.1.3 = INTEGER: 3
iso.3.6.1.2.1.2.2.1.1.4 = INTEGER: 4
iso.3.6.1.2.1.2.2.1.1.5 = INTEGER: 5
iso.3.6.1.2.1.2.2.1.1.6 = INTEGER: 6
iso.3.6.1.2.1.2.2.1.1.7 = INTEGER: 7
iso.3.6.1.2.1.2.2.1.1.8 = INTEGER: 8
iso.3.6.1.2.1.2.2.1.1.9 = INTEGER: 9
iso.3.6.1.2.1.2.2.1.1.10 = INTEGER: 10
iso.3.6.1.2.1.2.2.1.1.11 = INTEGER: 11
iso.3.6.1.2.1.2.2.1.2.1 = STRING: "loop0"
iso.3.6.1.2.1.2.2.1.2.2 = STRING: "enet0"
iso.3.6.1.2.1.2.2.1.2.3 = STRING: "ppp0"
iso.3.6.1.2.1.2.2.1.2.4 = STRING: "ppp1"
iso.3.6.1.2.1.2.2.1.2.5 = STRING: "ppp2"
iso.3.6.1.2.1.2.2.1.2.6 = STRING: "ppp3"
iso.3.6.1.2.1.2.2.1.2.7 = STRING: "ppp4"
iso.3.6.1.2.1.2.2.1.2.8 = STRING: "ppp5"
iso.3.6.1.2.1.2.2.1.2.9 = STRING: "ppp6"
iso.3.6.1.2.1.2.2.1.2.10 = STRING: "ppp7"
iso.3.6.1.2.1.2.2.1.2.11 = STRING: "ppp8"
iso.3.6.1.2.1.2.2.1.3.1 = INTEGER: 24
iso.3.6.1.2.1.2.2.1.3.2 = INTEGER: 6
iso.3.6.1.2.1.2.2.1.3.3 = INTEGER: 23
iso.3.6.1.2.1.2.2.1.3.4 = INTEGER: 23
iso.3.6.1.2.1.2.2.1.3.5 = INTEGER: 23
iso.3.6.1.2.1.2.2.1.3.6 = INTEGER: 23
iso.3.6.1.2.1.2.2.1.3.7 = INTEGER: 23
iso.3.6.1.2.1.2.2.1.3.8 = INTEGER: 23
iso.3.6.1.2.1.2.2.1.3.9 = INTEGER: 23
iso.3.6.1.2.1.2.2.1.3.10 = INTEGER: 23
iso.3.6.1.2.1.2.2.1.3.11 = INTEGER: 23
iso.3.6.1.2.1.2.2.1.4.1 = INTEGER: 1200
iso.3.6.1.2.1.2.2.1.4.2 = INTEGER: 1500
iso.3.6.1.2.1.2.2.1.4.3 = INTEGER: 1400
iso.3.6.1.2.1.2.2.1.4.4 = INTEGER: 1400
iso.3.6.1.2.1.2.2.1.4.5 = INTEGER: 1400
iso.3.6.1.2.1.2.2.1.4.6 = INTEGER: 1400
iso.3.6.1.2.1.2.2.1.4.7 = INTEGER: 1400
iso.3.6.1.2.1.2.2.1.4.8 = INTEGER: 1300
iso.3.6.1.2.1.2.2.1.4.9 = INTEGER: 1300
iso.3.6.1.2.1.2.2.1.4.10 = INTEGER: 1300
iso.3.6.1.2.1.2.2.1.4.11 = INTEGER: 1300
iso.3.6.1.2.1.2.2.1.5.1 = Gauge32: 1
iso.3.6.1.2.1.2.2.1.5.2 = Gauge32: 1000000000
iso.3.6.1.2.1.2.2.1.5.3 = Gauge32: 9600
iso.3.6.1.2.1.2.2.1.5.4 = Gauge32: 9600
iso.3.6.1.2.1.2.2.1.5.5 = Gauge32: 9600
iso.3.6.1.2.1.2.2.1.5.6 = Gauge32: 9600
iso.3.6.1.2.1.2.2.1.5.7 = Gauge32: 0
iso.3.6.1.2.1.2.2.1.5.8 = Gauge32: 0
iso.3.6.1.2.1.2.2.1.5.9 = Gauge32: 0
iso.3.6.1.2.1.2.2.1.5.10 = Gauge32: 0
iso.3.6.1.2.1.2.2.1.5.11 = Gauge32: 0
iso.3.6.1.2.1.2.2.1.6.1 = Hex-STRING: 00 00 00 00 00 00
iso.3.6.1.2.1.2.2.1.6.2 = Hex-STRING: 00 80 64 BD 1B 20
iso.3.6.1.2.1.2.2.1.6.3 = Hex-STRING: 00 00 00 00 00 00
iso.3.6.1.2.1.2.2.1.6.4 = Hex-STRING: 00 00 00 00 00 00
iso.3.6.1.2.1.2.2.1.6.5 = Hex-STRING: 00 00 00 00 00 00
iso.3.6.1.2.1.2.2.1.6.6 = Hex-STRING: 00 00 00 00 00 00
iso.3.6.1.2.1.2.2.1.6.7 = Hex-STRING: 00 00 00 00 00 00
iso.3.6.1.2.1.2.2.1.6.8 = Hex-STRING: 00 00 00 00 00 00
iso.3.6.1.2.1.2.2.1.6.9 = Hex-STRING: 00 00 00 00 00 00
iso.3.6.1.2.1.2.2.1.6.10 = Hex-STRING: 00 00 00 00 00 00
iso.3.6.1.2.1.2.2.1.6.11 = Hex-STRING: 00 00 00 00 00 00
iso.3.6.1.2.1.2.2.1.7.1 = INTEGER: 2
iso.3.6.1.2.1.2.2.1.7.2 = INTEGER: 1
iso.3.6.1.2.1.2.2.1.7.3 = INTEGER: 2
iso.3.6.1.2.1.2.2.1.7.4 = INTEGER: 2
iso.3.6.1.2.1.2.2.1.7.5 = INTEGER: 2
iso.3.6.1.2.1.2.2.1.7.6 = INTEGER: 2
iso.3.6.1.2.1.2.2.1.7.7 = INTEGER: 2
iso.3.6.1.2.1.2.2.1.7.8 = INTEGER: 2
iso.3.6.1.2.1.2.2.1.7.9 = INTEGER: 2
iso.3.6.1.2.1.2.2.1.7.10 = INTEGER: 2
iso.3.6.1.2.1.2.2.1.7.11 = INTEGER: 2
iso.3.6.1.2.1.2.2.1.8.1 = INTEGER: 1
iso.3.6.1.2.1.2.2.1.8.2 = INTEGER: 1
iso.3.6.1.2.1.2.2.1.8.3 = INTEGER: 2
iso.3.6.1.2.1.2.2.1.8.4 = INTEGER: 2
iso.3.6.1.2.1.2.2.1.8.5 = INTEGER: 2
iso.3.6.1.2.1.2.2.1.8.6 = INTEGER: 2
iso.3.6.1.2.1.2.2.1.8.7 = INTEGER: 2
iso.3.6.1.2.1.2.2.1.8.8 = INTEGER: 2
iso.3.6.1.2.1.2.2.1.8.9 = INTEGER: 2
iso.3.6.1.2.1.2.2.1.8.10 = INTEGER: 2
iso.3.6.1.2.1.2.2.1.8.11 = INTEGER: 2
iso.3.6.1.2.1.2.2.1.9.1 = Timeticks: (0) 0:00:00.00
iso.3.6.1.2.1.2.2.1.9.2 = Timeticks: (0) 0:00:00.00
iso.3.6.1.2.1.2.2.1.9.3 = Timeticks: (0) 0:00:00.00
iso.3.6.1.2.1.2.2.1.9.4 = Timeticks: (0) 0:00:00.00
iso.3.6.1.2.1.2.2.1.9.5 = Timeticks: (0) 0:00:00.00
iso.3.6.1.2.1.2.2.1.9.6 = Timeticks: (0) 0:00:00.00
iso.3.6.1.2.1.2.2.1.9.7 = Timeticks: (0) 0:00:00.00
iso.3.6.1.2.1.2.2.1.9.8 = Timeticks: (0) 0:00:00.00
iso.3.6.1.2.1.2.2.1.9.9 = Timeticks: (0) 0:00:00.00
iso.3.6.1.2.1.2.2.1.9.10 = Timeticks: (0) 0:00:00.00
iso.3.6.1.2.1.2.2.1.9.11 = Timeticks: (0) 0:00:00.00
iso.3.6.1.2.1.2.2.1.10.1 = Counter32: 0
iso.3.6.1.2.1.2.2.1.10.2 = Counter32: 0
iso.3.6.1.2.1.2.2.1.10.3 = Counter32: 0
iso.3.6.1.2.1.2.2.1.10.4 = Counter32: 0
iso.3.6.1.2.1.2.2.1.10.5 = Counter32: 0
iso.3.6.1.2.1.2.2.1.10.6 = Counter32: 0
iso.3.6.1.2.1.2.2.1.10.7 = Counter32: 0
iso.3.6.1.2.1.2.2.1.10.8 = Counter32: 0
iso.3.6.1.2.1.2.2.1.10.9 = Counter32: 0
iso.3.6.1.2.1.2.2.1.10.10 = Counter32: 0
iso.3.6.1.2.1.2.2.1.10.11 = Counter32: 0
iso.3.6.1.2.1.2.2.1.11.1 = Counter32: 0
iso.3.6.1.2.1.2.2.1.11.2 = Counter32: 28058922
iso.3.6.1.2.1.2.2.1.11.3 = Counter32: 0
iso.3.6.1.2.1.2.2.1.11.4 = Counter32: 0
iso.3.6.1.2.1.2.2.1.11.5 = Counter32: 0
iso.3.6.1.2.1.2.2.1.11.6 = Counter32: 0
iso.3.6.1.2.1.2.2.1.11.7 = Counter32: 0
iso.3.6.1.2.1.2.2.1.11.8 = Counter32: 0
iso.3.6.1.2.1.2.2.1.11.9 = Counter32: 0
iso.3.6.1.2.1.2.2.1.11.10 = Counter32: 0
iso.3.6.1.2.1.2.2.1.11.11 = Counter32: 0
iso.3.6.1.2.1.2.2.1.12.1 = Counter32: 0
iso.3.6.1.2.1.2.2.1.12.2 = Counter32: 0
iso.3.6.1.2.1.2.2.1.12.3 = Counter32: 0
iso.3.6.1.2.1.2.2.1.12.4 = Counter32: 0
iso.3.6.1.2.1.2.2.1.12.5 = Counter32: 0
iso.3.6.1.2.1.2.2.1.12.6 = Counter32: 0
iso.3.6.1.2.1.2.2.1.12.7 = Counter32: 0
iso.3.6.1.2.1.2.2.1.12.8 = Counter32: 0
iso.3.6.1.2.1.2.2.1.12.9 = Counter32: 0
iso.3.6.1.2.1.2.2.1.12.10 = Counter32: 0
iso.3.6.1.2.1.2.2.1.12.11 = Counter32: 0
iso.3.6.1.2.1.2.2.1.13.1 = Counter32: 0
iso.3.6.1.2.1.2.2.1.13.2 = Counter32: 0
iso.3.6.1.2.1.2.2.1.13.3 = Counter32: 0
iso.3.6.1.2.1.2.2.1.13.4 = Counter32: 0
iso.3.6.1.2.1.2.2.1.13.5 = Counter32: 0
iso.3.6.1.2.1.2.2.1.13.6 = Counter32: 0
iso.3.6.1.2.1.2.2.1.13.7 = Counter32: 0
iso.3.6.1.2.1.2.2.1.13.8 = Counter32: 0
iso.3.6.1.2.1.2.2.1.13.9 = Counter32: 0
iso.3.6.1.2.1.2.2.1.13.10 = Counter32: 0
iso.3.6.1.2.1.2.2.1.13.11 = Counter32: 0
iso.3.6.1.2.1.2.2.1.14.1 = Counter32: 0
iso.3.6.1.2.1.2.2.1.14.2 = Counter32: 0
iso.3.6.1.2.1.2.2.1.14.3 = Counter32: 0
iso.3.6.1.2.1.2.2.1.14.4 = Counter32: 0
iso.3.6.1.2.1.2.2.1.14.5 = Counter32: 0
iso.3.6.1.2.1.2.2.1.14.6 = Counter32: 0
iso.3.6.1.2.1.2.2.1.14.7 = Counter32: 0
iso.3.6.1.2.1.2.2.1.14.8 = Counter32: 0
iso.3.6.1.2.1.2.2.1.14.9 = Counter32: 0
iso.3.6.1.2.1.2.2.1.14.10 = Counter32: 0
iso.3.6.1.2.1.2.2.1.14.11 = Counter32: 0
iso.3.6.1.2.1.2.2.1.15.1 = Counter32: 0
iso.3.6.1.2.1.2.2.1.15.2 = Counter32: 15189587
iso.3.6.1.2.1.2.2.1.15.3 = Counter32: 0
iso.3.6.1.2.1.2.2.1.15.4 = Counter32: 0
iso.3.6.1.2.1.2.2.1.15.5 = Counter32: 0
iso.3.6.1.2.1.2.2.1.15.6 = Counter32: 0
iso.3.6.1.2.1.2.2.1.15.7 = Counter32: 0
iso.3.6.1.2.1.2.2.1.15.8 = Counter32: 0
iso.3.6.1.2.1.2.2.1.15.9 = Counter32: 0
iso.3.6.1.2.1.2.2.1.15.10 = Counter32: 0
iso.3.6.1.2.1.2.2.1.15.11 = Counter32: 0
iso.3.6.1.2.1.2.2.1.16.1 = Counter32: 0
iso.3.6.1.2.1.2.2.1.16.2 = Counter32: 0
iso.3.6.1.2.1.2.2.1.16.3 = Counter32: 0
iso.3.6.1.2.1.2.2.1.16.4 = Counter32: 0
iso.3.6.1.2.1.2.2.1.16.5 = Counter32: 0
iso.3.6.1.2.1.2.2.1.16.6 = Counter32: 0
iso.3.6.1.2.1.2.2.1.16.7 = Counter32: 0
iso.3.6.1.2.1.2.2.1.16.8 = Counter32: 0
iso.3.6.1.2.1.2.2.1.16.9 = Counter32: 0
iso.3.6.1.2.1.2.2.1.16.10 = Counter32: 0
iso.3.6.1.2.1.2.2.1.16.11 = Counter32: 0
iso.3.6.1.2.1.2.2.1.17.1 = Counter32: 0
iso.3.6.1.2.1.2.2.1.17.2 = Counter32: 2496838
iso.3.6.1.2.1.2.2.1.17.3 = Counter32: 0
iso.3.6.1.2.1.2.2.1.17.4 = Counter32: 0
iso.3.6.1.2.1.2.2.1.17.5 = Counter32: 0
iso.3.6.1.2.1.2.2.1.17.6 = Counter32: 0
iso.3.6.1.2.1.2.2.1.17.7 = Counter32: 0
iso.3.6.1.2.1.2.2.1.17.8 = Counter32: 0
iso.3.6.1.2.1.2.2.1.17.9 = Counter32: 0
iso.3.6.1.2.1.2.2.1.17.10 = Counter32: 0
iso.3.6.1.2.1.2.2.1.17.11 = Counter32: 0
iso.3.6.1.2.1.2.2.1.18.1 = Counter32: 0
iso.3.6.1.2.1.2.2.1.18.2 = Counter32: 0
iso.3.6.1.2.1.2.2.1.18.3 = Counter32: 0
iso.3.6.1.2.1.2.2.1.18.4 = Counter32: 0
iso.3.6.1.2.1.2.2.1.18.5 = Counter32: 0
iso.3.6.1.2.1.2.2.1.18.6 = Counter32: 0
iso.3.6.1.2.1.2.2.1.18.7 = Counter32: 0
iso.3.6.1.2.1.2.2.1.18.8 = Counter32: 0
iso.3.6.1.2.1.2.2.1.18.9 = Counter32: 0
iso.3.6.1.2.1.2.2.1.18.10 = Counter32: 0
iso.3.6.1.2.1.2.2.1.18.11 = Counter32: 0
iso.3.6.1.2.1.2.2.1.19.1 = Counter32: 0
iso.3.6.1.2.1.2.2.1.19.2 = Counter32: 0
iso.3.6.1.2.1.2.2.1.19.3 = Counter32: 0
iso.3.6.1.2.1.2.2.1.19.4 = Counter32: 0
iso.3.6.1.2.1.2.2.1.19.5 = Counter32: 0
iso.3.6.1.2.1.2.2.1.19.6 = Counter32: 0
iso.3.6.1.2.1.2.2.1.19.7 = Counter32: 0
iso.3.6.1.2.1.2.2.1.19.8 = Counter32: 0
iso.3.6.1.2.1.2.2.1.19.9 = Counter32: 0
iso.3.6.1.2.1.2.2.1.19.10 = Counter32: 0
iso.3.6.1.2.1.2.2.1.19.11 = Counter32: 0
iso.3.6.1.2.1.2.2.1.20.1 = Counter32: 0
iso.3.6.1.2.1.2.2.1.20.2 = Counter32: 0
iso.3.6.1.2.1.2.2.1.20.3 = Counter32: 0
iso.3.6.1.2.1.2.2.1.20.4 = Counter32: 0
iso.3.6.1.2.1.2.2.1.20.5 = Counter32: 0
iso.3.6.1.2.1.2.2.1.20.6 = Counter32: 0
iso.3.6.1.2.1.2.2.1.20.7 = Counter32: 0
iso.3.6.1.2.1.2.2.1.20.8 = Counter32: 0
iso.3.6.1.2.1.2.2.1.20.9 = Counter32: 0
iso.3.6.1.2.1.2.2.1.20.10 = Counter32: 0
iso.3.6.1.2.1.2.2.1.20.11 = Counter32: 0
iso.3.6.1.2.1.2.2.1.21.1 = Gauge32: 0
iso.3.6.1.2.1.2.2.1.21.2 = Gauge32: 0
iso.3.6.1.2.1.2.2.1.21.3 = Gauge32: 0
iso.3.6.1.2.1.2.2.1.21.4 = Gauge32: 0
iso.3.6.1.2.1.2.2.1.21.5 = Gauge32: 0
iso.3.6.1.2.1.2.2.1.21.6 = Gauge32: 0
iso.3.6.1.2.1.2.2.1.21.7 = Gauge32: 0
iso.3.6.1.2.1.2.2.1.21.8 = Gauge32: 0
iso.3.6.1.2.1.2.2.1.21.9 = Gauge32: 0
iso.3.6.1.2.1.2.2.1.21.10 = Gauge32: 0
iso.3.6.1.2.1.2.2.1.21.11 = Gauge32: 0
iso.3.6.1.2.1.2.2.1.22.1 = OID: ccitt.0
iso.3.6.1.2.1.2.2.1.22.2 = OID: ccitt.0
iso.3.6.1.2.1.2.2.1.22.3 = OID: iso.3.6.1.2.1.10.33.2.1.1.3
iso.3.6.1.2.1.2.2.1.22.4 = OID: iso.3.6.1.2.1.10.33.2.1.1.4
iso.3.6.1.2.1.2.2.1.22.5 = OID: iso.3.6.1.2.1.10.33.2.1.1.5
iso.3.6.1.2.1.2.2.1.22.6 = OID: iso.3.6.1.2.1.10.33.2.1.1.6
iso.3.6.1.2.1.2.2.1.22.7 = OID: iso.3.6.1.2.1.10.33.2.1.1.7
iso.3.6.1.2.1.2.2.1.22.8 = OID: iso.3.6.1.2.1.10.33.2.1.1.8
iso.3.6.1.2.1.2.2.1.22.9 = OID: iso.3.6.1.2.1.10.33.2.1.1.9
iso.3.6.1.2.1.2.2.1.22.10 = OID: iso.3.6.1.2.1.10.33.2.1.1.10
iso.3.6.1.2.1.2.2.1.22.11 = OID: iso.3.6.1.2.1.10.33.2.1.1.11
iso.3.6.1.2.1.4.1.0 = INTEGER: 0
iso.3.6.1.2.1.4.2.0 = INTEGER: 128
iso.3.6.1.2.1.4.3.0 = Counter32: 9737405
iso.3.6.1.2.1.4.4.0 = Counter32: 0
iso.3.6.1.2.1.4.5.0 = Counter32: 26714
iso.3.6.1.2.1.4.6.0 = Counter32: 0
iso.3.6.1.2.1.4.7.0 = Counter32: 0
iso.3.6.1.2.1.4.8.0 = Counter32: 0
iso.3.6.1.2.1.4.9.0 = Counter32: 9737411
iso.3.6.1.2.1.4.10.0 = Counter32: 0
iso.3.6.1.2.1.4.11.0 = Counter32: 0
iso.3.6.1.2.1.4.12.0 = Counter32: 26714
iso.3.6.1.2.1.4.13.0 = INTEGER: 60
iso.3.6.1.2.1.4.14.0 = Counter32: 0
iso.3.6.1.2.1.4.15.0 = Counter32: 0
iso.3.6.1.2.1.4.16.0 = Counter32: 0
iso.3.6.1.2.1.4.17.0 = Counter32: 0
iso.3.6.1.2.1.4.18.0 = Counter32: 0
iso.3.6.1.2.1.4.19.0 = Counter32: 0
iso.3.6.1.2.1.4.20.1.1.192.168.105.9 = IpAddress: 192.168.105.9
iso.3.6.1.2.1.4.20.1.2.192.168.105.9 = INTEGER: 2
iso.3.6.1.2.1.4.20.1.3.192.168.105.9 = IpAddress: 255.255.254.0
iso.3.6.1.2.1.4.20.1.4.192.168.105.9 = INTEGER: 0
iso.3.6.1.2.1.4.20.1.5.192.168.105.9 = INTEGER: 8192
iso.3.6.1.2.1.4.20.1.5.192.168.105.9 = INTEGER: 8192
Error: OID not increasing: iso.3.6.1.2.1.4.20.1.5.192.168.105.9
 >= iso.3.6.1.2.1.4.20.1.5.192.168.105.9

Et là j'imagine qu'il boucle à l'infini aussi, j'ai tenté de voir sur le net ce qu'il se passe mais j'ai rien compris. Le SNMP reste encore un gros mystère pour moi.

gbougard wrote:

Pour info, je vais être en congès 2 semaines, donc si tu as du neuf, je n'y répondrais probablement pas avant la rentrée. Bon courage d'ici là ;-)

Et bah pareil pour moi du coup , merci beaucoup pour le temps que tu me consacre, ça m'aide beaucoup.

Roby · 2021-08-24 14:28:08

Bonjour
Le nom par défaut des Wyse, c'est WT + l'adresse mac sans les :, du coup c'est déjà unique ...

Chez moi il me récupère bien les noms ! (9.5.5 + FI 9.5+3.0 et le patch sur l'agent 2.6 qui tourne sous ubuntu serveur)
Maintenant j'ai un souci de doublon, mais je vais créer un autre sujet

gbougard · 2021-09-01 14:58:52

Bonjour Azlo,

le bouclage sur l'OID "iso.3.6.1.2.1.4.20.1.5.192.168.105.9" est hautement suspect. Tu as probablement un problème sur ce Wyse au moins et ça pourrait impacter les tentatives d'inventaire. Essaies de voir si une mise à jour du firmware n'est pas disponible ou sinon tu devrais carrément rapporter ce bogue au constructeur ! Une autre tentative serait de ré-initialiser entièrement et de reconfigurer proprement le Wyse pour être certain qu'une mauvaise configuration n'est pas la cause du dysfonctionnement.

Concernant le nom, effectivement, comme netdiscovery extrait le bon nom, on ne devrait avoir de problème avec ça ensuite.

Azlo · 2021-09-14 11:14:51

Bonjour,

Roby wrote:

Bonjour
Le nom par défaut des Wyse, c'est WT + l'adresse mac sans les :, du coup c'est déjà unique ...

Yep.

Roby wrote:

Chez moi il me récupère bien les noms ! (9.5.5 + FI 9.5+3.0 et le patch sur l'agent 2.6 qui tourne sous ubuntu serveur)
Maintenant j'ai un souci de doublon, mais je vais créer un autre sujet

Puis-je te détester pour ma santé mental ?
Blague à part, quelles sont tes modèles de Wyse ? J'ai essentiellement des 3040 maintenant mais j'ai aussi des vielles SX0 et aussi des ... CT-50 je crois ? un truc comme ça.

gbougard wrote:

Bonjour Azlo,
le bouclage sur l'OID "iso.3.6.1.2.1.4.20.1.5.192.168.105.9" est hautement suspect. Tu as probablement un problème sur ce Wyse au moins et ça pourrait impacter les tentatives d'inventaire. Essaies de voir si une mise à jour du firmware n'est pas disponible ou sinon tu devrais carrément rapporter ce bogue au constructeur ! Une autre tentative serait de ré-initialiser entièrement et de reconfigurer proprement le Wyse pour être certain qu'une mauvaise configuration n'est pas la cause du dysfonctionnement.
Concernant le nom, effectivement, comme netdiscovery extrait le bon nom, on ne devrait avoir de problème avec ça ensuite.

Le truc c'est que ça fait ça sur toutes les Wyses de ce modèle et je ne pense pas que le soucis viennent de là puisque le XML qui est généré a bien toutes les infos (dont le nom d'hôte).
J'ai aussi des Wyses qui ne présentent pas ce problème (les 3040 en l'occurence) le système se comporte de la même manière au final.

J'ai tenté de tout supprimer et de tout refaire une nouvelle fois mais rien n'y fait. La différence entre moi et Roby que je vois pour le moment c'est que je suis sous Debian et pas Ubuntu, je sais pas si ça pourrait faire un différence, mais j'en doute.

Roby · 2021-09-14 14:09:00

Salut,
J'ai majoritairement du 3040, sinon j'ai du 3012 mais pas trop. Les 2 remontent correctement avec le patch. Et pour le coup je ne crois pas à la différence entre debian et ubuntu c'est quand même vraiment très très proche, tu dois avoir un autre souci

gbougard · 2021-09-15 08:15:41

Bonjour,

je confirme, du point de vue de l'agent, debian et ubuntu, c'est pareil. C'est plutôt la version du système qui pourrait influer, mais à moins que tu aies un système totalement dépassé apportant des bogues dans la pile de support SNMP, pour moi, c'est pas là le problème.

As-tu touché aux règles d'import et de liaison ? Généralement, les doublons viennent d'un mauvais usage de ces règles.

Azlo · 2021-09-15 16:14:00

Bonjour,

Concernant les versions de linux ne j'y croyais pas non plus mais je préfère demander connaissant mal le libre (ce qui est un tord mais je m'y met petit à petit). J'avais un Debian Stretch que j'ai passé en Buster donc rien de dinosauresque là dedans.

gbougard wrote:

As-tu touché aux règles d'import et de liaison ? Généralement, les doublons viennent d'un mauvais usage de ces règles.

Je ne crois pas y avoir touché.
Qu'entends-tu par doublon ? Le soucis vient du fait que GLPI nomme mes Wyse en fonction de l'adresse IP, c'est Roby qui parlait de doublon ici et sur son autre post nous sommes d'accord ?

Par acquis de conscience je vais réinitialiser les règles et je ferais un test demain. Si ça marche pour Roby et pas pour moi avec les même version de logiciel et les même modèles de Wyse y'a pas de raison que ça ne fonctionne pas c'est fou cette histoire.

Sinon Roby je voulais savoir, avant d'intégrer le code de gbougard, avais-tu le même soucis que moi ou c'était autre chose ?

Roby · 2021-09-15 16:16:04

Salut,

Avant d'ajouter son code, je ne récupérais pas les numéros de série des wyse ou la version du firmware, mais je n'avais pas de souci avec le nom

gbougard · 2021-09-15 17:11:20

Mdr, je commence à m'embrouiller un peu avec vos 2 threads

Forum GLPI-Project

Announcement

#1 2021-07-13 16:33:08

Découverte réseau, SNMP et Wyses ...

J’ai deux souci :

#2 2021-07-21 11:16:13

Re: Découverte réseau, SNMP et Wyses ...

#3 2021-07-23 13:12:34

Re: Découverte réseau, SNMP et Wyses ...

#4 2021-08-03 14:13:08

Re: Découverte réseau, SNMP et Wyses ...

#5 2021-08-03 18:19:44

Re: Découverte réseau, SNMP et Wyses ...

#6 2021-08-04 17:42:59

Re: Découverte réseau, SNMP et Wyses ...

#7 2021-08-05 10:44:36

Re: Découverte réseau, SNMP et Wyses ...

#8 2021-08-12 16:12:18

Re: Découverte réseau, SNMP et Wyses ...

#9 2021-08-13 13:33:51

Re: Découverte réseau, SNMP et Wyses ...

#10 2021-08-13 16:29:22

Re: Découverte réseau, SNMP et Wyses ...

#11 2021-08-24 14:28:08

Re: Découverte réseau, SNMP et Wyses ...

#12 2021-09-01 14:58:52

Re: Découverte réseau, SNMP et Wyses ...

#13 2021-09-14 11:14:51

Re: Découverte réseau, SNMP et Wyses ...

#14 2021-09-14 14:09:00

Re: Découverte réseau, SNMP et Wyses ...

#15 2021-09-15 08:15:41

Re: Découverte réseau, SNMP et Wyses ...

#16 2021-09-15 16:14:00

Re: Découverte réseau, SNMP et Wyses ...

#17 2021-09-15 16:16:04

Re: Découverte réseau, SNMP et Wyses ...

#18 2021-09-15 17:11:20

Re: Découverte réseau, SNMP et Wyses ...

Board footer