Recommended blocklist format for uTorrent

[Calamity]

I know many people here love PG/2, and I've nothing but respect for it.

With that said, I've now--for better or worse--outgrown it. I'm a power-seeder and its engine, at least in its current state, is just too inefficient for me, in terms of throughput overhead. So to keep things as bare and basic as is safely possible, I've decided to fully rely on uTorrent's native support for an ipfilter.dat file. These are my questions:

1) The FAQ states that uTorrent requires an unpadded blocklist format for the ipfilter.dat file, but that it'll accept padded formats as well. So which is it?

2) Perhaps more to the point--as I'll be using BLM to download and merge multi-sourced blocklist data--would I be all right exporting a processed list to the padded eMule format, or can anyone here recommend a better unpadded blocklist format I can export to?

Thanks in advance, guys!

[Switeck]

µTorrent wants this format:

38.118.100.0-38.118.100.255

Padded would look like this:

038.118.100.000-038.118.100.255

[Calamity]

Hi, Switeck, thanks for the quick reply. But sorry, you misunderstood me. I do know what the padded and unpadded formats mean--or look like. The reason why I was asking for clarification (my first question) is because the FAQ (including some earlier posts) states that they BOTH reportedly work in uTorrent.

Why do I ask? Well, because if that is really the case, then that would mean that I can just choose eMule's padded blocklist format from among BLM's various export options, copy the resultant ipfilter.dat file into my %AppData%/uTorrent folder and it would readily work in uT without further modification or conversion, right?

Well if not, is there another uTorrent-compatible unpadded blocklist I can use, with or without BLM's exporter's help? And yes, besides manually typing up a damned filter file myself, of course.

[Switeck]

Padded should work fine, though I've never tested it with more than 1,000 entries padded.

Unpadded, I've used over 100,000 entries.

[Calamity]

Hmm, interesting. So basically, the only difference between the two blocklist padding styles--as far as uTorrent is concerned, of course--is that more blacklisted entries can be accepted and used in one formatting than the other? Since I highly doubt that this limitation is inherent in the padding style itself, can I presume then, that this issue is "unique" to uTorrent's network filtering code? If this is the case, shouldn't this limitation be considered at least a medium-priority bug--or enhancement, if you prefer--that needs to be addressed? After all, this is, arguably, security-related. My argument not withstanding PG/2, Protowall or other network filtering tools, of course. But then again, as you can surmise from my original post, they won't be helping me much either.

Nevertheless, that is beyond the scope of this thread. So again, can anyone here recommend or suggest a good unpadded blocklist format that uTorrent can readily consume? Or am I just gonna have to suck it up and use eMule's padded filters, despite Switeck's warning?

[Switeck]

No, you misunderstood me.

I NEVER TESTED more than 1,000 padded entries in a ipfilter.dat file.

Padded format should work fine, but hey I doubt you're going to try more than 500,000 entries.

My advice is to consider your blocklist carefully. Most of the ranges in the lists I've seen are junk. Bogons often aren't, badguys are often larger than the ranges blocked, spyware source ips are often here today -- gone tomorrow.

[Firon]

I don't believe there's a limit to the number of entries. At least, there isn't an intentional one.

Padded, unpadded, µT doesn't really care. It can even have the extra comma stuff eMule adds (,255,Some comment).

[Calamity]

Hi Switeck, thanks again. Now I'm not being argumentative here, but the fact that you stated that you have never tested the padded formatting with that many entries before, does make it reasonable for me to assume you were implying at least some level of personal "reservation", right? That's why I took it as a hazard warning. Anyway, I'm just being clear, but forget it, no harm done. As for me trying more than 500,000 entries? Well, I AM a thorough person, so I just might. Haha!

Oh Firon, hi, thanks also for the additional revelation, hehe. So I guess this means that I've never had anything to worry about in the first place, huh?

Hey, one last related query guys: I'm not noticing some form of UI feedback regarding the IP filtering underneath. I even checked the logger pane, but nothing (that I saw). What should I be looking for to make sure that the filtering is working as it should?

Again, thanks a lot people!

[Switeck]

On another note, the best blocklist you can have is one you personally researched yourself.

[Calamity]

Yeah, I absolutely agree. But I've been very sick these past few days, and I've neither the time nor the strength to be able to pull off a tedious quest like that without passing out. Hehe.

Hey, can I "borrow" your list? *wink*wink* Hehe!

