Network Discovery does not work in GLPI 9.5.1.

hdelta045 · 2020-08-18 10:04:47

Server configuration: Ubuntu 20.04, GLPI 9.5.1, FusionInventory 9.5.0 + 1.0. FusionInventy 2.5 x64 client on Windows 10 x64 2004. SNMP protocol is installed and running on network equipment and computers. Network Discovery and Network Inventory are configured according to the FusionInventory instructions. I start the Network discovery task. I watch the task completion. The task appears but is in the "Prepared" state. Looking for nothing. They are coming for the second day. The client's logs indicate "Prepared".
I look at the FI and GLPI logs - there are no error messages.
If you connect to a computer and forcibly run FI Status Agent, the computer appears in the asset list. At the same time, he still does not look for printers and other network printers.
On the same configuration GLPI 9.4.5 works fine and looks for hardware.

What can be, where to look?

WebGreg · 2020-08-24 22:49:07

Maybe printscreens?

hdelta045 · 2020-08-25 11:05:52

WebGreg wrote:

Maybe printscreens?

Which sections do you want to see screenshots?

WebGreg · 2020-08-25 16:27:14

Good question So many places
Maybe I will write what I have - you will compare it.

Administration > FusionInventory > Tasks:
Task Management:
- Re-prepare a target actor: on
- Active: on
- Agent wakeup interval: 45
- Number of agents to wake up:1
Jobs configuration:
- Targets: IP range 10.0.0.1-10.0.0.50
- Actors: Agent_installed_somewhere
Job executions:
- Prepered: 1

Administration > FusionInventory > General > agents management > Agent_installed_somewhere > agents modules:
- Wake on LAN: on
- Network discovery: on
- Collect data: on
- Computer inventory: on
- SNMP: on

http://Agent_installed_somewhere:62354 > force inventory

And it works for me.

Last edited by WebGreg (2020-08-25 16:29:12)

hdelta045 · 2020-08-26 11:04:26

WebGreg wrote:

Good question So many places
...

And it works for me.

Sorry, for the second week I have been trying to start collecting data on my network, it’s no laughing matter.

IP range

Agent module

Network discovery

Network inventory

Discovery status

Does it matter that the agent has Windows 10 x64 2004 installed on the computer?

WebGreg · 2020-08-26 20:21:33

hdelta045 wrote:

Does it matter that the agent has Windows 10 x64 2004 installed on the computer?

In my opinion - no. I used agents with Windows 10 (v2.5.2), 7 and now Discovery and Inventory with Ubuntu. Works everywhere.

For me your configuration looks OK. I wonder if you are connected to the agent, but since you show the modules tab, it seems yes.

Did you try force start the inventory from agent website? You didn't set schedule start. I don't remember is it nessesery (but I think - no - the agent should get active tasks from the server during next time connect to the server) because I always started with "force inventory" - after that if re-prepare is set - next task starts automatic.

You must assign SNMP authentication to the IP range. But that shouldn't block the task, it should only cause (in the worst), that you get info about ignore the device import.

Did you check the fusioninventory-agent log file (C:\Program Files\FusionInventory-Agent\fusioninventory-agent.log)?

Last edited by WebGreg (2020-08-26 20:39:21)

hdelta045 · 2020-08-27 05:57:07

Yes, I forced discovery, you can see the result in the screenshot. As I understand it, first of all, you need to run discovery, and then inventory. Since it is not possible to start discovery, I do not see the need to start SNMP inventory now.

On the machine with the agent installed, I forcibly ran the fusioninventory-netdiscovery.bat file with the start and end addresses. The operation was successful, at least all network devices and their addresses he showed.
eg

