NetXMS Support Forum

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

If you are on Windows then I recommend to switch to version 4.3 - web UI installer for Windows also contains API which will be accessible under /api path. Starting with version 4.3 we also deploy complete Jetty server so you'll be able to properly setup SSL, etc.

Best regards,
Victor

Hi!

NetXMS server do walk on .1.3.6.1.4.1.2636.3.40.1.5.1.7.1.5 to collect port membership (but result should be the same as walking on .1.3.6.1.4.1.2636.3.40.1.5.1.7.1.3).

In your data port ge-0/1/3 has ifIndex=552, but I don't see it in VLAN port table (there should be entry with OID SNMPv2-SMI::enterprises.2636.3.40.1.5.1.7.1.3.nnn.552, where nnn is index in VLAN table).

Same for ge-0/0/16: it has ifIndex=534, and it has multiple entries in VLAN port table:
SNMPv2-SMI::enterprises.2636.3.40.1.5.1.7.1.3.2.534 = INTEGER: 3
SNMPv2-SMI::enterprises.2636.3.40.1.5.1.7.1.3.5.534 = INTEGER: 3
SNMPv2-SMI::enterprises.2636.3.40.1.5.1.7.1.3.14.534 = INTEGER: 3
SNMPv2-SMI::enterprises.2636.3.40.1.5.1.7.1.3.16.534 = INTEGER: 3
SNMPv2-SMI::enterprises.2636.3.40.1.5.1.7.1.3.17.534 = INTEGER: 3
SNMPv2-SMI::enterprises.2636.3.40.1.5.1.7.1.3.18.534 = INTEGER: 3
SNMPv2-SMI::enterprises.2636.3.40.1.5.1.7.1.3.23.534 = INTEGER: 3
which corresponds to VLANs CP-1, SSO-3, SSO-12, SSO-UnautenthicatedDevice, Example1, Example2, n9-2.

If this does not correspond to actual device configuration then it looks like device reports incorrect information via SNMP.

Best regards,
Victor

We are coming to Fosdem! If you're also visiting the event or are in Brussels on the 4-5 February, ping us. Let's meet (have a beer or a muffin) and talk about what's new in NetXMS and the open-source industry in general.