New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Tpacket v3 11 #2052
Tpacket v3 11 #2052
Conversation
No need for cooked header in the case of mmap capture.
This patch adds a basic implementation of AF_PACKET tpacket v3. It is basic in the way it is only working for 'workers' runnning mode. If not in 'workers' mode there is a fallback to tpacket_v2. Feature is activated via tpacket-v3 option in the af-packet section of Suricata YAML.
Reorder fields in AFPThreadVars and suppress some that were not used elsewhere than in the initialization.
Suppress useless fields in AFPThreadVars. This patch also get rid of bytes counter as it was only used to display a message at exit. Information on livedev and on packet counters are enough.
Error handling was not done. The implementation is making the choice to consider we must detroy the socket in case of parsing error. The same was done for tpacket_v2.
It is used to set the block size in tpacket_v3. It will allow user to tune the capture depending on his bandwidth. Default block size value has been updated to a bigger value to allow more efficient wlak on block.
Block timeout defines the maximum filling duration of a block.
If TPACKET_V3 is not defined then it is not available and we should not build anything related to tpacket_v3. This will allow us to activate it dy default and fallback to v2 if not available.
Update the code to use mmap capture by default even in unset in configuration file. mmap capture is now be turned off by using explicitely 'use-mmap: no' in configuration.
We can loose packets during setup because we are reading nothing. So it is logical to discard the counter at start of capture to start from a clean state. This means we don't need to account the drop at start. But the stats call that will reset the drop counts will also return and reset the packets count. So we need to know how many packets we really have. This is in fact the number of packets coming from the stats call minus the number of discarded packets and the drop count. All the other packets will have to be read.
Only parse them if mmap is activated.
As we only use the second we don't need GetTime() which is slower and get us milliseconds.
On an interface with mtu 9000 block_size 8192 doesn't work: [4380] 3/5/2016 -- 09:19:25 - (source-af-packet.c:1614) (AFPComputeRingParamsV3) -- [ERRCODE: SC_ERR_INVALID_VALUE(130)] - Block size is too small, it should be at least 9104 This makes sense, however I think you said somewhere the block_size for V3 should be a power of 2? If so this warning is inaccurate. |
Do you want an update of text to say "Block size is too small, it should be a power of 2 superior to 9104" ? |
On 03-05-16 09:41, Eric Leblond wrote:
Thats the lazy approach. If only we had a computer to actually calculate |
Something like:
|
Merged through #2091, thanks Eric! |
Update of #2036
Rebased on latest master and fix message if block size is too small.
PR builds: