NetXMS Support Forum

Version:
NetXMS Server Version 2.2.15 Build 9523 (d67b96f) (UNICODE)
NXCP: 4.48.1.18 (AES-256, Blowfish-256, 3DES, AES-128, Blowfish-128)
Built with: g++ (Debian 6.3.0-18+deb9u1) 6.3.0 20170516


I have some Radwin HSU devices that have odd SNMP characteristics. (For example, the ping3 driver breaks discovery of Radwin devices.)

They don't report their management IP on the correct interface -- the management interface is discoverable but has a loopback IP on it rather than the correct management IP.

One consequence is that the correct network subnet is not created upon device discovery, as NetXMS has no way of determining the correct mask for the IP, and we are not currently discovering the parent router(s) that provide the gateway (and correct mask) for these devices.

Even though these discovered nodes do not appear in "Entire Network", I am able to bind the "missing" devices to a container using the following function:
/* Function utilized to find objects that are missing a parent subnet
* in Entire Network. This should not be happening, but it do.
*
*/

sub BindUnboundNodes() {
parents = GetNodeParents($node);

parentContainers = 0;
foreach(p : parents) {
    // we are only interested in subnets
    if (p->type == 1) {
// if we find any subnet at all, this object is bound
            parentContainers++;
       
    }
}

toBind = parentContainers == 0;

if (toBind) {
    trace(0, "Node '" . $node->name . "' has no parent subnet.");
}

return toBind;
}

Another odd behavior is that if I put the relevant discovery networks into a zone other than Default, devices fail to be added at all.

Hi!

If I correctly identified devices it seems that they have management IP address and mask in private MIB: http://www.circitor.fr/Mibs/Html/R/RADWIN-MIB-WINLINK1000.php#winlink1000OduAdmAddres. Can you check if this MIB is supported and that device returns correct information? If yes then we cn create driver that will utilize private MIB to create management interface object.

Best regards,
Victor

Thanks, Victor.

I can confirm that this works for both base stations and clients:
[jaustin@jaustin applications]$ snmpwalk -v1 -c xxxxx <mgmt address> 1.3.6.1.4.1.4458.1000.1.1.6
iso.3.6.1.4.1.4458.1000.1.1.6.0 = IpAddress: <mgmt IPv4 address>
[jaustin@jaustin applications]$ snmpwalk -v1 -c xxxxx <mgmt address> 1.3.6.1.4.1.4458.1000.1.1.7
iso.3.6.1.4.1.4458.1000.1.1.7.0 = IpAddress: <mgmt IPv4 mask>

Would a Radwin driver fix the problem of the response to the ping3 driver? Currently I'm having to disable the ping3 driver, as I don't have any ping3 devices, and the Radwins reject the entire SNMP discovery query (currently three OIDs, two in mib2 and one from ping3 private, IIRC).