Re: General MoBlock thread

Originally Posted by jre

Strange ....
Please look in /var/log/moblock-control.log what is happening at the time when moblock reloads. From moblock-control this will only happen on "update" (either manually or by the cron job) or "reload".
I'm not the author of MoBlock (the daemon). Maybe there is something built in there that reloads it frequently.

Re: General MoBlock thread

Well, then I have to say I have no idea why this happens.
I've never heard of it, but maybe there's a cron job sending the SIGHUP (kill -s HUP/1 PID) to all processes. If anybody can explain this ...
I'll note this down in BUGS with a link to your post.

Re: General MoBlock thread

Originally Posted by jre

Well, then I have to say I have no idea why this happens.
I've never heard of it, but maybe there's a cron job sending the SIGHUP (kill -s HUP/1 PID) to all processes. If anybody can explain this ...
I'll note this down in BUGS with a link to your post.

Re: General MoBlock thread

@skipo, logrotate:
oops, I should have thought of that. Of course, after logrotation a new logfile needs to be opened, therefore the reloading. So everything is ok here. Thanks for figuring that out on your own!

@lovinglinux, intrepid problems:
first time I hear this. What's in the logfiles? Does "moblock-control start" work? What's happening if you start mobloquer from the console?

@skipo: unbinding from NFQUEUE
I changed the default NFQUEUE number to 92 (instead of 0) in moblock-control 1.0 (the current version), to avoid conflicts with other firewalls. So I don't know where the queue 0 stems from - it should always be 92.
Have you any other applications that use NFQUEUE?
Did you have the unbind in previous versions, too?
For the records: Please post "dpkg -l libnetfilter-queue* libnfnetlink*".
It might be a bug in these libraries or in moblock, which occurs only for non-default queue numbers (= not 0).

Re: General MoBlock thread

The error message in the code has a queue number of 0 hard coded, so it's misreporting the queue it just unbound from. I've seen the error myself, with moblock the only application using nfqueue.

If i'm understanding the code correctly, then recv() is used to read a message from kernelspace and passed to nfq_handle_packet() for parsing. The unbind error should only ever occur if the recv() returns an error which generally should never happen

After doing some more reading, recv() gets the data from netlink socket, prior to any queuing happening. The code doesn't capture the error code when this fails, but it could be due to a lack of buffer space (especially under high load). The l7 userspace filter code suggest the following;

If you get error messages about running out of buffer space, increase it with something like:

Re: General MoBlock thread

The article is aimed at snort_inline users, but the majority of it applies to moblock as well. Moblock doesn't currently allow the max queue size to be changed from the default, however I've just submitted a patch that allows this value to be tuned on the moblock developer site. The patch also fixes the misreported queue number in the error message and should hopefully print the error that caused moblock to unbind in the first place