Moblock-control.log doesn't say anything about reloading, but moblock.log gives following statement:
Code:Fri Oct 31 13:00:10| Got SIGHUP! Dumping and resetting stats, reloading blocklist
Printable View
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:
Or is it moblock because it did put the file there...Code:/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
}
@jre,
moblock is not starting at boot on Intrepid and mobloquer is not working.
If we are talking about bugs, sometimes this line appears in /var/log/moblock.log:
After that, I have to restart moblock to get web working again.Code:Mon Nov 3 11:25:21| NFQUEUE: unbinding from queue 0
I haven't changed the nfqueue number, so it should bind to the default queue, and it does after restart:
Code:Mon Nov 3 11:33:52| NFQUEUE: binding to queue '92'
@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: 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;
Quote:
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
Here's the dpkg list:
I have no other applications using NFQUEUE.Code: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 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