NetXMS Support Forum

There was a bug related to use of case operator. It's now fixed, will be included in next release which is planned next week.

Ну если на машине, откуда посылаются запросы, несколько интерфейсов, то может с разных адресов запросы идут. IPv6 тут не должно быть - указан IPv4 адрес.

Я бы начал с дампа пакетов с помощью tcpdump или wireshark чтоб понять чем отличаются пакеты snmpwalk и nxsnmpwalk

There is EnableTCPProxy parameter in agent config file.
And there's a demo java app that uses this functionality: https://github.com/netxms/netxms/blob/master/src/client/nxtcpproxy/src/main/java/org/netxms/tcpproxy/TcpProxyApp.java

The idea is that this java app connects to the server using same protocol that nxmc uses. Then this app can establish tcp tunnel via the agent. And if I remember correctly, the test app just opens a tcp port locally that corresponds to the tunneled port.

There's a forum post with more details: https://www.netxms.org/forum/general-support/tcp-proxy-functionality/

There was an issue that when users that were synchronized by ldap tried to login with wrong password, this error was put in the log. Looks like it was fixed today, so should be in next patch release
https://track.radensolutions.com/issue/NX-2254

Just to mention - agent log parser policies (this stuff in configured in templates) can execute actions directly on agent, even without communication to the server. So theoretically agent can watch some log file of ssh client and call some script to reestablish connection. I doubt that this is the best way, but might be convenient from deployment standpoint.

Hi!

Actually, there is no write access to mapping tables from NXSL. We can use either persistent storage or custom attributes. Persistent storage record length is limited to 2000 chars and unlimited for custom attributes, so let's use them.

There are two scripts, first one should be set as EPP filter script so it will be executed when event comes:

s = GetCustomAttribute($node, "EventTimestamps");
if (s != NULL and s != "")
{
  a = s->split(",");
}
else
{
  a = %();
}
if (a->size < 2000) a->append(time());
SetCustomAttribute($node, "EventTimestamps", ArrayToString(a,","));
return true;
Every time when event comes, this script will add unixtime to the custom attribute on the node. There's a limit of 2000 records so that the string won't grow endlessly.

The second script should be executed periodically - we can use script DCI with needed interval, e.g. 1 hour or 24 hours. You can just use interval or you can set cron schedule so that this DCI get's collected at exact moment:

period = 3600 * 24; // in seconds

s = GetCustomAttribute($node, "EventTimestamps");
a2 = %();
now = time();

if (s != NULL and s != "")
{
  a = s->split(",");
  for (i = a->minIndex; i <= a->maxIndex; i++)
  {
    if (a[i] > now - period) a2->append(a[i]);
  }
}

SetCustomAttribute($node, "EventTimestamps", ArrayToString(a2,","));
return a2->size;

The script goes through all recorded timestamps, throws away those that are older then specified period, saves updated custom attribute and counts the number of records.

Hi!

Currently server uses one certificate for TLS connection and to issue agent certificates. To use this workflow you'd need a certificate from Certificate Authority with CA flag set - this might be problematic or expensive.

I've created an issue in our bug tracker with the idea to have two separate certificates on the server: https://track.radensolutions.com/issue/NX-2256
Until this is implemented, you theoretically can just obtain a certificate without CA flag and put it as ServerCertificate in server config. And you can put your current server certificate into TrustedCertificate parameter. This way your current agents would be able to connect and work, but server won't be able to issue new agent certificates when they expire.

The other approach could be some sort of VPN between agent and server.

By the way, do you have some information on how exactly this firewall does the checking - it works as man-in-the-middle or establishes a second connection to the server to get the certificate?

This looks strange. I suggest you to minimize the code to get it as short as possible with this bug replicating.

Does it acts the same if you do "Execute server script" on any node and put the code there?

For debugging you can also trace the number of elements of array, it's size attribute, e.g. retval->size

Log parser policy is probably a nicer approach as there's no need to maintain any scripts on agents. With this there are two approaches:

1) You can use repeat interval functionality of log parser. E.g. you can set Repeat interval to 24 hours. Repeat count should be set to 1 (if it's 0, this functionality is disabled). Reset repeat count should be unchecked.
So now we have a 24-hour long rolling window and on each new match generated event will have the number of matches happened within this window.

Now the question comes - how can we save the value from event processing policy rule. We can create a DCI with origin "push". To this DCI we can send values from NXSL script (and also from command line utilities nxpush or nxapush (this one comes with the agent).

So imagine that on the node where log monitoring is set up we have push DCI with parameter "log_stats". In the EPP rule that reacts to our log monitoring event we can have the following filter script:
dci_id = FindDCIByName($node, "log_stats");
if (dci_id > 0) PushDCIData($node, dci_id, $event->$1);


It's called "filter scrip" as original idea is that EPP rule is processed or not depending on what that script returns. But we can just use this script to do some operations that we need. What we do - we just send the value from first parameter of the event into that push DCI. So we now have some historic data in this DCI.

There is a flaw in this approach - the values are only updated when log file has new matches. If there are no new matches, the DCI will get stuck with the last value. We can fix this by scheduling some action that would send 0 into our push DCI after 24 hours - but this won't be exactly correct - e.g. if we had one match 12 hours ago and another just now, then after 12 hours the value should drop from 2 to 1.

2) The other approach is to do the same job that agent does, when counting matches within specified time window, on the server. For this we need to store a list of unix timestamps when new events come (again from script in EPP rule). Then periodically (can just use a script DCI) we need to count timestamps that fit within 24 hour time window and delete older timestamps from the list. The list could be stored in a mapping table (it's a global place to store things) or just in custom attribute on the node as comma-separated string with unix timestamps.

I can give more detailed instructions if you decide to use this approach.
Feel free to ask if you need more detailed explanations on the above.

We will add displaying of IP address in list of sessions in a future version.
Currently you can set debug to level 5. This could be done on the fly in Tools->Server Console
debug 5

The messages that we want to see are these:
2022.04.13 13:10:01.442 *D* [                   ] SocketListener/Clients: Incoming connection from 127.0.0.1
2022.04.13 13:10:01.442 *D* [                   ] SocketListener/Clients: Connection from 127.0.0.1 accepted

so you can grep your server log by "SocketListener/Clients"

This way we will see from where these connections are coming.
Do you have any other integrations besides Grafana (nxshell, WEB API)?

Yes, on Windows in Task Manager on Details tab you can create dump file. The dump may have some sensitive information, so do not share it publicly.

This is actually strange. The only possible reason I can think of is if runtime error happens in the script. In this case script is interpreted as if it would return true (this will be reworked in next release). But script run-time error would be visible in the log file. And your script looks to be correct.

I would increase active discovery interval to 3600 - this is to make sure that discovery processes would stop. Then try setting server debug level to 6 (hopefully it's a test environment with not too many nodes - otherwise there will be too many lines in the log). And try to run discovery scan manually - select the range and click scan. The log should have detailed information on how discovery is happening.

I'd suggest to turn off the active discovery. Then to check that discovery queue is empty (run "show queues" from Tools->Server console). After that try deleting the nodes again and retry the discovery.

Hi!

I've added a couple of issues for these features:
https://track.radensolutions.com/issue/NX-2248
https://track.radensolutions.com/issue/NX-2249

NX-2249 is probably lower in priority, but might be done at some point.
Dashboard generation from performance tab is technically possible, but there's a lot of higher-priority things.