Hello all,
I'm new here so please be nice :)
I've just installed a netXMS server on my network (192.168.88.0/24). It works as intended with all nodes in SNMP V3 sending traps.
Now I'm trying to add my QNAP NAS that is on a separated network (192.168.89.0/24).
Using SNMPV1, it works. I received traps.
But if I try to activate SNMP V3, pulling is working, but the traps aren't.
The QNAP is first sending a "get-request" on port UDP 162
Frame 76985: Packet, 123 bytes on wire (984 bits), 123 bytes captured (984 bits) on interface \Device\NPF_{C16F6D7C-17E5-4278-B0F9-851AEB13E1D9}, id 0
Internet Protocol Version 4, Src: 192.168.89.9, Dst: 192.168.88.32
0100 .... = Version: 4
.... 0101 = Header Length: 20 bytes (5)
Differentiated Services Field: 0x00 (DSCP: CS0, ECN: Not-ECT)
Total Length: 109
Identification: 0x0f6c (3948)
010. .... = Flags: 0x2, Don't fragment
...0 0000 0000 0000 = Fragment Offset: 0
Time to Live: 63
Protocol: UDP (17)
Header Checksum: 0xf999 [validation disabled]
[Header checksum status: Unverified]
Source Address: 192.168.89.9
Destination Address: 192.168.88.32
[Stream index: 15]
User Datagram Protocol, Src Port: 40299, Dst Port: 162
Source Port: 40299
Destination Port: 162
Length: 89
Checksum: 0x8a97 [unverified]
[Checksum Status: Unverified]
[Stream index: 2066]
[Stream Packet Number: 6]
[Timestamps]
[Time since first frame: 5.005006100 seconds]
[Time since previous frame: 1.000912100 seconds]
UDP payload (81 bytes)
Simple Network Management Protocol
msgVersion: snmpv3 (3)
msgGlobalData
msgID: 1009582008
msgMaxSize: 65507
msgFlags: 04
.... .1.. = Reportable: Set
.... ..0. = Encrypted: Not set
.... ...0 = Authenticated: Not set
msgSecurityModel: USM (3)
msgAuthoritativeEngineID: <MISSING>
msgAuthoritativeEngineBoots: 0
msgAuthoritativeEngineTime: 0
msgUserName: <MISSING>
msgAuthenticationParameters: <MISSING>
msgPrivacyParameters: <MISSING>
msgData: plaintext (0)
plaintext
contextEngineID: 80001f8880b35b0f3ea69ec76a00000000
1... .... = Engine ID Conformance: RFC3411 (SNMPv3)
Engine Enterprise ID: net-snmp (8072)
Engine ID Format: Reserved/Enterprise-specific (128): Net-SNMP Random
Engine ID Data: b35b0f3e
Engine ID Data: Creation Time: Oct 8, 2026 15:46:14 Romance Daylight Time
contextName: <MISSING>
data: get-request (0)
get-request
request-id: 59606151
error-status: noError (0)
error-index: 0
variable-bindings: 0 items
This get-request is ignored by netXMS
2026.10.08 16:12:27.977 *D* [snmp.trap ] SNMPTrapReceiver: looking for SNMP security context for node 192.168.89.9 NAS Camera
2026.10.08 16:12:27.977 *D* [snmp.trap ] SNMPTrapReceiver: received PDU of type 0 from 192.168.89.9
2026.10.08 16:12:27.977 *D* [snmp.trap ] SNMPTrapReceiver: SNMP credential validation failed for trap from 192.168.89.9, dropping
2026.10.08 16:12:27.977 *D* [obj.macro ] ExpandText(sourceObject=451 template='SNMP trap from %<sourceIP> rejected: %<reason> (SNMP version %<snmpVersion>)' alarm=0 event=1245 instance='(null)')
2026.10.08 16:12:27.977 *D* [event.corr ] CorrelateEvent: event SYS_SNMP_TRAP_AUTH_FAILURE id 1245 source NAS Camera [451]
2026.10.08 16:12:27.977 *D* [event.corr ] CorrelateEvent: finished, rootId=0
2026.10.08 16:12:27.977 *D* [event.proc ] EVENT SYS_SNMP_TRAP_AUTH_FAILURE [170] at {0} (ID:1245 F:0x0001 S:1 TAGS:"") FROM NAS Camera: SNMP trap from 192.168.89.9 rejected: USM user name does not match (SNMP version 3)
2026.10.08 16:12:27.977 *D* [event.policy ] EPP: processing event 1245
2026.10.08 16:12:27.977 *D* [event.policy ] Event 1245 match EPP rule 55
2026.10.08 16:12:27.977 *D* [obj.macro ] ExpandText(sourceObject=451 template='SNMP_TRAP_AUTH_FAILURE_%i' alarm=0 event=1245 instance='(null)')
2026.10.08 16:12:27.977 *D* [obj.macro ] ExpandText(sourceObject=451 template='%m' alarm=0 event=1245 instance='(null)')
2026.10.08 16:12:27.977 *D* [obj.macro ] ExpandText(sourceObject=451 template='' alarm=0 event=1245 instance='(null)')
If you have any idea about what is wrong in here, your help is welcome :)
Hi,
This is a bug on server side, not your configuration - I've created a ticket: https://github.com/netxms/netxms/issues/3752
That get-request is SNMPv3 engine ID discovery, which means QNAP sends informs rather than traps - for informs sender first has to ask the receiver for its engine ID. Since 6.1 server checks credentials of every packet coming to the trap port before it looks what kind of packet it is. Discovery request has empty user name by design, so it's rejected as "USM user name does not match" and never answered. Your other devices send plain v3 traps, which don't need discovery.
Until it's fixed, turn credential check off for this node only: add custom attribute SysConfig:SNMP.Traps.ValidateCredentials with value false to the NAS node. No restart needed, but it requires server 6.2.3 or later. I haven't tested this with QNAP.
Note: authenticated v3 messages are still verified with the node's keys, so user name, authentication and encryption in QNAP trap settings should match SNMP credentials of the node (or separate trap credentials on node's SNMP property page).