Skip site navigation (1)Skip section navigation (2)

FreeBSD Manual Pages


home | help
Net::NSCA::Client::TroUsersContributed PeNet::NSCA::Client::Troubleshooting(3)

       Net::NSCA::Client::Troubleshooting - Troubleshooting information

   Dropping packet with	invalid	CRC32
       When a packet is	sent to	the NSCA server	and the	following errror
       appears in the server log:

	 Dropping packet with invalid CRC32 - possibly due to client using wrong password or crypto algorithm?

       This can	be cause by a number of	reasons, as NSCA provides this as a
       catch-all error message.

       Wrong "encryption_type" set

       It is possible the client is not	sending	the packet using the correct
       encryption type.	Currently this module only support no encryption or
       the "XOR" encryption. If	the server is expecting	something different,
       this is not going to work.

       Wrong "encryption_password" set

       It is possible that the client is not using the current encryption
       password. Please	double-check that the client and the server are	using
       the same	password.

       NSCA server compiled using custom constants

       It is possible that the NSCA server was compiled	with the constants
       relating	to the packet changed. If you changed the constants when
       compiling NSCA, you will	need to	setup the client to use	the same
       constant	values.	 See Net::NSCA::Client::ServerConfig on	how to change
       these constants for the client.

   Data	sent from client was too short
       This message indicates that the data packet the client is sending to
       the server is too small.	Unless there was a connection issue, the only
       reason this would occur is if the NSCA's	data packet constants where
       changed and the client needs Net::NSCA::Client::ServerConfig to be set
       to the current values.

   Received invalid packet type/version	from client
       This client will	always send version 3 packets. If the server is
       expecting version 3 packets and you get this message, the wrong
       "encryption_type" or "encryption_password" is set.

   Dropping packet with	future timestamp
       The time	stamp that is sent with	the data packet	is checked on the NSCA
       server to be sure it is not in the future. The time stamps are sent as
       the number of non-leap seconds since January 1, 1970 in UTC. This
       indicates that either the server's time is falling behind or the
       client's	time is	set too	far ahead.

   Dropping packet with	stale timestamp
       Check the "max_packet_age" variable in the server configuration.	Either
       the packet really is exceeding this age (getting	stuck in the network)
       or the server and/or client times are not set correctly.

perl v5.32.0			  2020-08Net::NSCA::Client::Troubleshooting(3)


Want to link to this manual page? Use this URL:

home | help