[Oisf-devel] Suggestions about feature #447

giuseppe at securitymind.it giuseppe at securitymind.it
Sat Jan 19 14:47:29 UTC 2013

On Sat, 19 Jan 2013 14:14:30 +0100, Victor Julien <victor at inliniac.net>
> On 01/19/2013 11:17 AM, giuseppe at securitymind.it wrote:
>> On Fri, 18 Jan 2013 10:38:17 +0100, Victor Julien <victor at inliniac.net>
>> wrote:
>>> On 01/16/2013 03:29 PM, giuseppe at securitymind.it wrote:
>>>>> What the timeout value should be set to is the destination OS' value.
>>>> When it's reset, timeout value must be:
>>>> tracker->timeout = Destination OS Value?
>>>> or
>>>> tracker->timeout = p->ts.tv_sec + defrag_context->timeout + Destination
>>>> OS Value;
>>>> ?
>>> I'd say just:
>>> tracker->timeout = p->ts.tv_sec + Destination OS Value;
>>> If we don't know "Destination OS Value" for some reason, fall back to
>>> "defrag_context->timeout".
>> Good morning,
>> I did commit the code I wrote, of course, is not yet finished.
>> But I would like some feedbacks, suggestions, etc..
>> Here you can see information about the commit:
>> https://github.com/glongo/suricata/commit/f941c344fe87accfe90b1391f2135119a63017a1
> I think this would work, but it can probably done in a more optimized
> way. The OS of the 2 hosts in the tracker will not change, so ideally
> you'd be looking them up only once per host for each tracker.

What would you say? Do I have to change something in the code?
(Except the opmitization)

>> In addition, I would ask:
>> the value of frag_pool_size can be reset for each packet sent?
> What would be the reason for that?

In some OSs, such as Solaris and FreeBSD, ip fragmentation timeout
isn't time based, but packet limit
(as discuss here: https://redmine.openinfosecfoundation.org/issues/417)

>> the ip frag timeout values must be an option in yaml file? Otherwise,
>> how can I set these these values?
> I think as a first step it's great to use the defaults for each OS. Then
> as a 2nd step it would be good to be able to set them to some other value.

Ok, this is the 2nd step!

More information about the Oisf-devel mailing list