WebUI and ipfilter.dat - curious behaviour

[e.emizerp]

Hello everyone

I'm compiling my own ipfilter.dat using TinyBLM (ver 2.0.7.8) via script so the whole process is automatic. All BISS sources are on EXCEPT LAN Ranges (0.*, 10.* and 192.*) with few of my own additions/exclusions. Yes, I know using ipfilter.dat is not by any mean bulletproof or even significant improvement, but it cannot hurt, so I've been using it this way for a while now (few years).

Funny thing started happening about a week ago. Suddenly I was unable to access uTorrent (ver 2.0 build 18488) using WebUI (ver 0.370, webui.2010020718333315.zip). As I first noticed this approximately when uTorrent build 18488 became available, first thought was new build was the culprit. To shorten the story, I went back couple of uTorrent versions, tried different uTorrent/WebUI variations when, by pure coincidence, noticed that WebUI was accessible when ipfilter.enable was set to False.

Now this is where the things start to get weird. I'm accessing WebUI from LAN (192.168.*) and when I check ipfilter.dat these addresses are not blocked. What's more, when I set ipfilter.enable to True I'm not cut-off immediately, WebUI continues working some 10-15 minutes more!

When I compile ipfilter.dat with Blocklist Manager (ver 2.7.7) with the exactly the same settings (the same sources/inclusions/exclusions) everything works OK (resulting files are not, of course, exactly the same, so I cannot do binary comparison, but both ipfilter.dat files are functionally the same). Also, problem ipfilter.dat works just fine with emule p2p clients (WebInterface).

If needed, I could post problem ipfilter.dat somewhere (it's 18+ Megs).

Anyone ran into something similar or has any ideas where I should look?

Cheers

Emi

[DreadWingKnight]

but it cannot hurt

Except that it can. Not only are you blocking large portions of legitimate peers haphazardly, you are also potentially funneling yourself into IP ranges controlled by the anti-p2p groups.