Unirecfilter startup race

[qha]

Unirecfilter sometimes gets itself into a bad state, i think it is when it is started at about the same time as all other Nemea modules.

When it gets into this state it keeps answering output ifc negotiations with trap_fmt_unknown.

A workaround that succeeds most of the time is to enter the supervisor_cli and restart just the unirecfiltermodule we run and then reloading the configuration causing downstream modules that have been automatically disabled to be reenabled and restarted.

Log files for the unirecfiltermodule we run are attached in egressfilter-logs.zip.

I might try again to produce a pull request for this issue but my initial attempts have failed.

[qha]

And, of course, please let me know if we can supply any other info to help diagnose this issue!

[janskto1]

This issue should be finally fixed in next version of libtrap.
More info about the bug can be found in the following pull request:
CESNET/Nemea-Framework#99

It would be lovely if you could confirm whether the provided fix solves this issue.

Thank you for reporting the bug.

[qha]

It will be hard to give a credible confirmation but i will certainly test this and if i haven't seen the problem agian in a while it is probably fixed.

I am however a bit backlogged after my summer vacation and then the course in Prague back to back so it may take a while until i get back.

[qha]

We have been running the haddrscan detector in production now in three instances with somewhat of a maze of unirecfilter instances before and after it for quite a while now. This has been quite stable the last months and i really think that this configuration should have exposed this bug if it were still around.

[janskto1]

Thanks for the feedback. I honestly believe the problem was fixed. If you encounter any other problems be sure to let us know.

PS: Happy bug-free year 2019. :-)