[Switeck]

I'm not really using much of one at the moment...just blocking the 38.x block and little else.

[Calamity]

Aww, come on, no? Oh, okay.

[khagaroth]

I'm also using BLM and exporting the list as "Generic - IP Range - UnPadded" using the Convert command. I have a filter with over 218 000 lines and uT is working just fine with it.

[Calamity]

Hi, Khagaroth. I was thinking of using that very same generic format too, but I was a bit apprehensive about it. You said it's working fine, but how exactly did you know that? Is there some feedback in the logger pane or somewhere else that I'm not seeing?

[Firon]

When ut loads the ipfilter, it tells you how many entries (lines) were successfully loaded. It should say it in the logger tab.

[Calamity]

Whoa, it does? I thought you were gonna say something to the effect of "it hasn't been fully implemented yet". Hmm, I think it must have scrolled off too quickly for me to have had a chance to notice it.

Anyway, thanks Firon, I'll check it out again right now.

[SplittingDistant]

I've just moved over from Azureus and on a steep learning curve at the moment - in fact it's so steep that I've stalled and my handbrake is about to give out as well! I'm having a bit of trouble with getting 'ipfilter.dat' to be picked up by uTorrent. I've created it using BlockListManager and saved it as a generic unpadded file. I've copied into c:/Program Files/uTorrent but I can't see anything showing that the ipfilter.dat has been loaded and is doing it's stuff, even when logging has 'verbose', 'Log Errors' and 'Log Peer Traffic' ticked.

All help and assistance will be gratefully received!

[DreadWingKnight]

I've copied into c:/Program Files/uTorrent

That's %programfiles%\utorrent and not %appdata%\utorrent (which is where it's supposed to go)

[SplittingDistant]

DreadWingKnight,

What can I say? Perhaps "D'oh" covers it!

Thanks for your response, I should have known.

I shall now slink away in abject shame.

Cheers & Thanks Again,

SplittingDistant.

[Calamity]

@ SplittingDistant:

Shame? Oh, not at all. If anything, I should be the one making apologies here. I promised Firon--well, sort of--that I'd check it out (see my earlier posts) and make a report about it--well not exactly, but it's kinda implied.

But as I said before, I've been sick a lot these past weeks and it totally slipped my mind. Had I done what I should have done, you or DreadWingKnight wouldn't even have needed to post anything at all (you'll soon see why). Again, please refer to previous posts for context:

First off, DreadWingKnight is absolutely correct about the ipfilter.dat file needing to be in the %appdata%\utorrent folder, and even the official FAQ will support him on this fact. However, I've discovered that there is a kink regarding this.

That is, even though uTorrent will, by default, check the %appdata%\utorrent folder for an ipfilter.dat file, it will only do so if your settings file/s is/are located there as well, which would normally be the case with default installer setups. But if, for instance, your settings file/s (along with the uTorrent executable, of course) is/are located in %programfiles%\utorrent, which would be the case with fully-independent, fully-portable manual setups like mine, uTorrent would look for ipfilter.dat at that location only, and then load it if found. But if not found, it wouldn't even bother double-checking the %appdata%\utorrent folder as a back-up or fail-safe procedure, just in case an ipfilter.dat file does exist at that location. So even if there is actually one there, uT will still assume that there isn't.

Now assuming of course that they haven't already fixed this tiny little bug by version 1.7.5 (I haven't checked the latest changelogs), what this basically boils down to is, if you're a purely leave-it-to-the-installer kind of user, you'll have no problem whatsoever. At the other end of it, if you're a custom-setup person like me, you'd still be okay, as long as you're aware of this sneaky part. This is actually why I couldn't see any UI feedback regarding my blocklists loading--or working. At first I thought I just missed it because the log entries, if there were any, had scrolled off the logger tab/pane too quickly. But after some patient testing, I found out that uT simply couldn't see them when under the circumstances that I described above.

Now just by looking at my posts here on this site, you'd see that I'm a strong supporter of uTorrent's portability/mobility "features", so you might wonder why I'm complaining. Well on the contrary, I'm not. If anything, I was actually elated to find this "undocumented" feature. It would have been especially horrendous for a portability advocate like me to have my uT all ready to rock another machine, then only to find out that my blocklist's ability/inability to protect me, depends solely upon the availability (or accessibility) of the destination machine's %appdata%/utorrent folder and the presence of a blocklist in it.