NetXMS Forum

Great, thanks a lot!

Ah, I thought ICMP.PingSize referred to the payload, not to the whole packet.

I'm now looking at https://wiki.netxms.org/wiki/Server_Configuration_Variables which says "Size of ICMP packets (in bytes, excluding IP header size) used for status polls.", so I guess minimum would be 8, correct? Or is that documentation wrong and the IP header is included in ICMP.PingSize?

Yes, we have set the ping size to 1 in order to reduce traffic, because most of our nodes are connected through mobile internet, so we pay for the traffic. What's the reason for having a 46 byte minimum? And how did NetXMS-3.9 handle this? Did it simply fall back to larger packets?

@filipp-sudanov said in Auto-Apply Template Not Working after Upgrade:

In 4.0 auto-apply was reworked so that it happens from template/container side. But the case when a new node is added was kinda forgotten. Will discuss that internally with developers.

Thanks, we would greatly appreciate this! We are adding nodes every day, and being able to see values straight away is helpful.

Thanks for that link. I somehow missed it.

Hi,

we tried upgrading from NetXMS 3.9.176 to NetXMS 4 on Debian (buster and bullseye, with postgresql 11 and 13, respectively). The nxdbmgr did it's job of upgrading the database without complaining. But netxmsd segfaults after about 1 minute. We tried NetXMS-4.0 and 4.1.283, same effect.

Setting up a new netxms installation with the same scripts, templates, events, nodes, etc. works fine. But we would like to keep the data history. Has anybody else observed such a behavior? Is there anything special we need to do?

Hi,

I've got several templates with automatic apply rules. In NetXMS-3.9 I could run a configuration poll or a status poll (don't remember which) to trigger the application of the matching templates.