<?xml version="1.0" encoding="UTF-8" ?>
<REQUEST>
<CONTENT>
<DEVICE>
<AUTHSNMP>1</AUTHSNMP>
<DESCRIPTION>HP ETHERNET MULTI-ENVIRONMENT,ROM none,JETDIRECT</DESCRIPTION>
<DNSHOSTNAME>192.168.1.171</DNSHOSTNAME>
<FIRMWARE>TR8-TR_10.0.1.5</FIRMWARE>
<IP>192.168.1.171</IP>
<IPS>
<IP>127.0.0.1</IP>
<IP>192.168.1.171</IP>
</IPS>
<MAC>00:26:55:16:a5:28</MAC>
<MANUFACTURER>Hewlett-Packard</MANUFACTURER>
<MODEL>HP Designjet Z2100 44in Photo</MODEL>
<SERIAL>CN3B73K011</SERIAL>
<SNMPHOSTNAME>NPI00265516A528</SNMPHOSTNAME>
<TYPE>PRINTER</TYPE>
<UPTIME>15 days, 06:59:44.86</UPTIME>
</DEVICE>
<MODULEVERSION>4.1</MODULEVERSION>
<PROCESSNUMBER>1</PROCESSNUMBER>
</CONTENT>
<DEVICEID>foo</DEVICEID>
<QUERY>NETDISCOVERY</QUERY>
</REQUEST>

I'll try to run fusioninventory-netinventory.bat now, maybe these devices will appear in GLPI.

The log file fusioninventory-agent.log looks like this

[Thu Aug 27 06:41:58 2020][info] running task Maintenance
[Thu Aug 27 06:42:02 2020][info] FusionInventory Agent memory usage: WSS=3358720 PFU=172924928

It seems to me that I have broken communication between the GLPI server and the FI agent. The server cannot tell the agent to start scanning, so the netdiscovery status is "Prepared". Can I somehow check this connection? Maybe on the server side or in Ubuntu I need to make some settings?

UPD.
I checked the collection of information on SNTN. On those network devices where this protocol is enabled, data is collected. Where it is not, it writes an entry to the log that skips inventory because it does not recognize the type

This indicates that the server is not sending a command to the agent to start data collection. The question is why? Second question: how to fix this?

Last edited by hdelta045 (2020-08-27 12:48:03)

WebGreg · 2020-08-27 19:45:12

hdelta045 wrote:

Yes, I forced discovery, you can see the result in the screenshot.

I thought about this:

First try open site on the agent machine: h ttp://localhost:your_port/ (default is h ttp://localhost:62354/)

hdelta045 wrote:

As I understand it, first of all, you need to run discovery, and then inventory. Since it is not possible to start discovery, I do not see the need to start SNMP inventory now.

indeed

hdelta045 wrote:

It seems to me that I have broken communication between the GLPI server and the FI agent.

Yes.

hdelta045 wrote:

Can I somehow check this connection?

You should see it in agent log, e.g.
[error] [http client] communication error: 500 Can't connect to your_server:443 (Bad file descriptor)

Or...
- Administrtion > FusionInventory > General > Agents management > Last contact date.
- /var/log/apache2/access.log
- /var/log/apache2/error.log

hdelta045 wrote:

I checked the collection of information on SNTN. On those network devices where this protocol is enabled, data is collected. Where it is not, it writes an entry to the log that skips inventory because it does not recognize the type

Sorry but i don't understand this

hdelta045 · 2020-08-28 06:24:01

WebGreg wrote:

hdelta045 wrote:

I checked the collection of information on SNTN. On those network devices where this protocol is enabled, data is collected. Where it is not, it writes an entry to the log that skips inventory because it does not recognize the type
Sorry but i don't understand this

Sorry, English is not my main language, so some things have to be written through the translator program.
I meant that if you run "fusioninventors-netdiscovery.bat -i --inventory --first 192.168.0.1 --last 192.168.0.254" from the command line on the computer, then the following can be seen from the logs displayed on the screen:
- devices on which the SNMP protocol is enabled transmit data to the server, for example;

<?xml version="1.0" encoding="UTF-8" ?>
<REQUEST>
<CONTENT>
<DEVICE>
<AUTHSNMP>1</AUTHSNMP>
<CONTACT>......@diskstation</CONTACT>
<DESCRIPTION>Linux nas 4.4.59+ #25426 SMP Tue Jul 14 19:47:36 CST 2020 aarch64</DESCRIPTION>
<DNSHOSTNAME>192.168.1.11</DNSHOSTNAME>
<IP>192.168.1.11</IP>
<IPS>
<IP>127.0.0.1</IP>
<IP>192.168.1.11</IP>
</IPS>
<LOCATION>Unknown</LOCATION>
<MAC>00:00:00:00:00:00</MAC>
<MANUFACTURER>Synology</MANUFACTURER>
<MODEL>DS418j</MODEL>
<NETBIOSNAME>SRV-NAS1</NETBIOSNAME>
<SERIAL>............</SERIAL>
<SNMPHOSTNAME>srv-nas1</SNMPHOSTNAME>
<TYPE>STORAGE</TYPE>
<UPTIME>35 days, 10:44:04.66</UPTIME>
<USERSESSION>SRV-NAS1</USERSESSION>
<WORKGROUP>WORKGROUP</WORKGROUP>
</DEVICE>
<MODULEVERSION>4.1</MODULEVERSION>
<PROCESSNUMBER>1</PROCESSNUMBER>
</CONTENT>
<DEVICEID>foo</DEVICEID>
<QUERY>NETDISCOVERY</QUERY>
</REQUEST>

- devices on which the SNMP is not turned on display

[info] [thread 1] # 262, Skipping inventory for 192.168.0.6 on not recognized device type

Actually, it is not that important at the moment. I can configure the collection of information through the Task Scheduler. This is not correct, but it works.

WebGreg wrote:

hdelta045 wrote:
Yes, I forced discovery, you can see the result in the screenshot.
I thought about this:

First try open site on the agent machine: h ttp://localhost:your_port/ (default is h ttp://localhost:62354/)
hdelta045 wrote:
As I understand it, first of all, you need to run discovery, and then inventory. Since it is not possible to start discovery, I do not see the need to start SNMP inventory now.
indeed
hdelta045 wrote:
It seems to me that I have broken communication between the GLPI server and the FI agent.
Yes.
hdelta045 wrote:
Can I somehow check this connection?
You should see it in agent log, e.g.
[error] [http client] communication error: 500 Can't connect to your_server:443 (Bad file descriptor)
Or...
- Administrtion > FusionInventory > General > Agents management > Last contact date.
- /var/log/apache2/access.log
- /var/log/apache2/error.log

After installing the agent on the computer, I immediately did just that.
There are no messages in the log files of the Apach2 web server, except for this

access.log
192.168.0.240 - - [28/Aug/2020:08:55:43 +0500] "GET /glpi/plugins/fusioninventory/?action=getConfig&machineid=note.<.....>.local-2020-08-26-10-25-15&task[Collect]=2.6 HTTP/1.1" 200 487 "-" "FusionInventory-Agent_v2.5.2"

No error records in error.log

[error] [http client] communication error: 500 Can't connect to your_server:443 (Bad file descriptor)
There is no such message

WebGreg · 2020-08-28 17:36:11

hdelta045 wrote:

Sorry, English is not my main language, so some things have to be written through the translator program.

You dont have to apologize. I am in exactly the same situation :-D

Strange... no errors. Looks OK but it's not OK. Maybe something goes wrong during the installation? GLPI? Agent? But it should shows any errors...

I use fusioninventory-agent-deployment.vbs for install Agent.

My SetupOptions = "/acceptlicense /execmode=Service /no-ssl-check /httpd-trust=192.168.1.101,192.168.5.201 /httpd-port=75232 /installtasks=Full /scan-homedirs /runnow /server='https://my.server.com/glpi/plugins/fusioninventory/' /html /local=C:\glpi_workfiles\FusionInventory\fusionInventoryLog.html /logfile=C:\glpi_workfiles\FusionInventory\fusioninventory-agent.log /S"

You didn't answer are h ttp://localhost:your_port/ (default is h ttp://localhost:62354/) works. If yes - delete fusioninventory-agent.log, click force inventory on website and show new log file. Maybe we can find something. Maybe you didn't install it as service?

And I found this: h ttps://forum.fusioninventory.org/showthread.php?tid=10300

Last edited by WebGreg (2020-08-28 23:06:24)

hdelta045 · 2020-08-31 08:16:54

WebGreg wrote:

hdelta045 wrote:
Sorry, English is not my main language, so some things have to be written through the translator program.

You dont have to apologize. I am in exactly the same situation :-D

Strange... no errors. Looks OK but it's not OK. Maybe something goes wrong during the installation? GLPI? Agent? But it should shows any errors...

