<![CDATA[Radwin discovery failing]]>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.

]]>https://forum.netxms.org/topic/5929/radwin-discovery-failingRSS for NodeFri, 13 Nov 2026 16:07:29 GMTMon, 06 May 2019 20:39:22 GMT60<![CDATA[Reply to Radwin discovery failing on Fri, 16 Apr 2021 17:53:18 GMT]]>@victor said in Radwin discovery failing:

Just added two new configuration options for version 3.3: driver blacklisting and switching SNMP probing into one OID per request mode. Either one should fix this issue.

Best regards,
Victor

This configuration option for SNMP probing resolved a tough issue I had been trying to resolve for a year.  I agree with jermudgeon... you rock, Victor!

]]>https://forum.netxms.org/post/29878https://forum.netxms.org/post/29878Fri, 16 Apr 2021 17:53:18 GMT<![CDATA[Reply to Radwin discovery failing on Mon, 09 Mar 2020 20:57:25 GMT]]>Saw that, Victor -- you rock! Thanks.

]]>https://forum.netxms.org/post/27538https://forum.netxms.org/post/27538Mon, 09 Mar 2020 20:57:25 GMT<![CDATA[Reply to Radwin discovery failing on Mon, 09 Mar 2020 20:56:27 GMT]]>Just added two new configuration options for version 3.3: driver blacklisting and switching SNMP probing into one OID per request mode. Either one should fix this issue.

Best regards,
Victor

]]>https://forum.netxms.org/post/27537https://forum.netxms.org/post/27537Mon, 09 Mar 2020 20:56:27 GMT<![CDATA[Reply to Radwin discovery failing on Tue, 03 Mar 2020 18:29:03 GMT]]>Here is the promised capture file. (Regular SNMP polling stripped out.) It shows the response to the discovery packet when ping3 is enabled, and the response when ping3 is disabled.

ping3-radwin.pcapng

]]>https://forum.netxms.org/post/27500https://forum.netxms.org/post/27500Tue, 03 Mar 2020 18:29:03 GMT<![CDATA[Reply to Radwin discovery failing on Mon, 13 May 2019 14:58:16 GMT]]>I will provide a tcpdump as soon as I can. I'm running into an odd situation elsewhere and am likely going to start the db again from scratch first.

]]>https://forum.netxms.org/post/25694https://forum.netxms.org/post/25694Mon, 13 May 2019 14:58:16 GMT<![CDATA[Reply to Radwin discovery failing on Wed, 08 May 2019 07:04:24 GMT]]>Hi,

that's quite unusual behavior for SNMP agent to return error on whole packet due to one invalid OID, but server definitely should be modified to handle such response correctly. Is it possible to provide us remote access to one such device for debugging? If not, could you provide full packet capture (output of tcpdump -w)?

Best regards,
Victor

]]>https://forum.netxms.org/post/25680https://forum.netxms.org/post/25680Wed, 08 May 2019 07:04:24 GMT<![CDATA[Reply to Radwin discovery failing on Mon, 06 May 2019 22:20:57 GMT]]>I also tried manually adding nodes. Even with manual binding of SNMP string and version, discovery tries all configured SNMP community strings. This is surprising.

Interface discovery consequently fails due to the response (ping3 driver):

14:17:45.602526 IP aaaa.35312 > bbbb.snmp:  C="xxxx" GetRequest(59)  system.sysObjectID.0 system.sysDescr.0 E:35160.1.1.0
14:17:45.630758 IP bbbb.snmp > aaaa.35312:  C="xxxx" GetResponse(59)  genErr@3 system.sysObjectID.0= system.sysDescr.0= E:35160.1.1.0=

]]>https://forum.netxms.org/post/25677https://forum.netxms.org/post/25677Mon, 06 May 2019 22:20:57 GMT