Skip to content
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

Open
Stoatwblr opened this issue Apr 27, 2018 · 4 comments
Open

Computers with SNMP - detection issue #496

Stoatwblr opened this issue Apr 27, 2018 · 4 comments

Comments

@Stoatwblr
Copy link
Contributor

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.

@Stoatwblr
Copy link
Contributor Author

Stoatwblr commented Apr 29, 2018

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 &lt;root@localhost&gt; (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)

@Stoatwblr
Copy link
Contributor Author

Stoatwblr commented Apr 29, 2018

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>

@Stoatwblr
Copy link
Contributor Author

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?

@g-bougard
Copy link
Contributor

Hi @Stoatwblr
you have a mix of different issues here. But for the most important and matching the issue title, I think you should create a plugin issue and discuss with @ddurieux to see how we can skip during discovery IPs still known as computer.

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 arp -a for the related ip.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants