QNAP snmpwalk

[Wolvverine]

snmpwalk_qnap.txt

[g-bougard]

Hi @Wolvverine your walk does not include the SNMPv2-MIB::sysObjectID or .1.3.6.1.2.1.1.2 value. Did you follow the snmpwalk output documentation ? Maybe your walk is not complete.

[Wolvverine]

new upload

[g-bougard]

Humpf, it seems your walk start from .1.3.6.1.2.1.1.9.1.2.1 ... some lines should has been removed at the beginning.

[Wolvverine]

and MIB database: NAS.mib.txt

[g-bougard]

Hi @Wolvverine about my last comment, I mean SNMPv2-MIB::sysObjectID or .1.3.6.1.2.1.1.2 value is still missing as first lines of your walk seems to have not been included. The MIB won't make that lines appear by themselves.

[Wolvverine]

Maybe because I'm walk in v3 ? .1.3.6.1.4.1.8072.1.2.1.1.4.0.8.1.3.6.1.2.1.1.2.127 = STRING: mibII/sysObjectID

[g-bougard]

@Wolvverine I don't think so. Maybe you truncated some lines when updating the walk. Can you double-check and attach it in a new comment ?

[Wolvverine]

snmpalk_command | wc -l 3765

[g-bougard]

The file you provided still have 3799 lines... which is larger than 3765. Btw I guess the user you're using may not have a full access on the device OIDs.

What are you get while doing something like: snmpget -v2c -c public "serverIP" 1.3.6.1.2.1.1.2.0 but changing the authentication by your snmp v3 authentication ?

[Wolvverine]

without .1 .1.3.6.1.2.1.1.1.0 = STRING: Linux TS-221 4.3.3

[Wolvverine]

@g-bougard some lines with hex value are split to 2 lines in editor

[g-bougard]

Do you mean you have not result with 1.3.6.1.2.1.1.2.0 ? If you don't have any result for this OID, you may have an issue with your user or your device can't be discovered by the agent (but this would be the first time I hear about a SNMP device not providing this OID).

[Wolvverine]

result with 1.3.6.1.2.1.1.2.0 .1.3.6.1.2.1.1.2.0 = OID: .1.3.6.1.4.1.24681

[g-bougard]

Okay, can you complete with this ones:

1.3.6.1.2.1.1.3.0
1.3.6.1.2.1.1.4.0
1.3.6.1.2.1.1.5.0
1.3.6.1.2.1.1.6.0

This should be sufficient do complete you walk manually. Thank you

[Wolvverine]

.1.3.6.1.2.1.1.3.0 = Timeticks: (42826661) 4 days, 22:57:46.61 .1.3.6.1.2.1.1.4.0 = STRING: .1.3.6.1.2.1.1.5.0 = STRING: QNAP .1.3.6.1.2.1.1.6.0 = STRING:

[Wolvverine]

Maybe it is worth adding these manual steps to the documentation, it will be faster.

[g-bougard]

You were the first for which these steps was necessary. The standard snmpwalk command from the documentation was sufficient for dozens of people before.

[g-bougard]

Hi @Wolvverine in fact, it seems SNMP with QNAP devices makes a problem to be inventoried if we can't find the hostname by default from .1.3.6.1.2.1.1.5.0. I proposed a PR #567 on agent to set a default hostname when we find a serial number (the case with your walk). You still can try the patch from this PR to see if it fixes your case.

After that, I updated the sysobject.ids in cfafee48b2 to include QNAP support, but QNAP was still supported as the description matches the Linux TS- pattern. In debug mode, you'll obtain a warning telling sysobjetcID is invalid as we only find the manufacturer id, but this is followed with partial match and is sufficient.

Then I'm closing this issue here. Feel free to open a FusionInventory-Agent issue linking this one if nor the PR nor the last commit here helps to inventory your QNAP devices.

[Wolvverine]

this is hostname , in hex with -Ih .1.3.6.1.2.1.1.5.0 = Hex-STRING: 51 4E 41 50 without: .1.3.6.1.2.1.1.5.0 = STRING: QNAP