more IPFilter info please

[drizzle]

I oftimes see block messages in the uT log. But it is frustrating how little info is provided.

Request:

Rather than simply blocking the incoming connect, it would be much more useful to the user for uT to accept the connection, go through the handshake, THEN LIE by returning a 'No such torrent' status to the blocked IP/peer.

There would be two benefits to this. (1) the logging could include the hash of the requested torrent (ie - not only would you know what IP was connecting, but which torrent they were interested in). And (2) by returning this status, they would (hopefully) purge your IP:port from their peer cache.

I really want to know which torrents the blocked IPs are interested in!

[jewelisheaven]

No.

No.

Multiple requests per thread are not permitted.

[Firon]

We're not gonna change the ipfilter to behave like that. The point of the ipfilter is to not connect at all.

[drizzle]

Multiple requests?

I made one request, showed how it might be implimented, and the benefits.

Is your "No. No." because of some fundamental design philosophy?

The connecting client already has "my" IP:port, it is not like refusing the connect hides this info.

Thanks for the quick responses!

edit:

In the meantime, I came up with a somewhat cumbersome approach that lets me determine what torrent the blocked IP is trying to access.

When I see a blocked IP of interest (like the two that have been trying to connect to me for over a week that prompted this request) I start up another copy of uT (diff port and/or diff PC) with full logging on, no torrents loaded, no ipfilter.dat. I then add an iptables rule to my (linux based) router that directs incoming connects from that IP to the second copy of uT.

Now when they attempt to connect, that copy is passed the connection and uT logs the torrent hash they requested in the disconnect log message. I then check this hash against the list of torrents in the "real" uT to determine which one they wanted...

I now know that the repeated connect attempts from the HBO IP was for 'Space:1999" and the one from a Macromedia IP was for 'Jeramiah'.

And what have *they* learned? Well, they already had my IP:Port and the torrent hash or they wouldn't be trying to connect, so nothing new was revealed. But now it appears to them that, yes he's running uT but No he's not ul/dl'ing the torrent...

*I* now _know_ what *they* are doing and *they* have been _misled_ about what *I* am doing. Perhaps some disagree, but I find this a HIGHLY desirable state of affairs.

The only problem is how cumbersome my workaround is. It would be much simpler if uT had an ipfilter option that allowed the incoming connect from a blocked IP to proceed to the point where they revealed the hash and THEN disconnect (with 'no such torrent' status) & log it, rather than simply refusing the connect and logging just the IP.

[qazwiz]

drizzle, you would more likely get what you want from an open source client. they are more likely to have someone able to split from the main client if they have the same absolute reaction as you got here

but not Azureus, their 3.1 update now requires registering for many of the new features (and are they still open source? no matter)