Transmission Peer Listening Port is closed
Clickbaitcake opened this issue · comments
I am having trouble attracting seeders on Transmission because the Transmission Peer Listening Port says its closed.
The default port 51413 is open on my firewall and the server is in a data centre with direct access to the internet.
If I run sudo netstat -tulpn | grep 51413 I do not see Docker binding/listening on the port, so I think Docker isn't binding correctly.
Is anyone else peer listing port stuck in the closed state? Am I doing something wrong?
Yeah, you're right. By default, the configuration isn't set to forward connections to Transmission on 51413 but it's simple enough to fix.
Add a line under the ports section in the transmission block:
https://github.com/lardbit/nefarious/blob/master/docker-compose.base.yml#L75-L86
Something like
ports:
- "9091:9091"
- "51413:51413"
You're the first one to point this out. I think most people are just leeches and don't worry/think about seeding. Maybe I should consider adding this to the default configuration?
Thanks @lardbit for the quick response. I made the change as you suggested and now the machine is listening on port 51413. Confirmed by using this command: sudo netstat -tunlp | grep 51413 Transmission GUI still says the port is closed but I don't think it is. I have opened on the firewall and there is no router or nat in the way as I am using a cloud based VPS.
I think it should be added to the default config because it will help Nefarious users attract more seeders and also help the torrenting community by seeding back more. With that said, there is still more time needed for testing because as mentioned Transmission does not think the port is open at the moment.
Just scanned my server from another machine which shows port 51413 open inbound. Transmission must be wrongly reporting the peer listening port as closed?
That's a good question. I know transmission's default peer-port is 51413 so I'm not sure why the GUI would report it closed for you.
Interestingly enough, I didn't forward any extra ports to transmission and my GUI says that it's peer port of 24528 (random I guess) is open. I cannot explain that. I am using the vpn version (in nefarious) which uses https://github.com/haugene/docker-transmission-openvpn as the transmission container image so it may be doing some things under the hood.
That's a good question. I know transmission's default
peer-portis51413so I'm not sure why the GUI would report it closed for you.Interestingly enough, I didn't forward any extra ports to transmission and my GUI says that it's peer port of 24528 (random I guess) is open. I cannot explain that. I am using the vpn version (in nefarious) which uses https://github.com/haugene/docker-transmission-openvpn as the transmission container image so it may be doing some things under the hood.
Was this marked as open even without having to modify the docker.yml as earlier discussed?
yeah, that was the weird part. And I definitely never specified 24528 anywhere. I'm wondering if that's part of Transmission's "random peer port" functionality (even though it appears unchecked).
I will test out the VPN version and report back my findings. Would you be willing to try the non VPN version on your network to see if the default port is open for you? That way I can rule my network being the issue.
Also, not to forget once we figure this out the default port forward config might need to be changed
Just to chime in here: I'm also using the VPN version and my transmission GUI reports 51413 is closed. Which is correct as it is closed.
Frankly I don't understand that much about this but download & seeding still seems to work fine telling from the ratios:
From what I have found online its still possible to seed when the port is closed (known as passive mode) however when downloading in passive mode will find less peers so may experience a slower than possible speed, I think this is what's happening to me.
This answer on AskUbuntu sums it up nicely:
The short answer to the question: YES, you can seed with closed port too.
If the port is closed that only means you can't accept incoming connections, but you can still connect to peers who accept connections. In torrent terminology they say that you are in passive mode.
If your port would be open then you would be able to accept connections too. In torrent terminology this is called active mode.
So it works like this: A client in passive mode can connect to a client which is in active mode, but not to a client which is in passive mode. A client in active mode can connect to both active and passive clients.So if your port is closed that only means you can't connect to other peers with closed ports. That means that you may get less peers and because of that worse speed. But if the torrent is frequent and there are lot of peers your client will likely be able to find enough active peers to max out your connection. If the torrent has few peers then it is likely that with active mode you would get much better speed. (If that rare case happens that all the peers are in passive mode, then you won't be able to download/upload anything. Actually non of the peers would be able to do anything as everyone is passive, you will have to wait until an active peer comes in.)
To open that port: First find out the number of the port in Transmission under Edit->Preferences->Network->Port used for incoming connections. That port can be blocked either by your router or by your firewall.
If you use Ubuntu with the default settings and didn't activate a firewall then the linux firewall won't block any port. If you activated some kind of firewall then you have to change those settings to allow incoming connections on that port. If you use a firewall but you don't know how to allow that port, use the following command where PORT_NUMBER is the port used for incoming connections in Transmission:
sudo iptables -I INPUT -p tcp --dport PORT_NUMBER -j ACCEPT
this is only a temporary solution, after reboot this firewall setting is lost. If you want to make it permanent you can put this command in a startup script. (But it is better if you allow the port in your firewall frontend (ufw, gufw, firestarter, e.g.) for permanent solution.)
So the much more likely case is that your router is "blocking" that port:The easier way to solve this is to just enable UPnP in the router's settings and also in Transmission under Edit->Preferences->Network tab-> and check in Use UPNP or NAT-PMP port-forwarding from my router.
If that doesn't solve it then you will have to forward that port in the router's settings. Here is a great site showing you how to do that for almost all types of router. Just select your router type there and follow the instructions. (On that site you will also have to select a program for which you want to forward, but it is unimportant which one you choose, because the solution will only differ in the port number, but you already know from transmission the port number which you want to forward.)
Note: You should only check Pick a random port every time Transmission is started in Transmission if you use UPNP, or the port number will always change and the firewall/forwarding have to be set up after every start of transmission. (UPNP can deal with changing port numbers.)`
So far we have some inconsistencies in each of our deployments. I wonder what's going on. I need to go and test the VPN Docker.
Scratch that. My docker containers didn't have internet access because of the issue I am exploring in #159. Restoring internet access and restarting docker now gives me open peer port so the earlier fix of adding "51413:51413" to the config worked. I think we should change the default config to tie this port in so Nefarious users can contribute to torrent swarms properly!
Great - glad opening the peer port was sufficient. I'll gladly merge in those changes. Thanks.
@lardbit I wanted to try out whether I can get it working now, debugged quite a bit but am now not sure anymore what to try next.
Was there anything else you needed to do to get this working with the VPN version? Does the VPN need to support Port Forwarding / Does yours?
Anything we maybe need to configure from this list or maybe we don't have these fixes yet? (grasping at straws here)
Some info from my debugging:
The output of sudo netstat -tulpn | grep 51413 now seems correct:
tcp 0 0 0.0.0.0:51413 0.0.0.0:* LISTEN 36575/docker-proxy
tcp6 0 0 :::51413 :::* LISTEN 36583/docker-proxy
I set up port forwarding on my router and allowed the port in the ipv6 firewall on the router. On my local PC I added the port to my ufw allow list. The port still showed as closed.
I then debugged with tcpdump on the router and canyouseeme.org whether the traffic comes through (suspected that maybe my modem is doing stuff?): It does come through and then tries to reach my PC but there it seems to get blocked. My firewall config seems fine though (verified with nc -l 51413 and nc -v -z {ip} 51413 from a different computer on the local network).
When I use the non VPN version it seems to work with the open port, telling from the docker log of Transmission: Port Forwarding State changed from "Not forwarded" to "Starting".
Hey @panmau,
I don't think the torrent server needs a peer port enabled since this scenario is documented as "passive" and should still work. However, I never opened up the peer port (in my docker compose) but my Transmission (via vpn image) reported the port was open, so I can't explain that. Are your torrents not working or are you just trying to make sure everything is optimal as it can be?
I guess I'm perplexed about your peer port too since you proved the connection seems open externally (via router) and internally (via lan). To me it sounds like it's working other than Transmission reporting otherwise. I can only assume the VPN docker image (haugene) is doing something more complicated or is a false negative.
@lardbit Yes, my torrents are working for the most part. I noticed though that for some of them I get way less or even 0 peers in comparison to what is shown in the GUI when manually searching for torrents. That is why I wanted to try out whether going into "active" mode makes any difference.
With the fix now included, does your transmission still show the port as open?
When you say 'via vpn image' you just mean that you're using the docker-compose-transmission-vpn file as described in VPN.md, right?
I couldn't spot any difference in download speeds yet though, so I don't think that it's a false negative.
I think the vpn transmission image has a mechanism of generating a random port forwarding/peer port which is generated at boot time. And the docker compose setting includes NET_ADMIN which, afaik, gives it super privileges to manipulate the host's network settings (e.g opening that port).
For instance, my peer port is the following even though I never explicitly opened it:
And here's part of the transmission logs:
Provider PIA has a script for automatic port forwarding. Will run it now.
If you want to disable this, set environment variable DISABLE_PORT_UPDATER=true
Running functions for token based port fowarding
Reserved Port: 24528 Wed Dec 29 14:24:44 UTC 2021
setting transmission port to 24528
Checking port...
Port is open: Yes
Port: 24528
I apologize this probably isn't helpful. I'm not as versed in networking as I'd like to be.
@lardbit
The log explains why it works for you: Provider PIA has a script for automatic port forwarding.
So your VPN has port forwarding (mine does not) and it is enabled automatically by a script in that image.
From what I found out so far it should also be possible without port forwarding in the VPN but probably I would need to fiddle with these firewall settings described here or maybe explicitly setting the peer port as someone got it working that way
I will try these out and then probably come back to this issue. Maybe documentation or defaults can then be improved on our side and maybe also on the vpn image side.
Ah, that makes sense. Manually defining the peer port using haugene's vpn transmission image sounds promising. Please keep me in the loop on what you come up with. His image is very powerful and it has so many options it's kind of overwhelming.
Found out that ufw isn't enabled and the manual setting didn't help.
It seems like I'm out of luck if I want to stay with the current VPN provider: (which actually makes sense)
After starting Transmission there is an optional step that some providers have; to get an open port and set it in Transmission. Opening a port in your local router does not work. I made that bold because it's a recurring theme. It's not intuitive until it is I guess. Since all your traffic is going through the VPN, which is kind of the point, the port you have to open is not on your router. Your router's external IP address is the destination of those packets. It is on your VPN providers end that it has to be opened. Some providers support this, other don't. We try to write scripts for those that do and that script will be executed after starting Transmission if it exists for your provider.
Oh that does make sense now that it's explained. Interesting. Luckily VPNs are cheap and disposable.
I got it working now!
I needed to add a custom transmission peer port and also enable IPv6 for docker-compose.
I didn't find anything better than adding this into the docker-compose though:
sysctls:
- net.ipv6.conf.all.disable_ipv6=0 # disable to 0 = enable :)
found it in the image documentation & their github issues
I propose that we add:
- TRANSMISSION_PEER_PORT=${TRANSMISSION_PEER_PORT} to the base or vpn compose file
- A note and a link to the transmission-openvpn doc regarding port forwarding to the VPN.md
Regarding ipv6 I'm not sure how we can do this so that not all users have it enabled and those that need it, can still follow the note in the header of the file: DO NOT EDIT THIS FILE 😄
Interesting. Glad you figured it out. I'm fine with adding this ipv6 setting to the docker compose vpn file, and we can utilize the .env file to keep it disabled by default.
sysctls:
- net.ipv6.conf.all.disable_ipv6=${VPN_IPV6:0} # disable to 0 = enable :)
Where the .env file would have something like:
# 1=yes, 0=no
VPN_IPV6=1
Then it would be disabled by default and you can toggle it via env settings.
Are you comfortable adding a pull request for this?