Klaus_1250 Posted June 22, 2006 Report Share Posted June 22, 2006 I was browing some peerlists for different torrents and I noticed the above IP and port was in quite a few of them. The strangest thing, however, was that there were several occasions where the was no non-private IP listed with the same port. I find it quite curious that you can list private IP's on a non-private DHT. It doesn't seem to add any value and I wonder, doesn't it make DHT vulnerable for attack or DoS by listing private IP's with specific ports or lots of private IP's/lots of ports? Link to comment Share on other sites More sharing options...
DreadWingKnight Posted June 22, 2006 Report Share Posted June 22, 2006 DHT was originally written with the intention of being able to serve within an RFC1918 subnet separate from the public internet.That's why there's no filters on the DHT itself.If there were the prospective possibility of an attack, it gets nerfed by mechanisms already in clients, such as automatic peer rotation in case of peer connection errors, and banning on repeated hashfails. Link to comment Share on other sites More sharing options...
schnurlos Posted June 22, 2006 Report Share Posted June 22, 2006 Klaus_1250, add ip 192.168.1.1 to ipfilter.dat and problem goes away. Link to comment Share on other sites More sharing options...
Klaus_1250 Posted June 22, 2006 Author Report Share Posted June 22, 2006 I just removed it recently... The reason being that if I block 192.168.1.1, I also block connections from uTorrent to its own external ip (which get translated to the internal router IP before returning them back to uTorrent) and thus uTorrent cannot determine its own external IP. Torrent-clients apparently use the client/peer id from the handshake to see if they are connecting to themselves. Link to comment Share on other sites More sharing options...
Switeck Posted June 22, 2006 Report Share Posted June 22, 2006 This sounds vaguely like an actual bug, or at least unintentional effect of design.On Gnutella, file sources used to almost always show up with the ips 192.168.x.x -- but that insanity was reduced by various Gnutella programs getting better at determining their real external ip....then alt-locs came along, and the problem grew worse again....then firewalled alt-locs came along, and the problem grew really bad.Except it wasn't 192.168.x.x but instead 0.0.0.0! The way firewalled alt-locs worked with NAT hole-punching, the ip was hidden until tested. Quite clever, except extremely annoying. Link to comment Share on other sites More sharing options...
Klaus_1250 Posted June 22, 2006 Author Report Share Posted June 22, 2006 I think it is both. Peers publishing private IP's to a non-private DHT-network are bugged. As for unintentional effect of design. If DHT was designed for RFC1918 subnets, I don't understand why it got implemented as a global DHT-network without modification.As for Gnutella. Which clients are always generating those pesky 192.168.x.x sources? Searching for anything on G1 always gave me a huge number of 192.168.x.x which were all useless. I never understood why that problem didn't get fixed. Link to comment Share on other sites More sharing options...
Switeck Posted June 23, 2006 Report Share Posted June 23, 2006 DHT should really not be posting 192.168.x.x or 10.x.x.x ips. If a torrent is on a LAN, it DOESN'T need DHT -- it needs Peer Exchange and/or a good tracker.Off-topic:On Gnutella with push routes, if you IMMEDIATELY did a connect attempt the smarter Gnutella clients would replace the LAN ip (192.168.x.x) with the WAN internet ip and work just fine. ...but it did make search results nearly useless. Link to comment Share on other sites More sharing options...
Klaus_1250 Posted June 23, 2006 Author Report Share Posted June 23, 2006 I can imagine why you might want to use DHT on a LAN. Saves you from running a tracker and Peer Exchange only works if everyone can find at least one alternate source. I think Rendezvous or smiliar technologies could be very beneficial for LAN-envirorements.One of the things that have always kept me wondering is why file-sharing apps always work so troublesome in mixed (WAN/LAN) envirorements. Link to comment Share on other sites More sharing options...
Switeck Posted June 24, 2006 Report Share Posted June 24, 2006 Ok, how on a LAN is DHT supposed to work?It has to bootstrap somewhere. And on a LAN, there are likely to be at least 1 static ip you can contact anyway.Either that, or it has to bootstap with an ip outside the LAN which means it then has to find ips INSIDE its LAN from the outside.Peer Exchange can already boostrap just fine in a LAN just like Alt-Locs work on the Gnutella network.I'd be really wary of running lots of trackers inside a college/university LAN-WAN. Link to comment Share on other sites More sharing options...
Klaus_1250 Posted June 24, 2006 Author Report Share Posted June 24, 2006 You could use something like Rendezvous as a Discovery protocol and bootstrap DHT from there. Doesn't PEX only work if you want to download something which the other party is seeding / leeching and you have at least one static ip? Link to comment Share on other sites More sharing options...
DreadWingKnight Posted June 24, 2006 Report Share Posted June 24, 2006 Peer exchange is for when you have already established connections.DHT is for when you have not. Link to comment Share on other sites More sharing options...
DreadWingKnight Posted June 24, 2006 Report Share Posted June 24, 2006 Bootstrapping within a lan is easy when you specify an IP:Port combination in a given torrent. Link to comment Share on other sites More sharing options...
Switeck Posted June 24, 2006 Report Share Posted June 24, 2006 From what I understand, (and this ironically refutes a bit of my earlier points) Peer Exchange serves to find new peers/seeds for a specific torrent. DHT can find new torrents shared.However inside a LAN/WAN, there should be some commonly connected nodes. If you know where all the trackers are at and they're at only 1 or 2 ips, DHT is IMO overkill. Link to comment Share on other sites More sharing options...
Klaus_1250 Posted June 28, 2006 Author Report Share Posted June 28, 2006 Did some more digging, but 192.168.1.1:65535 shows up on several private torrents (no DHT or PEX) too. I wonder if this is a bug anywhere in a client/tracker or that is has some willfull purpose (port 65535 doesn't seem an arbitrary one). Anyone got a clue? Link to comment Share on other sites More sharing options...
atm999 Posted June 28, 2006 Report Share Posted June 28, 2006 one simple way to get arround this is disable DHT, which you should do if you're using private trackers anyway. Link to comment Share on other sites More sharing options...
Klaus_1250 Posted June 28, 2006 Author Report Share Posted June 28, 2006 I see it on Private Torrents (e.g. no DHT or PEX, see previous post) too, so apperently, it does not neccessarily come from DHT. Link to comment Share on other sites More sharing options...
DreadWingKnight Posted June 28, 2006 Report Share Posted June 28, 2006 When it's happening on a private torrent, the issue is caused by the tracker creating a loopback condition by giving your own IP:port combination back to you.That part isn't a client issue. Link to comment Share on other sites More sharing options...
Klaus_1250 Posted June 28, 2006 Author Report Share Posted June 28, 2006 Added my own external IP to ipfilter.dat Not a clean sollution, but it did the trick. Thanx for the help Link to comment Share on other sites More sharing options...
Firon Posted June 28, 2006 Report Share Posted June 28, 2006 :65535 shows up when it has no port for the IP. Link to comment Share on other sites More sharing options...
Klaus_1250 Posted June 28, 2006 Author Report Share Posted June 28, 2006 Thanx Firon, now it is all clear :-) I've been wondering where that number came from. Link to comment Share on other sites More sharing options...
Recommended Posts
Archived
This topic is now archived and is closed to further replies.