Debug, IP Filter blocked <ipaddr>, <torrentname>: blocked peer: <ipaddr> [privileged_ports].

[kilves76]

It is really not nice to be doing this when the user has not requested to do this, especially when ip filter is even set to inactive. Happens with both ipv4 and ipv6 connections.

Many people run torrents on privileged ports to escape ISP traffic throttling, or vanity, or whatever reason - nevertheless i don't think anyone wants a single seed or peer to be dropped off because of their port number. Never encountered this kind of port [wording edited Eoin] before, it's an interesting thing to implement on a protocol which tries to maximize connectivity.

This is a brand new install (never tried Halite before) on Win7-64, running on a privileged port itself (making it sure not a single Halite client is going to connect to it...).

Another issue, on this magnet uri magnet:?xt=urn:btih:546cf15f724d19c4319cc17b179d7e035f89c1f4&dn=Ubuntu+Desktop+GNU%2FLinux+14.04.2+Trusty+Tahr+LTS+x64+64bit+amd64&tr=udp%3A%2F%2Fopen.demonii.com%3A1337&tr=udp%3A%2F%2Ftracker.coppersurfer.tk%3A6969&tr=udp%3A%2F%2Ftracker.leechers-paradise.org%3A6969&tr=udp%3A%2F%2Fexodus.desync.com%3A6969 leechers-paradise.org:6969 gets truncated into leechers-paradise.or, log entry:

None, Alert Ubuntu Desktop GNU/Linux 14.04.2 Trusty Tahr LTS x64 64bit amd64 (udp://tracker.leechers-paradise.or) (-1) No such host is known (1), Status code: -1, Times 1. ()

Another issue, UI has phantom message "Port nnnnn open" in lower left corner which is not seemingly related to anything, since Halite has been bound to a single port in options (not this one). Checking with netstat, this port is not listening or in use either.

Also wondering how many issues did go unreported because seemingly the only way to do it is to register an account with Github, i'd say 99,99% of people will just quietly drop it instead (i just happened to have way too much time atm). An email account like [email protected] could be rather welcome.

[kilves76]

Truncated magnet seems to be too short buffer issue since exodus.desync.com is not on list of trackers at all.

[Eoinocal]

Hi, Kilves, thanks for the feedback, I really appreciate it.

It is really not nice to be doing this when the user has not requested to do this, especially when ip filter is even set to inactive. Happens with both ipv4 and ipv6 connections. ​> ​Many people run torrents on ​​privileged ports to escape ISP traffic throttling, or vanity, or whatever reason - nevertheless i don't think anyone wants a single seed or peer to be dropped off because of their port number. Never encountered this kind of port [wording edited Eoin] before, it's an interesting thing to implement on a protocol which tries to maximize connectivity.​ ​> is a brand new install (never tried Halite before) on Win7-64, running on a privileged port itself (making it sure not a single Halite client is going to connect to it...). ​ [wording edited Eoin] is a very strong word to use in this context. That aside can you be more specific, as far as I know libtorrent, the underlying library, makes no such restrictions, and I didn't add any on top of that. Are you specifically talking port numbers below 1024? ​​ I just tried setting halite to listen on port 128 there. Both netstat say the port is open and trying to connect from www.​​canyouseeme.org verifies that UPnP has properly setup the NAT routing so the port open to the rest of the internet.. ​ ​ "Port nnnnn open" in lower left corner which is not seemingly related to anything,​​ ​ That reports the open port for me, again verified by netstat and ​​ canyouseeme.org

​> Another issue, on this magnet uri​ [...] gets truncated into leechers-paradise.or

​​That was a weird one, you are absolutely correct, I've fixed it now and will release an update ASAP.​

As for the bug reporting, I'll have to give that more thought.

Thanks again for the reports, if you can clarify the port problem you're having it'd bea great help.

Eoin

On Tue, May 26, 2015 at 6:55 PM, kilves76 [email protected] wrote:

Truncated magnet seems to be too short buffer issue since exodus.desync.com is not on list of trackers at all.

— Reply to this email directly or view it on GitHub https://github.com/Eoinocal/Halite/issues/5#issuecomment-105618106.

[kilves76]

On Wed, 27 May 2015 06:34:16 +0700, Eoinocal [email protected]
wrote:

Hi, Kilves, thanks for the feedback, I really appreciate it.

[wording edited Eoin] is a very strong word to use in this context. That aside can you
be more specific, as far as I know libtorrent, the underlying library, makes no such restrictions, and I didn't add any on top of that. Are you specifically talking port numbers below 1024?

Yes, i set it to 444 for testing.

I just tried setting halite to listen on port 128 there. Both netstat say the port is open and trying to connect from www.​​canyouseeme.org
verifies that UPnP has properly setup the NAT routing so the port open to the rest of the internet..

I can't verify this or that, i can see it's listening on 444 BUT there is
not a single established connection to/from that port. Just reporting what
Halite's log said. I can't reproduce the error today from the same
torrent, and Halite doesn't tell the peer's remote port (would be nice if
it did, as other torrent clients do show this).

Edit: after a few moments the error is there again, when Halite finally
encountered a peer at a low port.

I started the torrent in uTorrent and manually added peer 127.0.0.1:444
and it does connect and download to this direction.

But the error was about the port number in the peer end, as far as i
understood it correctly. I'm sorry but currently i don't have the
opportunity to change any available torrent client to a low port at
localhost to test this.

And a third final test, with halite:lowport other:lowport.

​> Another issue, on this magnet uri​ [...] gets truncated into leechers-paradise.or

​​>That was a weird one, you are absolutely correct, I've fixed it now and will release an update ASAP.​

Great! I took the time to report the errors because I liked what i see in
Halite, compared to the bloat (and bitcoin miners...) in some other
clients.

In addition to displaying the peer's port, it would be nice to show the
total amount up/downloaded to/from a peer, as the download speed per
second doesn't really give any long term implication. It's just nice to
see who is a genuinely good peer and seeds a lot, or who is a good peer
and trades with you a lot, and who is but a leech. And an average speed,
calculated for the past user_defined_seconds. And with the average values,
it'd then be easy to realize an ETA display, which really is kinda useful.

[d-random-contributor]

As I know, port [wording edited Eoin] is a libtorrent feature: hypothetically you can choose a server ip+port and send them to multiple peers over DHT, which will be effectively a ddos attack on that server. Also libtorrent has a heuristic ban algorithm, which works when ip filter is turned off too.