BiglyBT happily tries to communicate with itself as a peer & accepting peers in private IP range about biglybt HOT 9 CLOSED

In the scheme of things I don't consider connections to "self" as being a particular issue which is why I've never bothered looking into whether or not such connection attempts can be avoided.

Likewise the "encrypted transport" stuff - as you probably know it is only a level of obfuscation, not actually encryption, and while many years ago people obsessed over it, I don't believe it is of particular use these days. BiglyBT doesn't have access to low-level details of network connections so being able to differentiate between a failed successful connection and a failed failed connection is probably not possible. Also that second option is kind of silly to enable to be honest...

from biglybt.

In the scheme of things I don't consider connections to "self" as being a particular issue which is why I've never bothered looking into whether or not such connection attempts can be avoided.

They are probably not until they make up a majority of traffic (busy NO-OP loop) or start looking like something unsavory is happening in your network (my case).

Likewise the "encrypted transport" stuff - as you probably know it is only a level of obfuscation, not actually encryption, and while many years ago people obsessed over it, I don't believe it is of particular use these days.

Not that familiar with the mechanism (key exchange etc.), but from the wikipedia article it looks like that while it's not much help in preventing protocol identification, it could at least prevent a passive listener from cheaply logging the passing infohash etc. . Could you point me to a more detailed article regarding the matter (assuming you think that even that might not be true)?

BiglyBT doesn't have access to low-level details of network connections so being able to differentiate between a failed successful connection and a failed failed connection is probably not possible. Also that second option is kind of silly to enable to be honest...

Access to such info is probably platform specific and not that easy to do in a Java app. Regarding the second option, I know it's a compromise, but if the peer doesn't support encryption and there are no more peers to pick from, what can you do... It would probably make sense to be able to enable it on a per-torrent basis (a feature suggestion).

Any opinion on the possible general private / non-typical IP-range filtering options?
Should we just adjust the wiki so most people put the private IP ranges into their blocklist?
Could putting my own IP in there create any issues for other BiglyBT functions, or is the blocklist used strictly just for peer connections?

I know this is not a bug per se, but I though it interesting enough to post it. The finer details might even have some security implications (like becoming part of a DDOS, reflection / amplification attacks etc.)

from biglybt.

Ok. Made an experiment and added my public IP + private IP ranges to the IP filters list, but it doesn't seem to work. Not only were they not removed from the All Peers list but I still see new outgoing connection attempts from BiglyBT to my public IP. When does the IP blocking come into effect? Is it only when new peers are being added? And does it even block outgoing connection or just incoming?

I also noticed that if the "Options->IP Filters [Auto Loading]: Clear filters when reloading" is unchecked the entries get duplicated on (manual) reload. I would expect the update to be slower but the duplicates being removed. Also: Is it really that hard to swap the block list atomically in place (at the expense of temporarily increased memory requirements during reload)? Didn't look at the code (maybe the data structures were badly designed for this in Azureus/Vuze), but it seems quite possible to me.

from biglybt.

Ah, here we go, the expert coder. Submit a pull request.

from biglybt.

Ah, here we go, the expert coder. Submit a pull request.

I would suspect you don't want to see that. Didn't touch Java for almost 20 years.

from biglybt.

Update:
After BiglyBT restart all the blocked IPs no longer seem to appear in the All Peers list. Blocking seem to be working so far without disrupting any functionality.

IPv4 blocklist snippet for anyone interested (.p2p format , replace <INSERT_YOUR_OWN> in the first line with your own public IP):

MY OWN PUBLIC IP:<INSERT_YOUR_OWN>-<INSERT_YOUR_OWN>
Class A PRIVATE IP:10.0.0.0-10.255.255.255
Class B PRIVATE IP:172.16.0.0-172.31.255.255
Class C PRIVATE IP:192.168.0.0-192.168.255.255
Reserved - Current network:0.0.0.0-0.255.255.255
Reserved - CG NAT:10.64.0.0-10.127.255.255
Reserved - LoopBack:127.0.0.1-127.255.255.255
Reserved - Local-Link Addr:169.254.0.0-169.254.255.255
Reserved - IETF Protocol Assignments:192.0.0.0-192.0.0.255
Reserved - TEST-NET-1:192.0.2.0-192.0.2.255
Reserved - IPv6 to IPv4:192.88.99.0-192.88.99.255
Reserved - benchmarking:198.18.0.0-198.19.255.255
Reserved - TEST-NET-2:198.51.100.0-198.51.100.255
Reserved - TEST-NET-3:203.0.113.0-203.0.113.255
Reserved - Multicast:224.0.0.0-239.255.255.255
Reserved - MCAST-TEST-NET:233.252.0.0-233.252.0.255
Reserved - Future use:240.0.0.0-255.255.255.254
Reserved - LIMITED BROADCAST:255.255.255.255-255.255.255.255

If you are using IPv6, you should probably do the same in there as well (see https://en.wikipedia.org/wiki/Reserved_IP_addresses)

from biglybt.

Glad it works for you.

BiglyBT does all sorts of twatting around with fake addresses and internal connections (that maybe class C if bound to such an address). I don't know if they are checked against blocked ranges, perhaps not, but if anything seems to be broken that might be the cause.

from biglybt.

BiglyBT does all sorts of twatting around with fake addresses and internal connections (that maybe class C if bound to such an address). I don't know if they are checked against blocked ranges, perhaps not, but if anything seems to be broken that might be the cause.

Yeah, I wondered about that, especially when adding the loopback interface. Not much to be gained from that one other than potentially preventing communication with other local processes. But if you are concerned about that, you should probably run BiglyBT in some sort of sandbox anyway. I will leave it on for a few days just to see what happens, but for anyone attempting to use the above snippet, it might be a good idea (more future proof) to delete the following line:

Reserved - LoopBack:127.0.0.1-127.255.255.255

from biglybt.

uTorrent has similar problems with self-connection attempts.
I found it quit doing that once I blocked its LAN ips and its IPv4 internet ip address using its ipfilter.dat file.
The inclusion of my internet ip address in the ipfilter.dat means this workaround isn't portable to others.

IPv6 is unsupported by my ISP, but it still causes uTorrent problems with BiglyBT trying to uTP NAT hole-punch from a IPv6 address to a IPv4 address.

from biglybt.