Peer Port Number is not the Peer's Port Number.

[a-raccoon]

Please complete the following tasks.

• [x] Web browser cache cleared
• [X] Link provided to install script if applicable
• [X] Web browser, ruTorrent, PHP and OS version provided

Tell us about your environment

Very old very persistent bug I have neglected to report.

Web Browser: Google Chrome (all versions) ruTorrent: v3.10 PHP: unknown OS: unknown

Tell us how you installed ruTorrent

I'm just a user.

Describe the bug

Under the Peers tab, for any Address of any peer, the port number displayed is NOT the remote listening port of that peer, but instead, is the local session port of the current connection to that peer. The src port.

Steps to reproduce

1. Select an active torrent of a known peer.
2. Go to the Peers tab.
3. Observe their port number.
4. Ask them in person if that is indeed their port number. or 4a. Observe that same peer in any other torrent client.
5. They'll tell you no it is not their port.

Expected behavior

It should be the listening port of that peer. The port that peer entered into their client. It should not be the ever changing src port of the established connection.

Additional context

Sorry I have waited so long to report this.

[Novik]

As I may see, this is not true. Please, illustrate your ticket with a two screenshots: 1) Peers tab, where we may see concrete peer with IP:PORT 2) Result of command netstat -t | grep PORT

[yandrey0]

Правда, "p.port" - локальный порт к которому подключился пир (практически бесполезная информация), это хорошо видно когда один и тот же пир качает разные торренты, порты разные или если его отсоединить, то он вновь подключается уже с другим портом. В rutorrent не исправить, в rtorrent командах по пирам других портов нет.

[a-raccoon]

As I may see, this is not true. Please, illustrate your ticket with a two screenshots:

1. Peers tab, where we may see concrete peer with IP:PORT
2. Result of command netstat -t | grep PORT

As I stated, I'm only a user of the web client ruTorrent. I do not install them. However, everyone I've spoken to on IRC agrees that ruTorrent has always behaved in this way. I have personally witnessed this behavior for an excess of 5 years, on a dozen people's hosted machines, and without deviation. It always displays the incorrect (local) port of all connected peers.

Step 1: Open up your favorite desktop torrent client, ie, uTorrent or qBittorrent. Step 2: Add 5 torrents that only have 5 seeders. Step 3: Observe the IPs and Ports of those 5 seeders. Write them down. Step 4: Repeat steps 1..3 in ruTorrent.

[lps-rocks]

This is normal behavior and has nothing to do with ruTorrent or rTorrent. This is the typical behavior of most TCP/IP stacks and BTclients.

Torrent clients do not necessarily originate outbound connections from the same port number they listen on. This can be due to NAT or due to design of the BT client. If the connection is incoming, the source port will be different from the listening port of the remote peer.

[a-raccoon]

I think you still might be misunderstanding. It is not important which direction two clients connect. The only port number that should appear in the Peers section is the LISTENING PORT number that the user specified in their bittorrent client. r[u]Torrent is the only client that is misbehaving in this regard.

We do not care who connected to whom. We demand that the correct Listening Port is displayed next to the client's IP address. This is the same port number that is given to trackers. That is the correct port to put on display and none other shall occupy that space.

When a user wants to ADD PEER, it is this and only this IP:PORT that can ever be used. The current IP:PORTs on display cannot be used and serve no practical purpose.

[lps-rocks]

I think you still might be misunderstanding. It is not important which direction two clients connect. The only port number that should appear in the Peers section is the LISTENING PORT number that the user specified in their bittorrent client.

I'm not misunderstanding anything. Direction of connection is important. That's why rTorrent has a field that indicates if it's inbound or outbound. That's also not how the peer display works. It is not a list of peers provided by the tracker. It is a list of active connections.

r[u]Torrent is the only client that is misbehaving in this regard.

No, it's not. Find me a client that displays only peers and their listen port, not the connection port on the peers list. What should a client do when a peer is connecting that isn't provided by the tracker? How would it display that if it worked in the manner you're describing?

Futhermore all ruTorrent does is grab the data from rTorrent. So if the data is wrong, you should file an issue on the rTorrent repository - https://github.com/rakshasa/rtorrent/

We do not care who connected to whom. We demand that the correct Listening Port is displayed next to the client's IP address. This is the same port number that is given to trackers. That is the correct port to put on display and none other shall occupy that space.

See above as to directionality. You're demanding something based on an ill-conceived notion that the peer list in a BT client is a list of peers provided by the tracker. It's not. It's actually just a list of active connections. The appropriate things to do in that list is to display the correct IP/Ports that are being used by the TCP connection.

When a user wants to ADD PEER, it is this and only this IP:PORT that can ever be used. The current IP:PORTs on display cannot be used and serve no practical purpose.

This makes no sense.

[a-raccoon]

You made up this notion that I stated the peer list are those provided by the trackers. I am not. I am stating that the port number that must appear next to the peer IP is the port that the peer instructs you to display. It's in the same data packet as the peer's client version string. It is that peer's identity. Its phone number. Its soul. It is the copy/paste you use to add him as a peer to other torrents, for example, using the ADD PEER functionality.

I will not provide examples of other clients that behave this way, except that ALL OTHER clients behave this way. I have tested with qbittorrent, utorrent and azureus vuze. I am told that transmission also behaves correctly in this fashion. Just go look.

YOU show ME one other client that displays the dummy session port, and not the telephone home port of client peers. You can't and won't.

[lps-rocks]

No matter what you say, you're barking up the wrong tree. You need to open an issue in https://github.com/rakshasa/rtorrent/

This has nothing to do with ruTorrent. Thanks!

[stickz]

Futhermore all ruTorrent does is grab the data from rTorrent. So if the data is wrong, you should file an issue on the rTorrent repository - https://github.com/rakshasa/rtorrent/

Well said. I'm going to close this because it's not an issue with ruTorrent.

[a-raccoon]

Futhermore all ruTorrent does is grab the data from rTorrent. So if the data is wrong, you should file an issue on the rTorrent repository - https://github.com/rakshasa/rtorrent/

Well said. I'm going to close this because it's not an issue with ruTorrent.

Does rTorrent provide (expose) both port variables, but ruTorrent is using the wrong one? I have not installed rTorrent to look at its own GUI. It is not taken for granted that ruTorrent mimics rTorrent's GUI faithfully and accurately. Tries to but fails.

[lps-rocks]

I have not installed rTorrent to look at its own GUI. It is not taken for granted that ruTorrent mimics rTorrent's GUI faithfully and accurately. Tries to but fails.

Wait, you haven't even validated any of your claims!? Please don't open issues without some sort of validation and please provide validation when it's asked for (you've been asked twice and refused twice). The open source community volunteers our time to maintain these projects. Wasting volunteer's time with unsubstantiated claims is absurdly rude. If this was my repository, I'd ban you from opening issues after how uncooperative and rude you've been.