Activating SNMP V3 on a QNAP : sending get-request ignored by netXMS

[petoulachi]

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

[alk]

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).

[petoulachi]

Hello !
I can confirm that with the latest server version 7.0.0 this issue is resolved !