/ 
Net-NSCA-Client-0.009002
River stage zero No dependents
/ Net::NSCA::Client::Troubleshooting

NAME

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

COMMON SERVER ERROR MESSAGES

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.