NetXMS Support Forum

FindNodeByIPAddress is a function, so you should not add "Objects." in front of it. Dot is string concatenation operation in NXSL (we plan to change that in 5.0, but that's another story) - so Objects . FindNodeByIPAddress concatenates null value converted to empty string from non-existent variable "Objects" with object returned by FindNodeByIPAddress converted to string - so result is a string.
Correct script will be something like this:
node = FindNodeByIPAddress($1, null);
if (node == NULL) {
   println("Error: node not found.");
   return;
}

println(node->name);
println(node->executeSSHCommand("ip address print"));

Best regards,
Victor

We just published patch release 2 for version 4.3. Changes since previous patch release:

-  Fixed stacked line charts in new UI
-  Fixed timeout inconsistencies in netsvc subagent
-  Added web API calls for managing alarm comments
-  More functionality migrated to new management client

Fixed issues:

-  NX-677 (Dashboard editor: accelerators are duplicated in Line chart -> Data sources)
-  NX-2377 (Copy-paste of rules not working in EPP editor)
-  NX-2348 (Show active threshold event name in Last Values)
-  NX-2376 (Agent restart is not working correctly on RedHat based Linux OS)
-  NX-2379 (REST API to force poll DCI)
-  NX-2383 (Ignore systemd synthetic records when resolving node IP address to hostname)

Recording of webinar is available on YouTube: https://www.youtube.com/watch?v=KKPmv5GfJag

Make sure you have debug level set to 6 for tag ncd.telegram, then look for messages with this tag that precedes line "Telegram API call failed, driver configuration could be incorrect" - there should be more information about failure reason.

Best regards,
Victor

Link for today's webinar:

https://radensolutions.my.webex.com/radensolutions.my/j.php?MTID=m29245599aa75100935a0984fef1bef64

We just published patch release 1 for version 4.3. Changes since initial release for version 4.3:

- Fixed database schema upgrade on Microsoft SQL Server
- Fixed issues with network service checks using netsvc subagent as a replacement for portcheck subagent
- Fixed bug in external table provider command execution
- Fixed server crash during execution of object tool of type "server command"
- Dashboard element "Availability Chart" is working again
- Mikrotik driver correctly handles server settings for using ifXTable and interface aliases
- Fixed VLAN configuration reading bug in Juniper driver
- Multiple fixes and improvements in new management client application
- Cosmetic fixes in Windows agent installer

Fixed issues:

- NX-808 (NXSL error message should include module name)
- NX-2222 (Interface alias duplicated in UI if Objects.Interfaces.UseAliases set to "concatenate name with alias")
- NX-2345 (Copy to Clipboard and Save as image... buttons no longer exist in WebUI in line chart window)
- NX-2374 (Template auto unbind grace period handled incorrectly)

Best regards,
Victor

Hello everybody, we're renewing our online sessions of NetXMS Talks! It's a great opportunity to learn about new (and sometimes not-so-new) features and ask questions. Let's meet on Tuesday at 5pm EET (3pm GMT, 4pm CET, 10am in EST) and talk about
- Latest best practices for NXSL
- Context dashboards
- New console and its development plans
- And any other questions you want to ask us.
Reply here or send a message and we'll send you a link to a Webex call! Alternatively, you can just follow this thread - conference link will be published here shortly before start.

Best regards,
Victor

Yes, there is a bug in configuration parser introduced in 4.3.0. I just fixed it, fix will be included into release 4.3.1.

Best regards,
Victor

Hi,

Mikrotik is known for incorrectly reporting topology information via SNMP. We try to address it when workaround is possible. Please report specific cases (actual connections and how NetXMS server presents them), and we will try to find what causes inconsistencies and if there is a fix. Also, make sure that all your Mikrotiks have LLDP switched on.

Best regards,
Victor

Thank you for digging this! I just changed Juniper driver to use bridge port number instead of ifIndex to identify ports in VLANs. Fix will be included into release 4.3.1. If you want to test it before release I can provide intermediate build, just let me know what platform you are using.

Best regards,
Victor

Yes, we aware of it and will fix soon.

Best regards,
Victor

You cannot create SNMP transport because node object is not created yet. Currently community string used for discovery is not accessible to filtering script. Closest thing that you can do is to leave only one community string in network credentials and require SNMP support for newly discovered nodes. That way automatic discovery will only try that one community string, and devices that will not respond will not be marked as SNMP capable and will not pass filter. However, you will have to manually enter correct community string for devices that added manually and use different community string.

Best regards,
Victor

Correct, old subagent (portcheck) set host header and SNI separately. I just fixed netsvc in development branch so it use correct host name when called for network service object poll or via compatibility metrics, next patch release will contain fix.

Best regards,
Victor

Quote from: 2b2bff on January 27, 2023, 11:38:36 AMThanks a lot.

Sadly the DB upgrade for MSSQL fails because event_cfg.description is a TEXT column and the upgrade script compares it with VARCHAR in the WHERE clause.
Simple fix - please change all TEXT columns to VARCHAR(MAX). TEXT has been deprecated long time ago...
https://learn.microsoft.com/en-us/sql/t-sql/data-types/ntext-text-and-image-transact-sql

Cheers

Upgrade procedure is fixed in development branch, fix will be part of upcoming patch release 4.3.1. In version 4.4 we will also switch to varchar(max) from text.

Best regards,
Victor

Hi!

I was unable to reproduce telnet service check issue. "[  136] INT32      2" in response indicates connection problem, so agent was unable to connect to given address and port. Could it be that address is a loopback?

For HTTPS checks - it could be certificate issue. Unfortunately agent do not log exact failure reason (I fixed it already in development branch). Try to do same request with curl from command line (using URL exactly as logged - https://x.x.x.x:443/api/status) - will you get any errors?

Best regards,
Victor