[Oisf-users] Packets stucked in Nfqueue when running inline
Fernando Ortiz
fernando.ortiz.f at gmail.com
Thu Aug 18 17:02:46 UTC 2011
(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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openinfosecfoundation.org/pipermail/oisf-users/attachments/20110818/95cc9685/attachment-0002.html>
More information about the Oisf-users
mailing list