No incoming connections through VPN

[asd178]

I installed thin client (thanks again), ltConfig plugin, too. Version of libtorrent is 1.1.5.0.
By the way, do you know if such a thing as LabelPlus plugin for Deluge 2.0.3 exists?

it also worked in deluge 1.3.15, the test-button in preference-menu, I mean.

That one worked for me in 1.3.15, too.

but when going into preferences and pressing the checking button under network tab, then it works and the message in lower corner goes away

This is still not happening for me. The message in lower corner does not go away, ever. Neither when I press that button, nor when I see clearly as another client is uploading through forwarded port. Could be libtorrent 1.1.5 vs 1.2.3.

[mhertz]

Yeah probably libtorrent related, I tested 1.2.3 and 1.1.13, but never 1.1.5.

Ltconfig is available for deluge2, but there's an issue with configuring enabled/disabled(boolean) options from GTKUI, only settings without yes/no checkboxes can be changed. However, you can change them in ltconfig.conf in deluge profile dir or using webui. All settings are read and used from the conf and I'm here just talking about changing options.

https://github.com/ratanakvlun/deluge-ltconfig/releases

[mhertz]

Note, just found that the check-button in deluge is deluge's own python code, whereas the message down in statusbar is coming from libtorrent itself and deluge monitors libtorrent's 'has_incoming_connections' function, which shows true when receiving any connections on listening socket.

Libtorrent API Documentation:

has_incoming_connections is false as long as no incoming connections have been established on the listening socket. Every time you change the listen port, this will be reset to false

Some reported the test-button working but still the no incoming connection message in statusbar down right. Cas stated sometimes when restarting deluge then rebinding same port could be problematic as takes some time for OS to free a used port, but this should be fixed in later deluge and libtorrent version(0.16+). If the deluge fix not applied yet, then you could see it in preferences where the check-button is, that the port has changed away from the one you thought.
You probably don't have this issue, but just for full completeness about above mentions:
https://dev.deluge-torrent.org/changeset/5978b433d3ab68
https://dev.deluge-torrent.org/ticket/2122

[asd178]

For the sake of clarity: in this thread I was talking about exclusively a setup where the incoming port was forwarded through VPN.

I checked the behavior of my another client (1.3.15/1.0.9), which is connected to Internet directly, and it does exactly what you are saying: after pressing the "check button" the message goes away. More then that: if there are torrents in "seeded" state, after I restart Deluge and connect to it, I don't see the message at all. Apparently, the message clears out by "natural" incoming connections in those seconds it takes me to connect to Deluge.

[mhertz]

I was just little "worried" that you actually didn't have incoming connections anyways, as deluge just test for open port(I think), but the message down there in statusbar is an actual message from libtorrent about if it's "working"(incoming connections, that is).

I read a post where Cas stated that it should "turn"(the message) if working properly, unless there's a bug but unlikely, he said.

It must be a liborrent/deluge issue then, as you said, if working still.

[asd178]

I was just little "worried" that you actually didn't have incoming connections

OK, let us see in detail why I decided that I actually have incoming connections.

I have "client1", which is Deluge 2.0.3, that have incoming port 50000, which is forwarded from a VPN server with external (Internet) address, say, 1.2.3.4 and internal (VPN) address 10.0.0.1.
I have "client2", which is behind NAT and doesn't have incoming port forwarded.

On client1 I download a torrent with a very small number of seeders. After it's complete, I begin downloading the same torrent by client2. What happens next:

1) Client2 begins downloading from client1 (and possibly from some others, but that's irrelevant).
As far as I know, two torrent clients cannot connect if both have inaccessible incoming ports.

2) Client2 shows the address of client1 as 1.2.3.4:50000.
It cannot be anything else except the forwarded port of client1.

3) Client1 shows the address of client2 as 10.0.0.1:xxxxx (xxxxx - random port number).
It cannot be anything else except a connection established through VPN.


Any flaws in my reasoning?

[mhertz]

Yes, it sounds very much like you're having incoming connections agreed. I believe you're good

As far as I know, two torrent clients cannot connect if both have inaccessible incoming ports.

Just for full reference, with uTP, there's a holepunching extension or feature added, which can sometimes make firewalled peers connectable, though needs others to act as relay between the two that's connecting, and I believe it doesn't happen very often/good, I believe I read once.