Page 14 of 65 FirstFirst ... 412131415162464 ... LastLast
Results 131 to 140 of 650

Thread: General MoBlock thread

  1. #131
    Join Date
    Mar 2008
    Beans
    9

    Re: General MoBlock thread

    Just when I though I'd not seen the unbinding error on the RC of version 9, I got this after moblock did it's daily update the other morning;

    Thu Nov 13 07:36:08| NFQUEUE: unbinding from queue '92', recv returned No buffer space available

    So good news is my patch worked and captured the error, the bad news is when this happens moblock currently needs to be killed and restarted to bring it back to life. I've managed to replicate the issue which, for me, occurs under high load when a moblock-control restart is executed. While moblock is reloading the block files it's not processing packets and data is getting buffered, if too much data is buffered then we run out of buffer space and die.
    I've managed to find another bug that occurs when this happens, moblock tries to cleanly close the queue but the shutdown messages don't work because of the lack of buffers.
    I've created another patch that works around this and I've chosen to rebind the queue rather than exit, which works for me.
    Interestingly while I was testing I reduced the queue size and found the issue went away, however I had lots of these errors logged;

    nf_queue: full at 128 entries, dropping packets(s).

    So looks like with a smaller queue size the packets are dropped by the kernel before hitting moblock rather than hitting moblock and causing it to run out of buffers

    Matt

  2. #132
    Join Date
    Jan 2007
    Beans
    762

    Re: General MoBlock thread

    Hi noblem,

    first off thanks for your intensive investigations and your patches at moblock.berlios.de!
    I'm no programmer, but understand what you explain. Indeed this matches prior reports of unbinding which was fixed by only sending NEW traffic to MoBlock.
    What happens if you increase the buffer size (together with your other patches)?

    jre
    Last edited by jre; November 14th, 2008 at 06:26 PM.
    Please post your logfiles and output of commands wrapped in code tags:
    Code:
    [code]output[/code]
    Co-author of PeerGuardian Linux (pgl). Maintainer of the pgl package repositories for Debian and Ubuntu.

  3. #133
    Join Date
    Mar 2008
    Beans
    9

    Re: General MoBlock thread

    @jre I'm know programmer either but I understand enough of the the code to be able to figure out what it's doing and with the help of google hopefully fix it

    Only sending new packets to moblock would certainly help as moblock would have to buffer less data and therefore would be less likely to hit the issue.I've increased the buffers significantly but still run out of space under heavy load but only reloading the block lists but with my modifications moblock now rebinds to the queue and keeps going rather than dying. I'm not convinced this is the right approach on a reload, but it works for me.

    I've also come across this post on the netfilter-devel list which has a very good explanation of the causes of the issue

  4. #134
    Join Date
    Feb 2008
    Location
    The Netherlands
    Beans
    9
    Distro
    Kubuntu 8.10 Intrepid Ibex

    Re: General MoBlock thread

    Good evening,

    I'm sorry if this question was answered before, but I didn't find a clear answer on the first few pages...

    Anyway, moblock seems to block all http for me, while still allowing some other connections (I'm not entirely sure which, but I can talk over MSN, for example). Here is the output of 'sudo moblock-control status':

    Code:
    sevis@saruman-desktop:~$ sudo moblock-control status
    Current iptables rules (this may take awhile):
    
    Chain INPUT (policy ACCEPT 499K packets, 112M bytes)
     pkts bytes target     prot opt in     out     source               destination
        0     0 moblock_in  all  --  *      *       0.0.0.0/0            0.0.0.0/0           state NEW MARK match !0x14
    
    Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
     pkts bytes target     prot opt in     out     source               destination
        0     0 moblock_fw  all  --  *      *       0.0.0.0/0            0.0.0.0/0           state NEW MARK match !0x14
    
    Chain OUTPUT (policy ACCEPT 789K packets, 813M bytes)
     pkts bytes target     prot opt in     out     source               destination
        2   142 moblock_out  all  --  *      *       0.0.0.0/0            0.0.0.0/0           state NEW MARK match !0x14
    
    Chain moblock_fw (1 references)
     pkts bytes target     prot opt in     out     source               destination
        0     0 DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0           MARK match 0xa
        0     0 RETURN     all  --  *      *       192.168.1.0/24       192.168.1.0/24
        0     0 NFQUEUE    all  --  *      *       0.0.0.0/0            0.0.0.0/0           NFQUEUE num 92
    
    Chain moblock_in (1 references)
     pkts bytes target     prot opt in     out     source               destination
        0     0 DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0           MARK match 0xa
        0     0 RETURN     all  --  *      *       192.168.1.0/24       0.0.0.0/0
        0     0 RETURN     all  --  lo     *       0.0.0.0/0            0.0.0.0/0
        0     0 RETURN     all  --  *      *       192.168.0.0/24       0.0.0.0/0
        0     0 NFQUEUE    all  --  *      *       0.0.0.0/0            0.0.0.0/0           NFQUEUE num 92
    
    Chain moblock_out (1 references)
     pkts bytes target     prot opt in     out     source               destination
        0     0 REJECT     all  --  *      *       0.0.0.0/0            0.0.0.0/0           MARK match 0xa reject-with icmp-port-unreachable
        0     0 RETURN     all  --  *      *       0.0.0.0/0            192.168.1.0/24
        0     0 RETURN     all  --  *      lo      0.0.0.0/0            0.0.0.0/0
        0     0 RETURN     all  --  *      *       0.0.0.0/0            192.168.0.0/24
        0     0 RETURN     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:443
        0     0 RETURN     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:8080
        0     0 RETURN     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:80
        2   142 NFQUEUE    all  --  *      *       0.0.0.0/0            0.0.0.0/0           NFQUEUE num 92
    
    Please check if the above printed iptables rules are correct!
    
     * moblock is not running.
    Also, please note that moblock was running at that time - at least, I had used 'sudo moblock-control start', and it was blocking http quite successfully.

    In /etc/default/moblock, I have, after the autogenerated comments:

    Code:
    WHITE_IP_IN="192.168.0.0/24"
    WHITE_IP_OUT="192.168.0.0/24"
    WHITE_TCP_OUT="80 8080 443"
    Thank you!
    Sevis

  5. #135
    Join Date
    Apr 2005
    Beans
    25

    Re: General MoBlock thread

    Hi, jre, thanks for the good work.

    I have a problem that seems to be universally unanswered. So, I have ubuntu hardy server on an x86 router. The router hosts a wired lan and a wireless lan. I use Shorewall to configure iptables for maquerading and firewalling. What do I have to do to get moblock for filter the traffic for the router and the lans?

    If shorewall cannot be made to work with moblock easilly, what other firewall frontend should I use? Thanks,

  6. #136
    Join Date
    May 2008
    Beans
    2

    Re: General MoBlock thread

    I'm interested to hear an answer to this also. I have the same problem with the same /etc/default/moblock setup. Can get to my lan ok, but web is blocked. Maybe something to do with adding in TBG blocklists?

    *EDIT* - Took out these lines in my /etc/moblock/blocklists.list and it is working again:

    tbg.iblocklist.com/Lists/PrimaryThreats.zip
    tbg.iblocklist.com/Lists/GeneralCorporateRanges.zip
    tbg.iblocklist.com/Lists/BusinessISPs.zip
    tbg.iblocklist.com/Lists/SearchEngines.zip
    tbg.iblocklist.com/Lists/Educational-Institutions.zip
    tbg.iblocklist.com/Lists/Bogon.zip
    tbg.iblocklist.com/Lists/Hijacked.zip

    I had read the TBG lists were good to use, but I'll have to leave them out I guess.


    Quote Originally Posted by Sevis View Post
    Good evening,

    I'm sorry if this question was answered before, but I didn't find a clear answer on the first few pages...

    Anyway, moblock seems to block all http for me, while still allowing some other connections (I'm not entirely sure which, but I can talk over MSN, for example). Here is the output of 'sudo moblock-control status':

    Code:
    sevis@saruman-desktop:~$ sudo moblock-control status
    Current iptables rules (this may take awhile):
    
    Chain INPUT (policy ACCEPT 499K packets, 112M bytes)
     pkts bytes target     prot opt in     out     source               destination
        0     0 moblock_in  all  --  *      *       0.0.0.0/0            0.0.0.0/0           state NEW MARK match !0x14
    
    Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
     pkts bytes target     prot opt in     out     source               destination
        0     0 moblock_fw  all  --  *      *       0.0.0.0/0            0.0.0.0/0           state NEW MARK match !0x14
    
    Chain OUTPUT (policy ACCEPT 789K packets, 813M bytes)
     pkts bytes target     prot opt in     out     source               destination
        2   142 moblock_out  all  --  *      *       0.0.0.0/0            0.0.0.0/0           state NEW MARK match !0x14
    
    Chain moblock_fw (1 references)
     pkts bytes target     prot opt in     out     source               destination
        0     0 DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0           MARK match 0xa
        0     0 RETURN     all  --  *      *       192.168.1.0/24       192.168.1.0/24
        0     0 NFQUEUE    all  --  *      *       0.0.0.0/0            0.0.0.0/0           NFQUEUE num 92
    
    Chain moblock_in (1 references)
     pkts bytes target     prot opt in     out     source               destination
        0     0 DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0           MARK match 0xa
        0     0 RETURN     all  --  *      *       192.168.1.0/24       0.0.0.0/0
        0     0 RETURN     all  --  lo     *       0.0.0.0/0            0.0.0.0/0
        0     0 RETURN     all  --  *      *       192.168.0.0/24       0.0.0.0/0
        0     0 NFQUEUE    all  --  *      *       0.0.0.0/0            0.0.0.0/0           NFQUEUE num 92
    
    Chain moblock_out (1 references)
     pkts bytes target     prot opt in     out     source               destination
        0     0 REJECT     all  --  *      *       0.0.0.0/0            0.0.0.0/0           MARK match 0xa reject-with icmp-port-unreachable
        0     0 RETURN     all  --  *      *       0.0.0.0/0            192.168.1.0/24
        0     0 RETURN     all  --  *      lo      0.0.0.0/0            0.0.0.0/0
        0     0 RETURN     all  --  *      *       0.0.0.0/0            192.168.0.0/24
        0     0 RETURN     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:443
        0     0 RETURN     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:8080
        0     0 RETURN     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:80
        2   142 NFQUEUE    all  --  *      *       0.0.0.0/0            0.0.0.0/0           NFQUEUE num 92
    
    Please check if the above printed iptables rules are correct!
    
     * moblock is not running.
    Also, please note that moblock was running at that time - at least, I had used 'sudo moblock-control start', and it was blocking http quite successfully.

    In /etc/default/moblock, I have, after the autogenerated comments:

    Code:
    WHITE_IP_IN="192.168.0.0/24"
    WHITE_IP_OUT="192.168.0.0/24"
    WHITE_TCP_OUT="80 8080 443"
    Thank you!
    Sevis
    Last edited by typo99; November 21st, 2008 at 10:59 PM.

  7. #137
    Join Date
    Feb 2008
    Location
    The Netherlands
    Beans
    9
    Distro
    Kubuntu 8.10 Intrepid Ibex

    Re: General MoBlock thread

    Hmm, I checked /etc/moblock/blocklists.list but I don't have any of those blocklists. They are custom, as far as I understand? I am using the default blocklists, to be precise:

    Code:
    www.bluetack.co.uk/config/ads-trackers-and-bad-pr0n.gz
    www.bluetack.co.uk/config/bogon.gz
    www.bluetack.co.uk/config/dshield.gz
    #www.bluetack.co.uk/config/edu.gz
    www.bluetack.co.uk/config/fornonlancomputers.gz
    www.bluetack.co.uk/config/hijacked.gz
    www.bluetack.co.uk/config/iana-multicast.gz
    www.bluetack.co.uk/config/iana-private.gz
    www.bluetack.co.uk/config/iana-reserved.gz
    www.bluetack.co.uk/config/level1.gz
    www.bluetack.co.uk/config/level2.gz
    #www.bluetack.co.uk/config/level3.gz
    www.bluetack.co.uk/config/Microsoft.gz
    www.bluetack.co.uk/config/proxy.gz
    #www.bluetack.co.uk/config/rangetest.gz
    #www.bluetack.co.uk/config/spider.gz
    #www.bluetack.co.uk/config/spyware.gz
    www.bluetack.co.uk/config/templist.gz
    
    #locallist /etc/moblock/custom-blocklist.p2p
    On another note, my log file (/var/log/moblock.log) is filled with "Skipping useless range:" and then a name or title. At the end, there are quite a few lines like:

    Code:
    Sat Nov 22 13:17:25| OUT: IANA - Private Use [RFC1918],hits: 1,DST: 10.0.0.2
    Seeing as 10.0.0.2 is my DNS, I suppose that this would be the problem - should I unblock it in my defaults file? I have the feeling this would allow everything, but I am not all too good in the area of firewalls.

    Thank you,
    Sevis

  8. #138
    Join Date
    Mar 2008
    Beans
    9

    Re: General MoBlock thread

    @typo99 The tbg Bogon list also includes the RFC1918 private ranges so you'll probably fine you've been blocking your internal network (the moblock logs should tell you what's being blocked). You also might not necessarily need ever single blocklist loaded, unless your totally paranoid

    @sevis Yours is likely a similar issue, however I'm not sure why your seeing it being dropped OUT, normally that would mean out to the NET where private addresses shouldn't be routed - obviously though it depends on your network setup.
    In your case you probable need to remove the fornonlancomputers from your blocklist file and possibly iana-private and typo99 remove the Bogon list.

    Alternatively you could try to whitelist your lan in the config file, although this didn't work for me (due to the way I'm using nat and forwarding traffic I think). I've use the IP_REMOVE option to remove my lan range, although this removed all of 192.168.x.x/16 from the blocklist, so I've created a custom blocklist covering all of 192.168.x.x except my lan range just so I'm covered

  9. #139
    Join Date
    Aug 2008
    Location
    Brazil
    Beans
    12,497
    Distro
    Ubuntu Studio 12.04 Precise Pangolin

    Re: General MoBlock thread

    Quote Originally Posted by noblem View Post
    @typo99 The tbg Bogon list also includes the RFC1918 private ranges so you'll probably fine you've been blocking your internal network (the moblock logs should tell you what's being blocked). You also might not necessarily need ever single blocklist loaded, unless your totally paranoid

    @sevis Yours is likely a similar issue, however I'm not sure why your seeing it being dropped OUT, normally that would mean out to the NET where private addresses shouldn't be routed - obviously though it depends on your network setup.
    In your case you probable need to remove the fornonlancomputers from your blocklist file and possibly iana-private and typo99 remove the Bogon list.

    Alternatively you could try to whitelist your lan in the config file, although this didn't work for me (due to the way I'm using nat and forwarding traffic I think). I've use the IP_REMOVE option to remove my lan range, although this removed all of 192.168.x.x/16 from the blocklist, so I've created a custom blocklist covering all of 192.168.x.x except my lan range just so I'm covered
    You don't have to create a custom list without your lan ranges or remove fornonlancomputers/iana-private/Bogon lists, this is completely unnecessary. Just add the lan range to /etc/moblock/allow.p2p and you will be fine. The allow list has priority over the blocklist, so any IP included in it would not be blocked.
    Last edited by lovinglinux; November 25th, 2008 at 04:37 PM.

  10. #140
    Join Date
    Mar 2008
    Beans
    9

    Re: General MoBlock thread

    The allow.p2p file may not have the desired effect as it creates iptables rules to allow traffic out to the allowed range, in from the allowed range and forwarded traffic from either a source or destination of the allowed range.

    This is fine if you want to allow an host/range that's external to the local lan (which I'm guessing was the idea). If your trying to use it to allow traffic from your local lan the in and out will be backwards and all forwarded traffic will bypass moblock totally which probably isn't what you want, especially if the moblock host is doing nat for your internal network.

    The WHITE_LOCAL option may work, but forwarding is still going to be a problem so removing the lan range from the blocklist is probably the safest option
    Last edited by noblem; November 25th, 2008 at 09:07 PM.

Page 14 of 65 FirstFirst ... 412131415162464 ... LastLast

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •