Unfortunately Jython (Python implementation in Java) which is used as foundation for nxshell seems to be stuck on version 2.2. If they eventually release Python 3 version we definitely will update nxshell. Best regards, Victor

Hi, The fact that they do not support dot1dBase affects FDB reading. In FDB dot1dTpFdbPort supposed to contain bridge port number from dot1dBase. It looks like they just put ifIndex there. This we will be able to fix with device driver for those switches. I think that interface rename can be handled by driver as well. I think I'll be able to create driver for them in one of 3.3 patch releases if you can provide me access to test device or send required SNMP walks. You can contact me via PM regarding access or dumps. Best regards, Victor

This did the trick! I changed my config to: ExternalParameter=Test:"cmd.exe "/C C:\PROGRA~1\Scripts\test.bat"" and now I have the result in my NetXMS Server Thanks! [image: server.png]

Thanks, that worked.

Can you also show the screenshot of configuration of this DCI - first page - "General"

Thank you for reporting. The ThreadPool DCIs are failing because you have only one SYNCER process configured (default setting) - in this case thread pool mechanisms are not used. Server.Heap ones work only if server was compilled with jemalloc. In coming 3.3. version out of the box templates were updated to fix these issues.

You can disable this in Configuration->EventProcessingPolicy #7 Generate alarm when incorrect network mask detected on interface ->Filter->EditCondition Condition->rule is disabled Events->SYS_INCORRECT_NETMASK We had the same issue with 10.x.x.0/24.  if it finds a single unit with a /8 (or /16 in your case) it creates a subnet in Entire Network (or zone if enabled) that it then matches first.

Just checked - there was a fix in DB init script between 3.2.400 and 3.2.472 for exactly this issue. Completely forgot about it. Best regards, Victor

I did a new test with different waiting times (0, 1, 2, 5, 10, 0 and 1s) only the last try was successful and the call has returned the value 5. I've attached the captured ssh communication which was done localy only (from agent on the same RPi) therefore the network cannot be the source of the problem. I've attached the source of my test program, but it is very simple.   Here is the filtered agent log (the full log is attached): 2020.04.15 09:03:24.435 *D* [comm.cs.1 ] Requesting list "SSH.Command(192.168.18.134,"pi","raspberry","/opt/disp_ctrl/mon_c 0 5")" 2020.04.15 09:03:24.736 *D* [ ] SSH: created new session [email protected]:22/1 2020.04.15 09:03:24.841 *D* [comm.cs.1 ] GetListValue(): result is 500 (INTERNAL_ERROR) -- 2020.04.15 09:03:34.496 *D* [comm.cs.1 ] Requesting list "SSH.Command(192.168.18.134,"pi","raspberry","/opt/disp_ctrl/mon_c 1 5")" 2020.04.15 09:03:34.496 *D* [ ] SSH: acquired existing session [email protected]:22/1 2020.04.15 09:03:35.517 *D* [comm.cs.1 ] GetListValue(): result is 500 (INTERNAL_ERROR) -- 2020.04.15 09:03:42.637 *D* [comm.cs.1 ] Requesting list "SSH.Command(192.168.18.134,"pi","raspberry","/opt/disp_ctrl/mon_c 2 5")" 2020.04.15 09:03:42.637 *D* [ ] SSH: acquired existing session [email protected]:22/1 2020.04.15 09:03:44.657 *D* [comm.cs.1 ] GetListValue(): result is 500 (INTERNAL_ERROR) -- 2020.04.15 09:03:52.416 *D* [comm.cs.1 ] Requesting list "SSH.Command(192.168.18.134,"pi","raspberry","/opt/disp_ctrl/mon_c 5 5")" 2020.04.15 09:03:52.416 *D* [ ] SSH: acquired existing session [email protected]:22/1 2020.04.15 09:03:57.436 *D* [comm.cs.1 ] GetListValue(): result is 500 (INTERNAL_ERROR) -- 2020.04.15 09:04:03.635 *D* [comm.cs.1 ] Requesting list "SSH.Command(192.168.18.134,"pi","raspberry","/opt/disp_ctrl/mon_c 10 5")" 2020.04.15 09:04:03.635 *D* [ ] SSH: acquired existing session [email protected]:22/1 2020.04.15 09:04:03.917 *D* [comm.cs.1 ] Received message CMD_KEEPALIVE (146) 2020.04.15 09:04:13.656 *D* [comm.cs.1 ] GetListValue(): result is 500 (INTERNAL_ERROR) -- 2020.04.15 09:04:20.165 *D* [comm.cs.1 ] Requesting list "SSH.Command(192.168.18.134,"pi","raspberry","/opt/disp_ctrl/mon_c 0 5")" 2020.04.15 09:04:20.165 *D* [ ] SSH: acquired existing session [email protected]:22/1 2020.04.15 09:04:20.185 *D* [comm.cs.1 ] GetListValue(): result is 500 (INTERNAL_ERROR) -- 2020.04.15 09:04:29.965 *D* [comm.cs.1 ] Requesting list "SSH.Command(192.168.18.134,"pi","raspberry","/opt/disp_ctrl/mon_c 1 5")" 2020.04.15 09:04:29.966 *D* [ ] SSH: acquired existing session [email protected]:22/1 2020.04.15 09:04:30.986 *D* [comm.cs.1 ] GetListValue(): result is 0 (SUCCESS)   ssh.pcap mon_c.c nxagentd

