Re: (nfnl_talk: recvmsg over-run) and (nf_queue: full at 1024 entries, dropping packets(s). Dropped: 582) - bug or just some defaults increase required?

[Anton <anton.vazir@gmail.com>]

Pablo,

Today (unpatched) case happened with increased buffer size 
to 10240, nice=0, trying with nice=-15
No dmesg messages on overflows. Just loop again. 
Patch yet not usable, since returns failure too often on 
queue creation. Any update from you?

Regards,
Anton.

On Thursday 12 February 2009 17:43, Pablo Neira Ayuso wrote:
> Anton wrote:
> > Pablo,
> >
> > Some more info. After applying the patch, If we do try
> > to just create 100 QUEUE's by the test code - on the
> > test PC, with _no_ transit traffic, routed to QUEUE's -
> > it works fine, queues created with no problem.
> > But if we do this on the live PC, with trasit traffic
> > routed to queues - we came to the problem once in a few
> > queues. We localized the place, and the sequence is as
> > follows: nfnl_query=>nfnl_catch=>nfnl_process
> >
> > and in the nfnl_process
> >
> > if (nlh->nlmsg_seq && nlh->nlmsg_seq != h->seq) {
> >                 errno = EILSEQ;
> >                 return -1;
> > }
> >
> > and varibales are
> > nlh->msg_seq=1234422225, h->seq=1234422229.
> >
> > EILSEQ=84
> > strerr(84) returns "Invalid or incomplete multibyte or
> > wide character"
> >
> > Any clue on this?
>
> There's some race condition. It seems that you're
> receiving packets from kernel-space to nfqueue before the
> ACK message from kernel-space to user-space to confirm
> subscription is send. Let me investigate this. Thanks for
> the accurate report.