NetXMS Support Forum

Thanks, issue registered: https://github.com/netxms/netxms/issues/3428

Thanks for the follow-up — you are right, 6.2.1 does not fully fix this.

The fix that went into 6.2.1 removed the visible flickering of the columns, but not the underlying cost. Grid views still re-measure and repack every column on each refresh cycle, and that is what you are seeing as constant repainting on the Data Collection and Interfaces tabs. On a node with many interfaces or DCIs a refresh can be triggered very often, so it never settles.

I've opened https://github.com/netxms/netxms/issues/3418 to track it. The proper fix is to repack columns only when the content actually changes shape (new columns, first data load, or when you ask for it), instead of on every refresh.

Until then you can avoid the problem by unchecking "Resize columns automatically" in the view menu of the affected view. The setting is remembered per view, and with it off the columns are no longer repacked on refresh.

The identical value on both switches is expected, not the fault. 1.3.6.1.4.1.2011.5.25.42.4.1.19.1.2 is hwMstpiBridgeID, and under V-STP the M-LAG pair presents itself as one logical bridge, so both chassis report the same bridge ID. In your case that ID (AC:5E:14:7F:89:01) is xA's own dot1dBaseBridgeAddress, which you can see in xA's Hardware Inventory tab.

NetXMS reads that OID specifically to handle this - see https://github.com/netxms/netxms/issues/3353, fixed in 6.2.0. Without it, STP discovery invents a link to the M-LAG peer on every downstream port. Which server version are you running? If it is older than 6.2.0, upgrade first and re-run a configuration poll plus a topology poll on both switches.

The peer-link and keepalive links in your screenshots look correct: the six Eth-Trunk0 members (40GE5/0/34-35, 40GE6/0/34-35, 40GE7/0/34-35) and 10GE4/0/47 all resolve to the right peer and match your diagram. Two other things do look wrong, and neither can come from STP discovery:

1. On both switches, MEth0/0/0 and 10GE2/0/1 list the switch itself as peer node, pointing at each other. STP discovery cannot produce a self-link - it skips a bridge that resolves to the local node.

2. 40GE6/0/6-9 on xA linked to 10GE4/0/42-45 on xB. These ports are DOWN/Disabled, and a down port has no forwarding or blocking STP state, so STP would not report them. They are also absent from your diagram.

Could you widen the Interfaces table and show the "Peer discovery protocol" column? It is cut off in both screenshots, and it is the one field that tells me which discovery source created these links (STP, LLDP, CDP, or FDB). Also confirm whether 40GE6/0/6-9 were ever cabled to xB - if they were, these may just be stale cached links.

TRUNCATE

Thanks for the detailed report.

The missing zone record is not what's breaking discovery. Object ID 4 is a built-in object: the server creates the Default zone in memory at every startup, and the code paths that use it (including active discovery) handle it correctly whether or not a row exists in zones / object_properties - the row only gets written once the zone is actually modified, e.g. when the first subnet is placed into it. So on a freshly initialized database the tables being empty is expected, and this is not specific to SQLite or to Windows.

The error message in the log is misleading, though, and the zone should be persisted at first startup instead of being re-created every time. I've opened https://github.com/netxms/netxms/issues/3410 for that.

For the discovery problem, which is a separate issue, please check the following:

1. Discovery type. In Server Configuration, check NetworkDiscovery.Type. If it is 0 (disabled), the "Scan" action will enqueue addresses but nothing will pick them up. For active scanning of configured ranges it must be 2 (active) or 3 (active and passive).

2. Enable discovery debug output. Either start the server with a higher debug level, or set it at runtime without a restart:

    nxadm -c "debug tag poll.discovery 6"

Then run the scan again and watch netxmsd.log. At level 6 you will see, per address, whether the host responded to the probe and - if it did - whether the potential node was rejected and why ("IP address already known at node ...", "rejected by discovery filter", etc.). Reset it afterwards with nxadm -c "debug tag poll.discovery off".

3. Probing method. By default active discovery only uses ICMP ping. If the target hosts do not answer ICMP, nothing will be found. Check NetworkDiscovery.ActiveDiscovery.EnableSNMPProbing and NetworkDiscovery.ActiveDiscovery.EnableTCPProbing, and make sure ICMP is not blocked between the server and the scanned range.

4. Discovery filter. If a filter script is configured, a responding host can still be dropped. The level 6 log above shows this explicitly.

5. Address ranges. Verify that the ranges under Network Discovery -> Active Discovery Targets are the ones you expect, and that they are IPv4 - IPv6 ranges are skipped by active discovery.

If you post the poll.discovery log from a scan run, I can tell you where it stops.

