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

[Fernando Ortiz]

I had problems with both patches:

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/
>>
>
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openinfosecfoundation.org/pipermail/oisf-users/attachments/20110818/ab7cebf3/attachment-0002.html>