NetXMS Support Forum

Connection information for end nodes that does not support LLDP or CDP is obtained from FDB, so root cause is FDB not being retrieved from the switch.
What driver is selected for the switch? Also, what is walk output for .1.3.6.1.2.1.17.4.3.1?

Best regards,
Victor

I cannot reproduce this - in my test alarm list on dashboard shows alarms correctly according to checked severity in element configuration. Could you please provide step by step instruction on how to reproduce this issue?

Best regards,
Victor

Normally it should happen automatically for events SYS_NODE_DOWN if topology is known to the server. If server is able to determine route from itself to unreachable node, it will check all intermediate nodes, and generate SYS_NODE_DOWN only for router closest to the server, and SYS_NODE_UNREACHABLE for nodes down the line.
For more complex logic you can use script filters - all kind of topology information is available in scripts, so you can filter events based on peer nodes, routing information, etc.

Best regards,
Victor

Copy constructor is not a problem in executing AlarmStateChange hook - script is executed from Alarm::executeHookScript, which in turn only called after m_state for source alarm was changed.
I currently cannot see how hook could have been called with state 3 for new alarm. In described sequence of events, when did you restart the server?

Best regards,
Victor

Can you try to set debug level to 7 for tag poll.icmp, and when problem repeats, send me extract from the server log filtered by object name?

Best regards,
Victor

Can you please describe use case for that? Usually NXSL scripts are non-interactive, the only place where user normally invokes NXSL script is script based object tool - but there you can use input fields.

Best regards,
Victor

We just published patch release 7 for NetXMS 4.3. Changes since previous patch release:

-  Fixed bug in reading topology information from LLDPv2 MIB
-  Small fixes and improvements in new management client application
- Fixed issues:
  -  NX-2253 (Actual repeat count should be passed to event in log file monitoring when reset repeat count is true)
  -  NX-2418 (Log file monitoring does not work properly with symlinks)
  -  NX-2421 (Invalid time format in log parser configuration can cause agent crash)

Hi,

I was able to reproduce and fix this issue (yet another bug in LLDPv2 MIB handling). Fix will be included into next patch release (we likely will publish it this week).

Best regards,
Victor

Hi,

problem with ICMP polls ignoring "poll count for status change" was fixed. Do you have poll count set to more than 1 and still get regular ICMP unreachable?

Best regards,
Victor

Seems that actual conversion was already done. Execute the following SQL statement:
UPDATE metadata SET var_value='' WHERE var_name='PendingOnlineUpgrades';

This will inform nxdbmgr that all pending background updates are completed.

Yes, it should be safe to upgrade to 4.3.6.

Best regards,
Victor

Could you also provide server log file with debug level 6 for the duration of topology poll on that switch (i.e. set debug level to 6, go to Poll -> Topology on the switch node, set debug back)?

Also, don't forget about our  questionnaire! We'd really appreciate your input.

Direct link: https://survey.alchemer.com/s3/7316052/NetXMS?uid=live

Hello NetXMS community,

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

- Correctly handle FDB record type "secure"
- Improved driver for Cambium devices
- Fixed bug in handling /32 addresses during network discovery
- Fixed bug in flood notification processing in Telegram driver
- Fixed server crash caused by timeout during file transfer to agent
- Fixed bug in SNMP codepage handling
- Fixed bar gauge dashboard element drawing issue
- Small fixes and improvements in new management client application

Hi,

I've found a bug introduced in 4.3 which may cause incorrect decoding of strings received via SNMP (SNMP codepage was ignored in some cases). Fix will be included into upcoming patch release 4.3.6.

Best regards,
Victor

Yes, it actually could be related to codepage. Depending on entry type, NetXMS server may require to search for peers using texts (interface descriptions for example), and if it is received incorrectly search will fail. To be able to diagnose it I likely will need exact walk outputs though. We can move discussion to private messages or Telegram if you don't like to share such data publicly.

Best regards,
Victor