NetXMS Support Forum

As per your example above, JSON parser is failing on this part:
"antenna_gps": {"py/tuple": [01.12343455, 02.45542]}

You can check the syntax e.g. with this tool
https://jsonformatter.curiousconcept.com

So I suppose that the data returned by this web service might change time after time and sometimes the data confirms with what the JSON parser expects.

Yes, the log file will be useful

In current version of NetXMS JSON parser is failing on the leading zeroes of 01.12343455, 02.45542

besides from that the parsert should be able to extract the part you need, e.g. for time the path in document should be just "time".
So DCI parameter would be looking Name_of_your_web_service_definition:time

Do you encounter this when discovering direct from server, via proxy or in both cases?

Если вы не хотите, чтоб какие-то из интерфейсов влияли на статус, можно например их вообще не создавать - в Hook::CreateInterface добавить скрипт, который для этого типа устройства и для определенных имен интерфейсов вернет false.

Или если это не то, что вы хотите, то расшифруйте, что значит "читать то, что мне надо".

Статус узла определяется статусом его интерфейсов, алармов (если они есть) и могут быть еще DCI, у которых стоит галочка, то значение этого DCI управляет статусом.

Вопросик - это статуc UNKNOWN. Тут он у интерфейсов и от них унаследовался на узел. У интерфейса статус UNKNOWN может быть, когда netxms не может определить статус - нет связи по SNMP и одновременно с этим невозможно пропинговать интерфейс (например, у интерфейса нет IP адреса).

You can ping external IP address. For that set up the DCI on a node that has NetXMS agent (that could be the same node where you have netxms server - normally you should have netxms agent running there). Select DCI origin "Agent" and use ICMP.PacketLoss(8.8.8. parameter.

Are you sure that the other monitoring software is using exactly SNMP, not some proprietary protocol? Does it use standard SNMP port?
You can try capturing communication of that software to the router with Wireshark and compare what network packets it's actually sending.

also you can try getting some data via SNMP using snmpget package from netsnmp software https://sourceforge.net/projects/net-snmp/files/net-snmp%20binaries/5.5-binaries/net-snmp-5.5.0-2.x64.exe/download

Mapping tables might better just for the reason of not disclosing the addresses to 3-rd party and for reliability.

You can add this script to script library and then use macro %[name_of_script] to get mac address of that node's interface that has primary IP address.
mac = NULL;
for (i:$node->interfaces)
{
  if ($node->ipAddr == i->ipAddr) mac = i->macAddr;
}
return mac;

TCP connection to port 44818 happens on the next step of configuration poll - that's an attempt to connect via Ethernet/IP protocol. It's a protocol used in industrial devices. Your router is answering with RST - it says that this port is closed. This is normal.
The part related to SNMP is above. You can see that NetXMS is sending SNMP request that have three OIDs in it - 1.3.6.1.2.1.1.2.0 and so on. The is no reply, so the request is being repeated multiple time.

It could be that the router does not like that three OIDs are requested simultaneously. You can try turning on server configuration parameter SNMP.Discovery.SeparateProbeRequests, then only one OID will be requested at a time.

Note these lines in configuration poll:
[15.01.2021 12:10:10]    Checking SNMP...
[15.01.2021 12:10:24]    No response from SNMP agent
For some reasons netxms is not able to receive response from that router. There are two options:
- problems with network/firewall/etc so that packets are not getting to where they should
- this router does not understand the way how netxms created SNMP request and does not reply.

I would suggest capturing communication between netxms and this router using tcpdump or Wireshark. If you need help in doing that, please inform, if your netxms is running on linux or windows.

As per above screenshot - you are using parameter of origin "Internal". In this case, the parameter should be just "Icmp.PacketLoss" and it will return stats for pinging node's primary host name. Option for specifying IP address in brackets if for situation, when you set checkbox "Collect ICMP response statistics for this interface" in properties of an interface of a node.

Are you monitoring any other SNMP devices (just to exclude general server problem regarding SNMP like closed ports on firewall)?

Check SNMP version in node properties and community string. Try doing Full configuration poll. If there were problems communicating with node via SNMP when the node was added, netxms will not set isSNMP flag and will not try communicating via SNMP. This flag can be visible in Object Details on the right-hand-side under Capabilities.

There are two ways of doing ICMP pinging.
- Collecting parameter from agent. Agent should have ping.nsm subagent enabled. E.g. Icmp.PacketLoss(target) - origin in DCI properties should be "Agent".
- Server periodically pings nodes and collects statistics. This statistics are available via DCIs of origin "Internal".

See for more information https://www.netxms.org/documentation/adminguide/icmp-ping.html

Для VLANов что-то может быть просто не реализовано.
Чтоб лучше понять, что происходит - в Tools->Sever console можно дать команду
trace <id одной ноды> <id другой ноды>