-
Notifications
You must be signed in to change notification settings - Fork 126
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Computers with SNMP - detection issue #496
Comments
Here's why: Scanning a computer (or other device) with snmp enabled (this is bare minimum net-snmp configuration on the target. It doesn't return the ifMIB responses) ]# ./fusioninventory-netdiscovery --first 128.40.73.248 --last 128.40.73.248 <?xml version="1.0" encoding="UTF-8" ?>
<REQUEST>
<CONTENT>
<DEVICE>
<AUTHSNMP>1</AUTHSNMP>
<CONTACT>Root <root@localhost> (configure /etc/snmp/snmp.local.conf)</CONTACT>
<DESCRIPTION>Linux msslyz.mssl.ucl.ac.uk 2.6.32-696.23.1.el6.x86_64 #1 SMP Sat Feb 10 11:10:31 EST 2018 x86_64</DESCRIPTION>
<DNSHOSTNAME>msslyz.mssl.ucl.ac.uk</DNSHOSTNAME>
<IP>128.40.73.248</IP>
<LOCATION>Unknown (edit /etc/snmp/snmpd.conf)</LOCATION>
<MANUFACTURER>Net-SNMP</MANUFACTURER>
<MODEL>Linux</MODEL>
<SNMPHOSTNAME>msslyz.mssl.ucl.ac.uk</SNMPHOSTNAME>
<TYPE>COMPUTER</TYPE>
<UPTIME>1 day, 08:33:11.68</UPTIME>
</DEVICE>
<MODULEVERSION>2.6</MODULEVERSION>
<PROCESSNUMBER>1</PROCESSNUMBER>
</CONTENT>
<DEVICEID>foo</DEVICEID>
<QUERY>NETDISCOVERY</QUERY>
</REQUEST> Scanning one without snmp enabled: ]# ./fusioninventory-netdiscovery --first 128.40.69.174 --last 128.40.69.174 <?xml version="1.0" encoding="UTF-8" ?>
<REQUEST>
<CONTENT>
<DEVICE>
<DNSHOSTNAME>msslal.mssl.ucl.ac.uk</DNSHOSTNAME>
<IP>128.40.69.174</IP>
<MAC>50:9a:4c:5d:d7:52</MAC>
<NETPORTVENDOR /></DEVICE>
<MODULEVERSION>2.6</MODULEVERSION>
<PROCESSNUMBER>1</PROCESSNUMBER>
</CONTENT>
<DEVICEID>foo</DEVICEID>
<QUERY>NETDISCOVERY</QUERY>
</REQUEST> I'd call this a definite fusioninventory bug: It shouldn't be looking at the ifMIB MAC responses at all during netdiscovery operations, or at least be able to cope with bogus/no response/null response/not matching ARP/nmap (this might happen if the SNMP target is actually a transparent SNMP proxy or if snmp is somehow misconfigured) |
This gets a little more interesting These SNMP returns are somehow coming from the 10Gb cards installed on the systems, not the computers themselves. Again, they're not being linked to the computers and if you do move the network devices to the computer, they're redetected as new devices on the next network discovery In these cases, macs ARE showing, but they're still not being linked in correctly. <?xml version="1.0" encoding="UTF-8" ?>
<REQUEST>
<CONTENT>
<DEVICE>
<DNSHOSTNAME>msslak-a.mssl.ucl.ac.uk</DNSHOSTNAME>
<IP>128.40.69.218</IP>
<MAC>00:07:43:31:fc:70</MAC>
<NETPORTVENDOR>Chelsio Communications</NETPORTVENDOR>
</DEVICE>
<MODULEVERSION>2.6</MODULEVERSION>
<PROCESSNUMBER>1</PROCESSNUMBER>
</CONTENT>
<DEVICEID>foo</DEVICEID>
<QUERY>NETDISCOVERY</QUERY>
</REQUEST> <?xml version="1.0" encoding="UTF-8" ?>
<REQUEST>
<CONTENT>
<DEVICE>
<DNSHOSTNAME>msslay.mssl.ucl.ac.uk</DNSHOSTNAME>
<IP>128.40.69.239</IP>
<MAC>00:10:9b:13:dd:68</MAC>
<NETPORTVENDOR>Emulex</NETPORTVENDOR>
</DEVICE>
<MODULEVERSION>2.6</MODULEVERSION>
<PROCESSNUMBER>1</PROCESSNUMBER>
</CONTENT>
<DEVICEID>foo</DEVICEID>
<QUERY>NETDISCOVERY</QUERY>
</REQUEST> |
I don't know enough about the internal structure of the agent, but it seems to me that the following is happening: If there is a SNMP return, it's preferred to the simple nmap information (IP/ARP) If the SNMP return isn't for a SNMP-supported device (network equipment/printer) or contains a bogus MAC or serial numbers (At least one printer here has been known to return a serial number of "00000000000000" after a service tech changed out the logic board) then the entry isn't parsed for the type of device that's expected (In this case: computer) and ends up being dumped through to unmanaged. Am I sniffing in the right direction? |
Hi @Stoatwblr About the "10Gb cards" point, that's weird, but I understand the ethernet cards have embedded snmp supports. This is a really specific case. You should open a new issue eventually providing a snmpwalk to we can see better how to handle this case. For the last case, in fact, the agent merges the information from SNMP, Ping & arp table (arp table since 2.4.1 as we get rid of nmap). Mac from arp table always replace the mac found from SNMP. Have you tried latest releases ? 2.4.2 was release last week. If you still got a wrong mac, please provide us the output of |
Computers already present in GLPI that have SNMP enabled are having their network devices show up as managed entities during each network discovery scan of the network.
The devices appear as MAC only (no IP) and with sysdescr present, but nothing else.
If they are attached to their registered computer and the unmanaged entity deleted, they simply reappear at the next discovery scan.
This problem has been present for a couple of years and is present right up to the latest dev build.
The text was updated successfully, but these errors were encountered: