NetXMS Support Forum

In console version 2.2.13, I am able to move DCI template items to template groups. As template groups don't support DCI items, they disappear.

Is this expected behavior?

I tried discovering some Radwin Jet devices. Subscriber units ("HSU") discovered fine using SNMPv2c.

Base stations ("HBS"), however, didn't discover, even though discovery configuration had valid IP ranges and community strings.

If I manually add a base station to discovery by IP, I observe that NetXMS runs through all the community strings first with v2c, and then with v1. The valid v1 string returns a response like this:

(tcpdump)
12:34:18.143917 IP aaaa.38220 > bbbb.161:  C="xxxx" GetRequest(58)  .1.3.6.1.2.1.1.2.0 .1.3.6.1.2.1.1.1.0 .1.3.6.1.4.1.35160.1.1.0
12:34:18.158012 IP bbbb.161 > aaaa.38220:  C="xxxx" GetResponse(58)  genErr@3 .1.3.6.1.2.1.1.2.0= .1.3.6.1.2.1.1.1.0= .1.3.6.1.4.1.35160.1.1.0=

I also note that if I use snmpget:

[jaustin@jaustin tmp]$ snmpget -v1 -c xxxx bbbb  .1.3.6.1.2.1.1.2.0 .1.3.6.1.2.1.1.1.0 .1.3.6.1.4.1.35160.1.1.0
12:36:01.720684 IP aaaa.36646 > bbbb.161:  C="xxxx" GetRequest(59)  .1.3.6.1.2.1.1.2.0 .1.3.6.1.2.1.1.1.0 .1.3.6.1.4.1.35160.1.1.0
12:36:01.737880 IP bbbb.161 > aaaa.36646:  C="xxxx" GetResponse(59)  genErr@3 .1.3.6.1.2.1.1.2.0= .1.3.6.1.2.1.1.1.0= .1.3.6.1.4.1.35160.1.1.0=
Error in packet
Reason: (genError) A general failure occured
Failed object: iso.3.6.1.4.1.35160.1.1.0

12:36:01.737996 IP aaaa.36646 > bbbb:160  C="xxxx" GetRequest(42)  .1.3.6.1.2.1.1.2.0 .1.3.6.1.2.1.1.1.0
12:36:01.757800 IP bbbb.161 > aaaa.36646:  C="xxxx" GetResponse(66)  .1.3.6.1.2.1.1.2.0=.1.3.6.1.4.1.4458.20.5.1.1 .1.3.6.1.2.1.1.1.0="Wireless Link"
iso.3.6.1.2.1.1.2.0 = OID: iso.3.6.1.4.1.4458.20.5.1.1
iso.3.6.1.2.1.1.1.0 = STRING: "Wireless Link"

-----------

So snmpget will discard the invalid OID and try again.

I note that 1.3.6.1.4.1.35160 is from the ping3 device driver.

I also note that I *can* set snmp.testOID as an override on a device *that already exists*, but this does not help devices that are failing discovery.

Any recommendations? I don't have any ping3 devices, so theoretically I could disable the driver; however, that doesn't fix the underlying logical problem.