Hi,
On Thu, 2011-08-18 at 12:11 -0500, Fernando Ortiz wrote:
> 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
If it compiled, it is ok. Segfault is just random :P
BR,
>
>
> 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
>
--
Eric Leblond
Blog: http://home.regit.org/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: <http://lists.openinfosecfoundation.org/pipermail/oisf-users/attachments/20110818/25ac11dc/attachment.sig>