Bug #2215
closed
Lost events writing to unix socket
Added by Fanny Dwargee about 7 years ago.
Updated almost 7 years ago.
Description
Hi,
when using the pcap offline analysis and configured Suricata for writing eve-log events to a unix stream socket some events can be lost.
Find attached a pcap with a lot of DNS events (malware generated), first I wrote in Python a UNIX stream socket server for reading the eve log events and surprisingly some events were lost because Suricata was lot quicker writing to the socket than my code reading from it so using the "send()" primitive returned an EAGAIN error.
After that, instead of coding a C UNIX server I used the socat utility and unfortunately the same behaviour was observed.
IMHO a minimal wait would be sufficient when using a UNIX socket for eve log events.
Tested on GitHub master branch with latest commit https://github.com/inliniac/suricata/commit/499afaba4bc4624afa9e7d7e7648f9070ea5d37d
I'm going to send a PR to the GitHub repository with a new eve log option named 'unix-retry-wait' where you can set the microseconds for waiting before retry a write on a UNIX stream socket with the write queue full
Files
|
timeout.pcap (540 KB)
timeout.pcap |
PCAP with a lot of DNS flows (keep care, malware generated) |
Fanny Dwargee, 09/20/2017 12:07 PM
|
|
I think a better fix would be to allow blocking when not running live. This would mean no lost events due to a blocking socket when using pcaps and no configuration change required between live and file reading.
I don't think any wait is acceptable in live mode, as it does hold up processing packets.
- Assignee set to OISF Dev
- Target version set to TBD
I get your point and it's a really good one but I'm not totally convinced. :)
Why not let the user choose if waiting is acceptable or not?
Some will prefere to wait while others won't, in any case I think the user is the more appropriate one to decide what really needs and that's the point of the configuration option.
I think a better fix will be to take into account not being in live mode to make the wait but keep on using nonblocking sockets, IMHO it's a more balanced choice.
...so that would be a mix between your idea and the initial one (I'm sorry but I don't know how to edit a post)
My apologies,
I think my initial explantion lacks how I'm using Suricata, I'm controlling Suricata from a unix socket and use that for analyzing pcap files.
The command line used is:
- suricata -vv --unix-socket -c /usr/local/etc/suricata/suricata.yaml
...so Suricata runs in UNIX_MODE
- Status changed from New to Assigned
- Assignee changed from OISF Dev to Danny Browning
- Tracker changed from Optimization to Bug
Found to be a bug in not determining correctly run runmode is offline, and thus setting blocking socket for unix socket outputs.
- Status changed from Assigned to Closed
- Target version changed from TBD to 4.0.2/4.0.3
Also available in: Atom
PDF