NetXMS Support Forum

You should be able to do that with object tools. Create tool that will call a script, define necessary input fields, and when user will run the tool he will be asked for additional input. This input will be available in a script.
You can even create context dashboard and add those tools as action buttons.

Best regards,
Victor

This is normal behavior - for some reasons PDH reports temporary objects that cannot actually be accessed. You can safely ignore those errors.

Best regards,
Victor

Yes, we have that "sponsor" button on github

Best regards,
Victor

Sorry for delay, just get back to issues that piled up.
Looks like switch returns FDB information, so problem is within server. Can you set debug level 6 for tag "topology.fdb", run topology poll on switch node, and show me server log?

Best regards,
Victor

Currently it is not possible to inject topology information from hook script, but I see how that could be beneficial. Another option which I consider for some time already is to extend driver concept beyond SNMP, to allow SSH commands and possibly other protocols. This may help with reading VLAN information on Mikrotik switches for example, and probably lot of other cases with devices that have marginal SNMP support.
Added note to myself to think about it for one of next releases

Best regards,
Victor

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