Thanks for the suggestion — I've opened an issue for it: https://github.com/netxms/netxms/issues/3409

At the moment all backup-related read operations (list of backups, latest backup, individual backup by ID) are gated only by "Read" access on the node, so anyone who can see the node can also pull the full device configuration with whatever it contains. Splitting that into a separate right for the backup list and another for viewing/exporting the actual content makes sense to me.

There are a few things to settle first — mainly what the default should be for existing installations, and the fact that the object access rights mask is nearly out of free bits — so I'll discuss it with the team before we implement anything. Feel free to add your thoughts to the issue.

Самое простое решение - добавить в Hook::CreateInterface:

if (($1.name == "ISW001") and ($1->name ~= "^VLAN.*"))
{
    return false;   // не создавать VLAN-интерфейсы
}
return true;


That's more or less expected with the current caching: the client caches tiles under .nxmc4 and doesn't invalidate them when the tile server changes, so you can get stale/missing tiles from the previous server — which is why clearing the cache fixed it for you. I've filed a ticket to key the cache by tile server URL so switching servers invalidates automatically and you won't need to clear it by hand. Thanks for tracking it down.

Objects already have a "presentation image" property that is meant to control exactly this. It turns out it's currently ignored when the object is rendered on the geo map, so you always get the default icon there. I've opened an issue to fix it — once done, your custom presentation image will be used on geo maps as well. Thanks for the report.

Ticket: https://github.com/netxms/netxms/issues/3398

Hi Leo,

Yes — libcurl.dll will be updated to 8.21.0 or later in the next agent build. It's bundled with the Windows agent, server, client and web UI installers, so all of them get the new DLL.

That said, NetXMS itself is not exploitable through this bug, so there's no urgency here.

CVE-2026-8927 needs four things to line up at once:

1. the proxy is configured through environment variables rather than CURLOPT_PROXY,
2. a curl handle is reused across sequential transfers,
3. the proxy changes between those transfers, and
4. the first transfer authenticated to the proxy using Digest.

The fourth one never happens in NetXMS. libcurl only negotiates Digest against a proxy if the application sets CURLOPT_PROXYAUTH to include CURLAUTH_DIGEST or CURLAUTH_ANY — the default for that option is CURLAUTH_BASIC. We never set CURLOPT_PROXYAUTH anywhere in the codebase, in the agent or the server. So the stale Proxy-Authorization state that the CVE describes is never created in the first place.

Worth heading off one thing that looks related but isn't: the agent's web service support does offer Digest as an authentication option (WebServiceAuthType::DIGEST). That is passed to CURLOPT_HTTPAUTH, which authenticates to the web service itself via the Authorization header. Proxy authentication (Proxy-Authorization) is a separate state machine and is not affected.

If your scanner is flagging the DLL by version rather than by reachability, and you'd rather not wait for the next build, you can drop a newer libcurl.dll into the agent's bin directory yourself. curl keeps its ABI stable across the 8.x series, so a straight 8.21.0 replacement works. Two caveats: it will be overwritten on the next agent upgrade, and it won't carry our code signature.

Hi,

Thanks, my bad. Fixed now.

Simplest approach is to modify retention time in server configuration, then run housekeeper (or just leave it overnight). Once done, vacuum DB and you'll have more space.

nxdbmgr actually do this migration for all images - but stock images (there are 9) are deleted by the upgrade process before the actual migration. Current build of both debs and rpms have workaround for that, and it's completely fixed in upcoming 6.2.1.

Hi,

The problem is the servlet container version, not Java.

The NetXMS 6.2 web client (nxmc-6.2.0.war) is built against the Jakarta Servlet API (jakarta.servlet.* namespace) and requires a container that supports it. You are running Tomcat 9.0.58, which still uses the older javax.servlet.* namespace. Because of that, Tomcat 9 cannot load the application's context listeners, which is exactly the "One or more listeners failed to start" / "Context startup failed" error you see.

The ClassCastException about ObjectStreamClass$Caches is a harmless secondary warning. It comes from Tomcat's cleanup routine running on a newer JDK while it tears down the already-failed context - it is not the cause. That is also why switching from JDK 17 to 21 made no difference; the JDK was never the issue.

To fix it, deploy the WAR on a container that supports the Jakarta Servlet API:

- Tomcat 10.1 or later - on Ubuntu use the tomcat10 package, webapps directory /var/lib/tomcat10/webapps.
- Jetty 11 or later is also fine (Jetty 11/12 support the Jakarta Servlet API).

Java 17 or 21 works with either. Do not run it under Tomcat 9 - the javax vs jakarta namespace difference cannot be bridged by a config change or a different JDK.