How do I do this in NetXMS-4.1? None of the polls seem to have an effect, but if I wait for some time, the templates get applied. Is there a way to trigger this manually? Is this somehow related to the new server variable "Object.AutobindPollingInterval" (which I can't find documentation for)?

Well, okay then: How do I connect the agent with the server when living on the same machine? We don't need the agent for anything else but nxapush, so we haven't tried it from another machine.

We are running Debian Buster. libssl:

ii  libssl1.1:amd64                      1.1.1d-0+deb10u6             amd64        Secure

@filipp-sudanov said in nxapush not working?:

Do you have any DPI system between agent and server that could intercept ssl connections?

No. Server and agent are living on the same physical machine.

With java-8 on Linux (openjdk-8-jre package in Ubuntu 18.04 LTS) I see the same problem as with java-11: The session key sometimes arrives delayed.

I haven't tried the CipherTest with java-8.

Yes, the DCI parameter is "LOCAL_TEST", origin is "push".

With DebugLevel=6 in netxmsd and nxagent the only output I get is in the agent log file. Nothing shows up in the server log. Here is the agent log:

2021.03.31 13:39:08.836 *D* [                   ] NamedPipeListener(nxagentd.push): accepted connection by user ats
2021.03.31 13:39:08.836 *D* [                   ] ProcessPushRequest: connection established
2021.03.31 13:39:08.836 *D* [                   ] ProcessPushRequest: received message CMD_PUSH_DCI_DATA
2021.03.31 13:39:08.836 *D* [                   ] PushData: "LOCAL_TEST" = "7"
2021.03.31 13:39:08.836 *D* [                   ] ProcessPushRequest: connection by user ats closed

Is there a way to tell the agent which server it should connect to? Is this localhost by default?

We are running netxmsd-3.8.250 with nxshell-3.8.250 on Debian Buster with java from Debian (openjdk 11.0.9.1 2020-11-04).

There are no stuck sessions from previous connection attempts.

With DebugLevel=6 in netxmsd we can see that there seems to be a problem with the session key exchange. I've got three logfile excerpts for you:

1. Successful login, everything looking good:

2021.03.31 13:08:03.134 *D* [client.session     ] Client session with ID 1 registered
2021.03.31 13:08:03.147 *D* [client.session.1   ] Received message CMD_GET_SERVER_INFO
2021.03.31 13:08:03.147 *D* [client.session.1   ] Server time zone: UTC+00UTC
2021.03.31 13:08:03.147 *D* [client.session.1   ] Sending message CMD_REQUEST_COMPLETED (616 bytes)
2021.03.31 13:08:03.152 *D* [client.session.1   ] Received message CMD_REQUEST_ENCRYPTION
2021.03.31 13:08:03.152 *D* [client.session.1   ] Sending message CMD_REQUEST_SESSION_KEY (344 bytes)
2021.03.31 13:08:03.224 *D* [client.session.1   ] Received message CMD_SESSION_KEY
2021.03.31 13:08:03.226 *D* [client.session.1   ] Sending message CMD_REQUEST_COMPLETED (32 bytes)
2021.03.31 13:08:03.230 *D* [client.session.1   ] Received message CMD_LOGIN
2021.03.31 13:08:03.230 *D* [client.session.1   ] authentication type 0
2021.03.31 13:08:03.230 *D* [client.session.1   ] Protocol level compression is supported by client
2021.03.31 13:08:03.230 *D* [client.session.1   ] User [email protected] authenticated (language=en clientInfo="nxjclient/3.8.250 (Linux 4.19.0-14-amd64; libnxcl 3.8.250)")
2021.03.31 13:08:03.230 *D* [client.session.1   ] Sending compressed message CMD_LOGIN_RESP (304 bytes)
2021.03.31 13:08:03.235 *D* [client.session.1   ] Received message CMD_GET_OBJECT_CATEGORIES
2021.03.31 13:08:03.235 *D* [client.session.1   ] Sending message CMD_REQUEST_COMPLETED (48 bytes)
2021.03.31 13:08:03.235 *D* [client.session.1   ] Received message CMD_GET_OBJECTS
2021.03.31 13:08:03.235 *D* [client.session.1   ] Sending message CMD_REQUEST_COMPLETED (32 bytes)
2021.03.31 13:08:03.237 *D* [client.session.1   ] Sending compressed message CMD_OBJECT (720 bytes)
2021.03.31 13:08:03.238 *D* [client.session.1   ] Sending compressed message CMD_OBJECT (352 bytes)
2021.03.31 13:08:03.238 *D* [client.session.1   ] Sending compressed message CMD_OBJECT (336 bytes)
2021.03.31 13:08:03.238 *D* [client.session.1   ] Sending compressed message CMD_OBJECT (296 bytes)

2. Successful login, but with quite some delay. Note there is a 7 second delay between "Sending message CMD_REQUEST_SESSION_KEY" and "Received message CMD_SESSION_KEY":

2021.03.31 13:09:28.943 *D* [                   ] SocketListener/Clients: Incoming connection from 127.0.0.1
2021.03.31 13:09:28.943 *D* [                   ] SocketListener/Clients: Connection from 127.0.0.1 accepted
2021.03.31 13:09:28.943 *D* [client.session     ] Client session with ID 1 registered
2021.03.31 13:09:28.951 *D* [client.session.1   ] Received message CMD_GET_SERVER_INFO
2021.03.31 13:09:28.951 *D* [client.session.1   ] Server time zone: UTC+00UTC
2021.03.31 13:09:28.951 *D* [client.session.1   ] Sending message CMD_REQUEST_COMPLETED (616 bytes)
2021.03.31 13:09:28.954 *D* [client.session.1   ] Received message CMD_REQUEST_ENCRYPTION
2021.03.31 13:09:28.954 *D* [client.session.1   ] Sending message CMD_REQUEST_SESSION_KEY (344 bytes)
2021.03.31 13:09:36.078 *D* [client.session.1   ] Received message CMD_SESSION_KEY
2021.03.31 13:09:36.080 *D* [client.session.1   ] Sending message CMD_REQUEST_COMPLETED (32 bytes)
2021.03.31 13:09:36.083 *D* [client.session.1   ] Received message CMD_LOGIN
2021.03.31 13:09:36.083 *D* [client.session.1   ] authentication type 0
2021.03.31 13:09:36.083 *D* [client.session.1   ] Protocol level compression is supported by client
2021.03.31 13:09:36.083 *D* [client.session.1   ] User [email protected] authenticated (language=en clientInfo="nxjclient/3.8.250 (Linux 4.19.0-14-amd64; libnxcl 3.8.250)")
2021.03.31 13:09:36.083 *D* [client.session.1   ] Sending compressed message CMD_LOGIN_RESP (304 bytes)
2021.03.31 13:09:36.091 *D* [client.session.1   ] Received message CMD_GET_OBJECT_CATEGORIES
2021.03.31 13:09:36.091 *D* [client.session.1   ] Sending message CMD_REQUEST_COMPLETED (48 bytes)
2021.03.31 13:09:36.091 *D* [client.session.1   ] Received message CMD_GET_OBJECTS
2021.03.31 13:09:36.091 *D* [client.session.1   ] Sending message CMD_REQUEST_COMPLETED (32 bytes)
2021.03.31 13:09:36.095 *D* [client.session.1   ] Sending compressed message CMD_OBJECT (720 bytes)
2021.03.31 13:09:36.095 *D* [client.session.1   ] Sending compressed message CMD_OBJECT (352 bytes)
2021.03.31 13:09:36.095 *D* [client.session.1   ] Sending compressed message CMD_OBJECT (336 bytes)
2021.03.31 13:09:36.095 *D* [client.session.1   ] Sending compressed message CMD_OBJECT (296 bytes)
2021.03.31 13:09:36.096 *D* [client.session.1   ] Sending compressed message CMD_OBJECT (288 bytes)
[...]

3. Unsuccessful connection attempt. 30 seconds after "Sending message CMD_REQUEST_SESSION_KEY" the server is giving up, but nxshell hangs forever:

2021.03.31 13:10:48.138 *D* [                   ] SocketListener/Clients: Incoming connection from 127.0.0.1
2021.03.31 13:10:48.138 *D* [                   ] SocketListener/Clients: Connection from 127.0.0.1 accepted
2021.03.31 13:10:48.138 *D* [client.session     ] Client session with ID 1 registered
2021.03.31 13:10:48.146 *D* [client.session.1   ] Received message CMD_GET_SERVER_INFO
2021.03.31 13:10:48.146 *D* [client.session.1   ] Server time zone: UTC+00UTC
2021.03.31 13:10:48.146 *D* [client.session.1   ] Sending message CMD_REQUEST_COMPLETED (616 bytes)
2021.03.31 13:10:48.148 *D* [client.session.1   ] Received message CMD_REQUEST_ENCRYPTION
2021.03.31 13:10:48.148 *D* [client.session.1   ] Sending message CMD_REQUEST_SESSION_KEY (344 bytes)
2021.03.31 13:11:18.148 *D* [client.session.1   ] Sending message CMD_REQUEST_COMPLETED (32 bytes)
2021.03.31 13:11:18.148 *D* [client.session.1   ] readSocket: connection closed
2021.03.31 13:11:18.148 *D* [                   ] *Locks* All locks for session 1 removed
2021.03.31 13:11:18.148 *D* [                   ] Closing all logs for session 1
2021.03.31 13:11:18.148 *D* [client.session.1   ] Session closed
2021.03.31 13:11:18.149 *D* [client.session     ] Client session with ID 1 unregistered
2021.03.31 13:11:18.149 *D* [client.session.1   ] Socket closed
2021.03.31 13:11:18.149 *D* [client.session.1   ] Session object destroyed

We have a small number of sockets in TIME_WAIT in netstat (typically one socket, sometimes two), seemingly caused by unsuccessful connection attempts.

Hi,

I'm trying to use nxshell to setup nodes, get some DCI values, etc. Mostly it's working fine, but sometimes nxshell hangs at the "INFO org.netxms.client.NXCSession - Connecting to localhost:4701" stage. If it does, I have to abort that command and wait a bit before trying again, as it seems that waiting only a few seconds is not enough and the next connection attempt is hanging again.

There is only minimal load on the server, because this is a test setup with only two nodes. I'm running nxshell directly on the server.

Can I define a connection timeout so that I don't have to abort the command manually? Do you have any idea why subsequent connection attempts also fail and how I can avoid this?

Thanks a lot,

  Hendrik

Hi,

I can't get nxapush to work. I have a DCI called "LOCAL_TEST" with "push"
origin, the node is the server itself, and on the server I'm running this:

$ nxapush -vv LOCAL_TEST=7
1 data pair to send
Connected to NetXMS agent
Disconnected from NetXMS agent

nxapush doesn't complain, but the value doesn't show up in the "Last Values" table.

I've also tried to push to other nodes using "nxapush -vv -o 299 LOCAL_TEST=7" where 299 is the nodeId to which the DCI belongs. Again, the value doesn't make it to the node. CheckTrustedNodes is disabled in the server configuration.

What am I missing?

Thanks a lot,

  Hendrik

Great, that works! Thanks!

I still think a "setThresholds()" method would be nice, but I'm glad I can go on now.   

Brief update: Looking at the netxms-client sources it seems that there is no setThreshods() method for DataCollectionItem. I think something like this needs to be added to org/netxms/client/datacollection/DataCollectionItem.java:

	/**
	 * @param thresholds the thresholds to set
	 */
	public void setThresholds(ArrayList<Threshold> thresholds)
	{
		this.thresholds = thresholds;
	}

Is that correct?

Hi,

I'm using the java API to create DCIs. This works fine for the basic stuff like name, description, polling interval, etc. But how can I attach a Threshold object to the DataCollectionItem?

Thanks a lot,

Hendrik

Hi,

I've got a router with a /64 IPv6 prefix and a Linux host connected to it. The linux kernel obtains an address using SLAAC and says it's a /64 (e.g. fd11:1111:1111:1111:abcd:abff:fecd:abcd/64). If I try to add both machines as nodes to NetXMS, the first works fine, but for the second I get an "ip conflict with node xxx" error.

What's the best solution for this setup?

Thanks,

  Hendrik

Good idea, works fine! Thanks a lot!

Ah, that works! Thanks!

But this triggers another question: My plan was to have a DCI that is updated every hour through SNMP polls and additionally through SNMP traps triggering PushDCIData() (whenever the value changes on the client). Is there a clever way of doing this? Maybe always use traps? Or can I update DCIs through SNMP traps using a different mechanism than PushDCIData()?