Added by Andreas Herz over 6 years ago. Updated almost 3 years ago.
Description
When logging to unix dgram socket the max message size is 64k. Goal is to test what happens if the messages we generate exceed that and come up with recommendations for how to handle this case.
I think its safer to use the unix_stream option. Syslog output may have the same issue depending on which syslog daemon and network transport is in use. Should be documented.
On a modern Linux system I hit failures somewhere between 200000 and 250000 bytes. Interestingly, the failure was inside Suricata, not on the receiver. Too large of a write fails. I was unable to create the condition where the received message may be truncated. This is a good thing I suppose.
I do expect messages to be truncated when done over a UDP socket however, but we don't support that mode.
On FreeBSD the message size does appear be 65535 (at least by default). But like in Linux, the error is on Suricata's side where the message fails to send:
[100599] 22/4/2021 -- 11:40:00 [CS:logopenfile] - <Warning> -- [ERRCODE: SC_ERR_SOCKET(200)] - Write error on Unix socket "/tmp/suricata": Message too long; reconnecting...
In my opinion we don't have an issue here to worry about. Suricata will clearly fail, and the option is to move to unix_stream, or a file out.
NOTE: I had to modify the code to generate messages this size, but it doesn't mean that a logging situation couldn't be created to get to this size.
Even 5000 bytes seems to large for FreeBSD (at least on a default install).
The error message should probably indicate that the user should switch to unix_stream? And/or that certain options should be disabled, like payload logging?
Jason Ish wrote in #note-5:
On a modern Linux system I hit failures somewhere between 200000 and 250000 bytes.
Hit the same problem, the reason for this range seems to be the system limit of /proc/sys/net/core/wmem_max
Switching unix_stream doesnt solve the problem altogether. There are limits there as well.