General MoBlock thread

[skipo]

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.

Moblock-control.log doesn't say anything about reloading, but moblock.log gives following statement:

Fri Oct 31 13:00:10| Got SIGHUP! Dumping and resetting stats, reloading blocklist

[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.

[skipo]

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.

It's the logrotate. In /etc/logrotate.d/ is a file moblock:

/var/log/moblock.log {
        rotate 12
        daily
        compress
        delaycompress
        missingok
        notifempty
        postrotate
                [ ! -f /var/run/moblock.pid ] || kill -s HUP `cat /var/run/moblock.pid`
        endscript
}

Or is it moblock because it did put the file there...

[lovinglinux]

@jre,

moblock is not starting at boot on Intrepid and mobloquer is not working.

[skipo]

I'll note this down in BUGS with a link to your post.

If we are talking about bugs, sometimes this line appears in /var/log/moblock.log:

Mon Nov  3 11:25:21| NFQUEUE: unbinding from queue 0

After that, I have to restart moblock to get web working again.

I haven't changed the nfqueue number, so it should bind to the default queue, and it does after restart:

Mon Nov  3 11:33:52| NFQUEUE: binding to queue '92'

[jre]

@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).

[noblem]

Re: unbinding from NFQUEUE

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:

echo 524280 > /proc/sys/net/core/rmem_default
echo 524280 > /proc/sys/net/core/rmem_max
echo 524280 > /proc/sys/net/core/wmem_default
echo 524280 > /proc/sys/net/core/wmem_max

[lovinglinux]

@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?

Mea culpa! The problem was due to /etc/default/moblock permissions. I have replaced the one from fresh install with a copy and root user hasn't permission to read and write. Everything is working now.

[skipo]

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).

Here's the dpkg list:

Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Installed/Config-f/Unpacked/Failed-cfg/Half-inst/t-aWait/T-pend
|/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad)
||/ Name                Version        Description
+++-===================-==============-======================================
ii  libnetfilter-queue1 0.0.13-1       Netfilter netlink-queue library
ii  libnfnetlink0       0.0.25-1       Netfilter netlink library

I have no other applications using NFQUEUE.

[noblem]

I found this article about tuning netfilter performance;
http://www.inliniac.net/blog/2008/01...rformance.html

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

Matt