NetXMS Support Forum

Yes, main reason for moving name resolution to configuration poll was concern that there will be too much DNS requests. I'll see how I could make this configurable.

Best regards,
Victor

Currently NetXMS do name resolve only on configuration poll. Looks like we have to move it to status poll.

Best regards,
Victor

Hi!

Drivers are written in C++. They all extends base driver class and overrides methods needed to provide accurate information. Most important is to mark physical ports in interface list and provide VLAN information. All existing driver sources located under src/server/drivers - you can take a look.

My main problem with H3C driver is that I currently does not have access to any HP A series device for testing. I can assist you in driver development if you want to take it. Alternatively, I can write a driver if you can provide me with remote access over SNMP to some test device.

Best regards,
Victor

Hi!

Could you run agent in debug mode and provide me with debug log (at least last messages before freeze)?

Best regards,
Victor

Hi!

That means that flag NF_HAS_WINPDH (Node supports Windows PDH parameters) set and cleared periodically. Node considered to support PDH if it has NetXMS agent and agent responds correctly to PDH requests (PDH.Objects list and others). You can check server debug log (running with debug level 5 or higher) for error messages started with WinPerfObject::getWinPerfObjectsFromNode prefix.

Best regards,
Victor

Hi!

Everything is correct except event tag - it should be

<event params="1">100005</event>

Value in params attribute should match number of capture groups in regular expression (1 in your case).

Best regards,
Victor

Hi!

Agent cannot use UDP for communications. It's just standard practice to assign both tcp and udp port numbers - I didn't even request udp ports.

Best regards,
Victor

Пока рассчитываем в конце этой недели, но может немного задержится.

Please provide result of

cat /proc/drbd

on your machine.

Best regards,
Victor

I mean that it requires additional development. I've rigistered it as feature request so it will not be forgotten (https://www.radensolutions.com/chiliproject/issues/561).

Best regards,
Victor

Hi!

Actually it's a flaw in trap processing logic - they should be ignored for unmanaged nodes. I've registered this as a bug.

Best regards,
Victor

This is a reference to unimplemented feature.

Best regards,
Victor

Hi!

Can you share (part of) log file you are trying to monitor?

Best regards,
Victor

Hi!

No, it's not supported. Could you register feature request for this? Should not be hard to implement

Best regards,
Victor

Net.RemoteShareStatus should return status code returned by NetUseAdd Windows API call. Level 2 call is used.

Best regards,
Victor