[Oisf-users] Packets stucked in Nfqueue when running inline

Fernando Ortiz fernando.ortiz.f at gmail.com
Thu Aug 18 17:11:43 UTC 2011


I changed this:
*ret = nfq_set_verdict2(t->qh, p->nfq_v.id, NF_DROP, 0, 0, NULL);*
to this:
*ret = nfq_set_verdict2(qh, p->nfq_v.id, NF_DROP, 0, 0, NULL);*

It compiled. Is it ok ? :P

source-nfq.c:

static int NFQCallBack(struct nfq_q_handle *qh, struct nfgenmsg *nfmsg,
              struct nfq_data *nfa, void *data)
{
    NFQThreadVars *ntv = (NFQThreadVars *)data;
    ThreadVars *tv = ntv->tv;
    int ret;

.......

        SCLogWarning(SC_ERR_NFQ_HANDLE_PKT, "NFQ setup failure");
#ifdef HAVE_NFQ_SET_VERDICT2
      *  *ret = nfq_set_verdict2(qh, p->nfq_v.id, NF_DROP, 0, 0, NULL);**
#else
        ret = nfq_set_verdict(qh, p->nfq_v.id, NF_DROP, 0, NULL);
#endif
        if (ret < 0) {


2011/8/18 Fernando Ortiz <fernando.ortiz.f at gmail.com>

> (Forgot to send this to the list too)
>
> All patches worked find. I got this error again, though
>
> source-nfq.c: In function âNFQCallBackâ:
> source-nfq.c:328:32: error: âtâ undeclared (first use in this function)
> source-nfq.c:328:32: note: each undeclared identifier is reported only once
> for each function it appears in
>
> Regards
>
> 2011/8/18 Fernando Ortiz <fernando.ortiz.f at gmail.com>
>
>> All patches worked find. I got this error again, though
>>
>> source-nfq.c: In function âNFQCallBackâ:
>> source-nfq.c:328:32: error: âtâ undeclared (first use in this function)
>> source-nfq.c:328:32: note: each undeclared identifier is reported only
>> once for each function it appears in
>>
>>
>>
>> 2011/8/18 Fernando Ortiz <fernando.ortiz.f at gmail.com>
>>
>>> Great! I will test this and keep you informed.
>>>
>>> Thanks
>>>
>>>
>>> 2011/8/18 Eric Leblond <eric at regit.org>
>>>
>>>> Hello,
>>>>
>>>> On Thu, 2011-08-18 at 10:32 -0500, Fernando Ortiz wrote:
>>>> > I had problems with both patches:
>>>>
>>>> Oups, at least 4 patches were missing on the way from origin/master to
>>>> this two patches.
>>>>
>>>> In attachement please find the result of a cherry-pick party of all my
>>>> commits on NFQ. They have been applied on origin/master and this should
>>>> thus apply easily on your side.
>>>>
>>>> BR,
>>>>
>>>> >
>>>> > Patch 1:
>>>> > patching file source-nfq.c
>>>> > Hunk #1 FAILED at 247.
>>>> > Hunk #2 FAILED at 320.
>>>> > 2 out of 2 hunks FAILED -- saving rejects to file source-nfq.c.rej
>>>> >
>>>> >
>>>> > Patch 2:
>>>> > patching file decode.h
>>>> > patching file source-ipfw.c
>>>> > Hunk #1 FAILED at 518.
>>>> > 1 out of 1 hunk FAILED -- saving rejects to file source-ipfw.c.rej
>>>> > patching file source-nfq.c
>>>> > Hunk #1 FAILED at 339.
>>>> > Hunk #2 FAILED at 918.
>>>> > 2 out of 2 hunks FAILED -- saving rejects to file source-nfq.c.rej
>>>> > patching file source-nfq.h
>>>> > patching file tmqh-packetpool.c
>>>> > Hunk #1 succeeded at 49 with fuzz 1.
>>>> > Hunk #2 FAILED at 159.
>>>> > Hunk #3 FAILED at 192.
>>>> > 2 out of 3 hunks FAILED -- saving rejects to file
>>>> > tmqh-packetpool.c.rej
>>>> >
>>>> >
>>>> > I manually edited the files. But still have problems in compilation.
>>>> > Specifically with patch 1
>>>> >
>>>> >
>>>> > source-nfq.c: In function âNFQCallBackâ:
>>>> > source-nfq.c:322:32: error: "t" undeclared (first use in this
>>>> > function)
>>>> > source-nfq.c:322:32: note: each undeclared identifier is reported only
>>>> > once for each function it appears in
>>>> >
>>>> >
>>>> >
>>>> >
>>>> > source-nfq.c: In function "NFQSetVerdict":
>>>> > source-nfq.c:798:2: warning: âreturnâ with no value, in function
>>>> > returning non-void
>>>> >
>>>> >
>>>> > In my source-nfq.c I had this function declaration.
>>>> > void NFQSetVerdict(Packet *p) {
>>>> >
>>>> >
>>>> > But in the patch 2, it looks like that function returns TmEcode
>>>> > TmEcode NFQSetVerdict(Packet *p) {
>>>> >
>>>> >
>>>> > I changed it, as it was in the patch thus there is a warning because
>>>> > there is a void return in the code.
>>>> >
>>>> >
>>>> > TmEcode NFQSetVerdict(Packet *p) {
>>>> >     int iter = 0;
>>>> >     /* can't verdict a "fake" packet */
>>>> >     if (p->flags & PKT_PSEUDO_STREAM_END) {
>>>> >           return;
>>>> >     }
>>>> >
>>>> >
>>>> > I am working with the last repository in git. Could you give a hand
>>>> > please?
>>>> >
>>>> >
>>>> >
>>>> > 2011/8/17 Fernando Ortiz <fernando.ortiz.f at gmail.com>
>>>> >         Great! I will test both right now. Thank you.
>>>> >
>>>> >
>>>> >
>>>> >         2011/8/17 Eric Leblond <eric at regit.org>
>>>> >                 Hello again,
>>>> >
>>>> >                 On Wed, 2011-08-17 at 16:53 +0200, Eric Leblond wrote:
>>>> >                 > Hi again,
>>>> >                 >
>>>> >                 > On Wed, 2011-08-17 at 16:28 +0200, Eric Leblond
>>>> >                 wrote:
>>>> >                 > > Hello,
>>>> >                 > >
>>>> >                 > > On Tue, 2011-08-16 at 14:30 -0500, Fernando Ortiz
>>>> >                 wrote:
>>>> >                 > > > Sorry the late of the answer. I got a server to
>>>> >                 make more test in
>>>> >                 > > > production again.
>>>> >                 > >
>>>> >                 > > No problem, I was on holiday :P
>>>> >                 > >
>>>> >                 > > > I patched Suricata. I still have the same
>>>> >                 problem with packets stucked
>>>> >                 > >
>>>> >                 > > Bad news.
>>>> >                 > >
>>>> >                 > > If you have some time, could you test the attached
>>>> >                 patch.
>>>> >                 >
>>>> >                 > This is not necessary to test this patch: I've
>>>> >                 continued to study the
>>>> >                 > problem. There is an issue with the code pointed out
>>>> >                 by the patch but
>>>> >                 > this can not explain the problem.
>>>> >
>>>> >
>>>> >                 Two patches will follow this mail. The fist one
>>>> >                 improves the error
>>>> >                 handling in NFQ and suppress one of the potential
>>>> >                 source of ghost
>>>> >                 packets. The second one is more generic but it should
>>>> >                 fix one other
>>>> >                 potential source.
>>>> >
>>>> >                 Both patches display explicit message in log level
>>>> >                 warning. If something
>>>> >                 occurs, you will not missed it.
>>>> >
>>>> >                 BR,
>>>> >                 --
>>>> >
>>>> >                 Eric Leblond
>>>> >                 Blog: http://home.regit.org/
>>>> >
>>>> >
>>>> >
>>>> >
>>>> >
>>>> >
>>>> >
>>>> >
>>>> >
>>>> >
>>>> >
>>>> >
>>>>
>>>> --
>>>> Eric Leblond
>>>> Blog: http://home.regit.org/
>>>>
>>>
>>>
>>>
>>> --
>>> Fernando Ortiz
>>> Twitter: http://twitter.com/FernandOrtizF
>>>
>>>
>>
>>
>>
>> --
>> Fernando Ortiz
>> Twitter: http://twitter.com/FernandOrtizF
>>
>>
>
>
>
> --
> Fernando Ortiz
> Twitter: http://twitter.com/FernandOrtizF
>
>



-- 
Fernando Ortiz
Twitter: http://twitter.com/FernandOrtizF
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openinfosecfoundation.org/pipermail/oisf-users/attachments/20110818/eabd9f73/attachment-0002.html>


More information about the Oisf-users mailing list