I use fusioninventory-agent-deployment.vbs for install Agent.
My SetupOptions = "/acceptlicense /execmode=Service /no-ssl-check /httpd-trust=192.168.1.101,192.168.5.201 /httpd-port=75232 /installtasks=Full /scan-homedirs /runnow /server='h ttps://my.server.com/glpi/plugins/fusioninventory/' /html /local=C:\glpi_workfiles\FusionInventory\fusionInventoryLog.html /logfile=C:\glpi_workfiles\FusionInventory\fusioninventory-agent.log /S"
You didn't answer are h ttp://localhost:your_port/ (default is h ttp://localhost:62354/) works. If yes - delete fusioninventory-agent.log, click force inventory on website and show new log file. Maybe we can find something. Maybe you didn't install it as service?
And I found this: h ttps://forum.fusioninventory.org/showthread.php?tid=10300

A very strange thing happened over the weekend. The FI suddenly conducted a network discovery himself: the task was prepared on August 28, and completed on August 29. There are no errors in the logs. What happened I don't understand at all.

Yes it works. Log entry
[Mon Aug 31 08:55:06 2020][info] target server0: server h ttp://192.168.1.12/glpi/plugins/fusioninventory/
[Mon Aug 31 08:55:06 2020][info] sending prolog request to server0
[Mon Aug 31 08:55:07 2020][info] running task Deploy
[Mon Aug 31 08:55:07 2020][info] No Deploy job enabled or Deploy support disabled server side.
[Mon Aug 31 08:55:14 2020][info] running task Collect
[Mon Aug 31 08:55:14 2020][info] No Collect job enabled or Collect support disabled server side.
[Mon Aug 31 08:55:18 2020][info] running task NetDiscovery
[Mon Aug 31 09:08:57 2020][info] running task ESX
[Mon Aug 31 09:08:58 2020][info] No ESX job enabled or ESX support disabled server side.
[Mon Aug 31 09:09:02 2020][info] FusionInventory Agent memory usage: WSS=3444736 PFU=313073664
[Mon Aug 31 09:09:04 2020][info] running task Maintenance
[Mon Aug 31 09:09:08 2020][info] FusionInventory Agent memory usage: WSS=3309568 PFU=311918592

The agent works as a service.

Thanks for the installation script. I will try to use in my work

WebGreg · 2020-08-31 18:45:24

hdelta045 wrote:

A very strange thing happened over the weekend. The FI suddenly conducted a network discovery himself: the task was prepared on August 28, and completed on August 29. There are no errors in the logs. What happened I don't understand at all.

Me too, but the most important thing is that it already works

Any asset skipped during import? Did he import anything at all? If yes - now you can start with inventory task.

You marked "re-prepere a target-actor". Did he prepared next job? I don't understand how the agent wake up feature works. For me - the task is performed according to the time specified in general configuration > Inventory frequency (in hours).

hdelta045 · 2020-09-02 11:59:15

WebGreg wrote:

hdelta045 wrote:
A very strange thing happened over the weekend. The FI suddenly conducted a network discovery himself: the task was prepared on August 28, and completed on August 29. There are no errors in the logs. What happened I don't understand at all.
Me too, but the most important thing is that it already works

I do not like that this is unstable, it is not clear on what factors and on which side (client or server) the launch of information collection depends. Start the network diskovery on the new subnet today, the agent has been in the "prepared" state for 3 hours. At the same time, I see all devices on this subnet with a ping command. I'll wait until tomorrow, maybe it will work.

WebGreg wrote:

Any asset skipped during import? Did he import anything at all? If yes - now you can start with inventory task.

Yes, even after that, he added all the objects found to the "Unmanaged device" asset. I manually imported them into different assets: computers to computers, printers to printers, etc.

WebGreg wrote:

You marked "re-prepere a target-actor". Did he prepared next job? I don't understand how the agent wake up feature works. For me - the task is performed according to the time specified in general configuration > Inventory frequency (in hours).

No, I didn't. I suspect that this is due to the fact that I have not configured the launch of GLPI tasks through the CRON. The server tells me about it. I plan to solve this problem tomorrow.
I now run all tasks in manual mode through the forced start command.

WebGreg · 2020-09-14 16:30:58

hdelta045 wrote:

I do not like that this is unstable, it is not clear on what factors and on which side (client or server) the launch of information collection depends. Start the network diskovery on the new subnet today, the agent has been in the "prepared" state for 3 hours. At the same time, I see all devices on this subnet with a ping command. I'll wait until tomorrow, maybe it will work.

And how does it look like?
Today I had exactly the same problem. The server reset didn't help. But after reset automatic action taskscheduler - started working.

hdelta045 · 2020-09-16 06:54:47

It looks like this ...
We start network discovery. We are waiting for 18 hours. We get a list of hosts on the network. We start the network inventory. We are waiting for 18 hours. We receive data from the detected hosts.
Given the fact that computers on the network work around the clock without shutdown, the detection and collection of information works. It is very uncomfortable.
Perhaps this is a feature of the GLPI version 9.5.1. We will wait for the next update.

By the way, do you have print servers on your network?

Last edited by hdelta045 (2020-09-16 06:55:05)

WebGreg · 2020-09-16 08:35:57

hdelta045 wrote:

We start network discovery. We are waiting for 18 hours.

The time is problem now? If yes than check Home > Administration > FusionInventory > General setup > Inventory frequency (in hours).

***
Managed mode

This mode requires the agent to be run as a server process (daemon under Unix, service under Windows). The agent wake-up schedule is controlled from GLPI server, using PROLOG_FREQ setting. More precisely, the agent wakes up at a random time between 50% and 100% of this value, ie for 24H, it will executes sometimes between 12 and 24H. Additionaly, the server may also initiate additional out-of-schedule executions by sending HTTP requests to the agent.
***

hdelta045 wrote:

By the way, do you have print servers on your network?

No.

Last edited by WebGreg (2020-09-16 08:36:11)

hdelta045 · 2020-09-16 10:11:14

I know it. The problem is that with a forced start, both network discovery and network inventory are not started immediately, but only after 18 hours.

WebGreg · 2020-09-16 13:38:35

hdelta045 wrote:

I know it. The problem is that with a forced start, both network discovery and network inventory are not started immediately, but only after 18 hours.

Force start but from where? I do not use the button from the task configuration (I don't see any reaction here). For me, it's better to go to the agent's website and use a link "Force an Inventory" - works perfect.

hdelta045 · 2020-09-23 12:04:11

I am using the force start button from the task configuration. This is more convenient for me, since my organization has many remote offices, each office has its own subnet, and changes in software and hardware are rare. It's easier for me to start a forced start manually.
In general, this whole system somehow works. Not as much as we would like, but information about the hosts is being collected.

Forum GLPI-Project

Announcement

#1 2020-08-18 10:04:47

Network Discovery does not work in GLPI 9.5.1.

#2 2020-08-24 22:49:07

Re: Network Discovery does not work in GLPI 9.5.1.

#3 2020-08-25 11:05:52

Re: Network Discovery does not work in GLPI 9.5.1.

#4 2020-08-25 16:27:14

Re: Network Discovery does not work in GLPI 9.5.1.

#5 2020-08-26 11:04:26

Re: Network Discovery does not work in GLPI 9.5.1.

#6 2020-08-26 20:21:33

Re: Network Discovery does not work in GLPI 9.5.1.

#7 2020-08-27 05:57:07

Re: Network Discovery does not work in GLPI 9.5.1.

#8 2020-08-27 19:45:12

Re: Network Discovery does not work in GLPI 9.5.1.

#9 2020-08-28 06:24:01

Re: Network Discovery does not work in GLPI 9.5.1.

#10 2020-08-28 17:36:11

Re: Network Discovery does not work in GLPI 9.5.1.

#11 2020-08-31 08:16:54

Re: Network Discovery does not work in GLPI 9.5.1.

#12 2020-08-31 18:45:24

Re: Network Discovery does not work in GLPI 9.5.1.

#13 2020-09-02 11:59:15

Re: Network Discovery does not work in GLPI 9.5.1.

#14 2020-09-14 16:30:58

Re: Network Discovery does not work in GLPI 9.5.1.

#15 2020-09-16 06:54:47

Re: Network Discovery does not work in GLPI 9.5.1.

#16 2020-09-16 08:35:57

Re: Network Discovery does not work in GLPI 9.5.1.

#17 2020-09-16 10:11:14

Re: Network Discovery does not work in GLPI 9.5.1.

#18 2020-09-16 13:38:35

Re: Network Discovery does not work in GLPI 9.5.1.

#19 2020-09-23 12:04:11

Re: Network Discovery does not work in GLPI 9.5.1.

Board footer