glpi-project / glpi-agent

GLPI Agent
GNU General Public License v2.0
212 stars 51 forks source link

SNMP error communication using glpi-netinventory while snmpwalk it works #556

Closed Franco-Sparrow closed 6 months ago

Franco-Sparrow commented 6 months ago

Bug reporting acknowledgment

Yes, I read it

Professional support

None

Describe the bug

I am not able to execute netinventory through glpi-agent, to a network device (switch) on different network. I am able to execute snmpwalk and succesfully gather the SNMP information, but not with the glpi-agent.

The GLPI server, with the given agent is located on a different network, it means is not in L2 with the network devices, but it can reach them though VPN access, through a host that is directly connected to this network, and is masquerading all traffic from tun0 (OpenVPN tunnel). Once garanteed this communication, the snmpwalk it works from the GLPI server to the network device, on the isolated network, but through the glpi-netinventory is not working. It only works through the host that is at the edge (the VPN server that is in L2 with the network devices).

Does this means that glpi-netinventory cant be execute from a host on a different network?

To reproduce

Execute a netdiscovery:

glpi-netdiscovery --host 10.7.100.3 --credentials version:2c,community:ecasanc --timeout 30 --inventory --save /etc/glpi-agent/ --debug

Created the file 10.7.100.3.xml

cat /etc/glpi-agent//netdiscovery/10.7.100.3.xml

Its contents is as follow:

<?xml version="1.0" encoding="UTF-8"?>
<REQUEST>
  <CONTENT>
    <DEVICE>
      <AUTHSNMP>1</AUTHSNMP>
      <CONTACT>Grupo de soporte redes@ecasa.avianet.cu</CONTACT>
      <DESCRIPTION>Huawei Versatile Routing Platform Software
VRP Software Version 3.10, Release 1510P02
Quidway S5624P Product Version S5600-1510P02
Copyright (c) 1998-2006 Huawei Technologies Co.,Ltd. All rights reserved.</DESCRIPTION>
      <DNSHOSTNAME>10.7.100.3</DNSHOSTNAME>
      <IP>10.7.100.3</IP>
      <LOCATION>Centro de Datos #1 (principal). Redes. Rack de equipos activos.</LOCATION>
      <MAC>00:0f:e2:59:ef:dd</MAC>
      <MANUFACTURER>Huawei</MANUFACTURER>
      <MODEL>QuidWay S5624P</MODEL>
      <SERIAL>210235A126A075000117</SERIAL>
      <SNMPHOSTNAME>SW2-S5600</SNMPHOSTNAME>
      <TYPE>NETWORKING</TYPE>
      <UPTIME>348 days, 11:43:07.00</UPTIME>
    </DEVICE>
    <MODULEVERSION>6.0</MODULEVERSION>
    <PROCESSNUMBER>1</PROCESSNUMBER>
  </CONTENT>
  <DEVICEID>foo</DEVICEID>
  <QUERY>NETDISCOVERY</QUERY>
</REQUEST>

But when used glpi-netinventory command:

glpi-netinventory --host 10.7.100.3 --credentials version:2c,community:ecasanc --timeout 30 --type NETWORKING --debug > 10.7.100.3.xml

It only created the file 10.7.100.3.xml on your root directory, not inside the agent folder as expected (it can be fixed specifying the complete path, but you still have to create the netinventory folder first)

Anyway, the output of the previous command is as follow:

[debug] Current netinventory run expiration timeout: 1.0 hour
[debug] using 1 netinventory worker
[debug] #1, full snmp scan of 10.7.100.3 with credentials 1
[debug] #1, full match for sysobjectID .1.3.6.1.4.1.2011.10.1.43 in database

When you check the file 10.7.100.3.xml, is empty.

I can execute an snmpwalk to the network device:

snmpwalk 10.7.100.3 -v2c -c ecasanc | less

The output is as follow:

iso.3.6.1.2.1.1.1.0 = STRING: "Huawei Versatile Routing Platform Software
VRP Software Version 3.10, Release 1510P02
Quidway S5624P Product Version S5600-1510P02

Copyright (c) 1998-2006 Huawei Technologies Co.,Ltd. All rights reserved.
"
iso.3.6.1.2.1.1.2.0 = OID: iso.3.6.1.4.1.2011.10.1.43
iso.3.6.1.2.1.1.3.0 = Timeticks: (3010900800) 348 days, 11:36:48.00
iso.3.6.1.2.1.1.4.0 = STRING: "Grupo de soporte redes@ecasa.avianet.cu"
iso.3.6.1.2.1.1.5.0 = STRING: "SW2-S5600"
iso.3.6.1.2.1.1.6.0 = STRING: "Centro de Datos #1 (principal). Redes. Rack de equipos activos."
iso.3.6.1.2.1.1.7.0 = INTEGER: 78
iso.3.6.1.2.1.2.1.0 = INTEGER: 35
iso.3.6.1.2.1.2.2.1.1.14 = INTEGER: 14
iso.3.6.1.2.1.2.2.1.1.16 = INTEGER: 16
iso.3.6.1.2.1.2.2.1.1.31 = INTEGER: 31
iso.3.6.1.2.1.2.2.1.1.823 = INTEGER: 823
iso.3.6.1.2.1.2.2.1.1.4227614 = INTEGER: 4227614
# [...]

Trying again with glpi-netinventory command, this time with less options:

glpi-netinventory --host 10.7.100.3 --credentials version:2c,community:ecasanc

The output show error communication via SNMP using the agent:

[error] #1, SNMP communication error: no response from host 10.7.100.3
<?xml version="1.0" encoding="UTF-8"?>
<REQUEST>
  <CONTENT>
    <DEVICE>
      <ERROR>
        <ID>0</ID>
        <MESSAGE>SNMP communication error: no response from host 10.7.100.3</MESSAGE>
      </ERROR>
    </DEVICE>
    <MODULEVERSION>6.0</MODULEVERSION>
    <PROCESSNUMBER>1</PROCESSNUMBER>
  </CONTENT>
  <DEVICEID>foo</DEVICEID>
  <QUERY>SNMPQUERY</QUERY>
</REQUEST>

Why is not working the netinventory using the agent, when snmpwalk is able to query the remote network device, using SNMP protocol?

Expected behavior

The glpi-netinventory being able to gather SNMP information from the network device, on a different network.

Operating system

Linux

GLPI Agent version

1.6.1

GLPI version

10.0.10

GLPIInventory plugin or FusionInventory for GLPI plugin version

GLPI Inventory v1.x.x (See additional context below)

Additional context

The agent is installed on same GLPI server and the server has access to isolated network for network devices, through VPN. Network devices are under 10.7.100.0/24, while GLPI server is glpi.ecasa.avianet.cu. The agent config is as follow:

server = https://glpi.ecasa.avianet.cu/marketplace/glpiinventory
delaytime = 3600
lazy = 0
scan-homedirs = 0
scan-profiles = 0
html = 0
backend-collect-timeout = 180
force = 0
additional-content =
no-p2p = 0
proxy =
user =
password =
ca-cert-dir =
ca-cert-file =
no-ssl-check = 1
timeout = 180
no-httpd = 1
httpd-ip =
httpd-port = 62354
httpd-trust =
logger = stderr
logfile = /var/log/glpi-agent.log
logfacility = LOG_USER
color = 0
tag =
debug = 0
g-bougard commented 6 months ago

Hi @Franco-Sparrow

well I don't know why but indeed I missed you opened this issue before I answered your comment and opened #588 discussion.

So I'm closing to continue the discussion in #588.