Thanks for clarification.

Thanks for fast fix

Thanks for fast response and fix.

On CentOS the libssh can be installed as a package. Compiling form sources works fine. It even works with ssh.nsm copied from Debian package but libpcre.so.3.13.3, libpcre32.so.3.13.3 are missing on CentOS and cannot be installed as packages therefore these libraries must be copied too.

SOLVED Found out that since 4 days there is a new Version of the datasource on Git (but nor message About this..)

Yes, it's still up to date. Export is slow (especially on large databases) and require server to be down.

Hi there, I got a little Problem after I've updated to 3.1.343, some Internal DCIs changed to UNSUPPORTED: From Template /NetXMS Server/Database Writer:   - Server.AverageDBWriterQueueSize.IData;   - Server.AverageDBWriterQueueSize.Other;   - Server.AverageDBWriterQueueSize; From Template /NetXMS Server/Server Performance:   - Server.AverageDataCollectorQueueSize;   - Server.AverageSyslogProcessingQueueSize;   - Server.AverageSyslogWriterQueueSize; Today, I updated to 3.2.472, that didn't solve the problem. Trivia: I once manually changed these DCIs (at Node, not in the Template) to DISABLED, but everytime the housekeeper ran it reenabled the DCIs... ...the DCIs changed back to UNSUPPORTED and so I got 6 Alarms every morning. Because I got really annoyed by those 6 daily alarms (I get most alarms via mail too, cause I'm not looking at the Console all day long), I tried to find a way to disable the DCIs for good (so I've at least got workaround). Strangely, the TemplateGroup "NetXMS Server" wasn't visible at my installation, at the DCI Collection Configuration the Internal DCIs just showed <unkonw> at the template-column. I took some time analyzing the Database-Structure itself and I found out there was no entry for this TemplateGroup in the table "container_members". After manually creating that entry and restarting the NetXMS Core, the Console showed me that TemplateGroup and I could disable those DCIs in the Template itself. As I guess, disabling DCIs in the "NetXMS Server" Templates might not be the qay the system was designed, I just wanted to ask for any ideas about what's wrong with my installation... NetXMS Core is running on Windows Server 2008 R2 with MariaDB Database (Server is configured to use the mariadb.ddr Driver). Prior to the Update to 3.1.343, everything was fine. Any idea is highly appreciated! Best regards, Manuel

Found the problem, if you have all the interfaces as 'ignore' then it will cause this situation, I expected the node to just rely on the Use ICMP on primary IP address to determine node status setting.

There's a new release available not that fixes one memory leak. Please try it.

It depends on what you want to achieve. If you are not interested in these interfaces at all, you can prevent them from creating - modify script "Hook::CreateInterface" in scripting library. Script is executed on configuration poll for each new interface (accessible as $1, https://www.netxms.org/documentation/nxsl-latest/#class-interface) and should return true or false. If return value is false - interface will not be created. It's possible to use $1->ifType (interface type as defined by IANA, list of interface types available here: https://github.com/netxms/netxms/blob/master/include/nms_common.h#L908, or can be seen on the object overview tab when interface is selected). Or you can query node via SNMP to get some data. If you want to keep interfaces in the system, but ignore status change - simplest way is to set “Expected Interface State” to IGNORE. You can do it in configuration poll hook (Hook::ConfigurationPoll). Sample: for (i : $node->interfaces) {     if (i->ifType == 131) { // tunnel         i->setExpectedState("IGNORE");     } } If you want to block events in the EPP, add rule before any alarms or notifications: Script:     i = $node->getInterface($5);     if (i->ifType == 131) { // or any other filter         return true;     }     return false; Action:     stop processing Alternatively, add script to your alarm / notification rules and return true only if it’s not dynamic interface:     i = $node->getInterface($5);     if (i->ifType == 131) { // or any other filter         return true;     }     return false;

Good idea, works fine! Thanks a lot!