Radwin discovery failing

[jermudgeon]

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.

[jermudgeon]

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=

[victor]

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

[jermudgeon]

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.

[jermudgeon]

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

[victor]

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

[jermudgeon]

Saw that, Victor -- you rock! Thanks.

[BobArch]

@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!