Nagios Support Forum

I have compiled NSCA with libmcrypt on omnios, an solaris/illumos variant.

Whenever NSCA requests are received, NSCA responds with a very large number, such as "Time difference in packet: 11018287". This can be worked around with setting "max_package_age=0" but ideally I would like to get to the bottom of this. Encryption works with this setting as well as sending unencrypted. If i do not set "max_package_age=0", unencrypted or not always fails with time differences.

I have compiled WITHOUT libmcrypt support and NSCA functions correctly and has no problems with time differences.

Both NSCA and libmcrypt have been compiled as 64 bits, with only prefix as a configure option. NSCA finds libmcrypt via CFLAGS & LDFLAGS.

so I would appreciate any feedback at what might be making this combination bork the timestamp?

It looks like this is just a debugging message:

Try setting debug=0 in the nsca.cfg file and restarting the service.

The source can be found at https://raw.githubusercontent.com/Nagio ... src/nsca.c.

thanks for your response, I am looking at the nsca.c code now.

yes it is a debug message, but NSCA drops the package, and the service will then become stale.

everytime send_nsca sends to NSCA, it is the exact same time difference,11018287, so I am thinking it is something to do with the setting up on the current_time and packet_time variables.

in NSCA WITHOUT libmcrypt, I set 2 new debug messages directly under that debug message: and the debug message in log when run is: shouldn't current time be showing seconds from epoch, ie 1586812468, rather than 0?
I

Are both systems time settings the same? (time, TZ, etc)

What version of NSCA exactly?

yes, both time zones match. also I have tried from a third host sending to the NSCA daemon and time differences are always the same.

the version is 2.9.2.

I have decided to use NRDP instead of NSCA so I do not necessarily need a resolution to this.

That's what I would use as well.

Are we okay to lock this up then? If you're switching I'm not going to run down the rabbit hole as I haven't seen this before.

2.10 was released earlier this month if you want to test NSCA again:

https://github.com/NagiosEnterprises/ns ... ANGELOG.md

There does appear to have been a changes to the nsca.c file including the packet_age variable.

I will definitely have a look at 2.1.0 over the weekend

leave this open and I will let you know what I find.

Philip

NSCA maintainer here,

Just wanted to let you know that I did take a look into this. I suspect 2.10.0 will "fix" your issue, but not in the way you wanted.

It looks like the packet_age check was actually removed in this commit. What's really strange is that even in the 2.9.2 release, the packet age and current time are left uninitialized, meaning the check was useless to begin with. As for why we haven't seen this before, I'm guessing that there was something slightly different in the stack layout on your Unix+?? system than in the CentOS+gcc systems we tend to use for testing.

In short, if you're planning to use NRDP anyways, don't feel pressured to do any more work with this.

Regards,
Sebastian Wolf

Hi ,

yeah, i looked at that and was not brave enough to say that it was not being initialized, i have a very low/no skill in C so did not want to point out something, that would surely have been pointed out in NSCAs long history. go figure.

thanks for your post. that has cleared up a lot and I am happy using NSCA without package age set.

Philip