That Silly Transmission (client)

Support & Help Requests
1

Often when I'm fetching an .ISO I use the Transmission BitTorrent client to a) save on bandwidth and b) share the file with others. I've experienced some issues with Transmission lately and out of curiosity checked the port I had assigned to it. In this case, the port is 51412. When I test this in Transmission-gtk, the response is "Closed." However, I have configured this in ufw.

> sudo netstat -nlp | grep 51412
> [sudo] password for ******: 
> tcp        0      0 0.0.0.0:51412           0.0.0.0:*               LISTEN      11958/transmission- 
> tcp6       0      0 :::51412                :::*                    LISTEN      11958/transmission- 
> udp        0      0 0.0.0.0:51412           0.0.0.0:*                           11958/transmission- 
> udp6       0      0 2600:4040:46ef:f9:51412 :::*                                11958/transmission-

Since I wasn't receiving any data, I quite Transmission, cleared out the torrents in ~/.config/transmission/torrents, made sure to killall transmission and restarted the program. The torrents started flowing again, but Transmission still reports the port is closed. Go figure.

1 Like
2

Usually gateway router has to be configured to forward incoming NNNN port connection to the client computer as well.

1 Like
3

I just confirmed that my gateway is properly configured. Port 51412 forwards TCP to the same port on my server. I don't think Transmission has ever used (or required) UDP.

And since it's working, I suspect the issue is with the way Transmission tests the port.

1 Like
4

I have just verified my setup and can confirm an issue:

  • router: port forwarding configured
  • computer: port is being listened
  • transmission: reports port to be closed
  • external port scan: timeout

BTW: UM 24.04.2

2 Likes
5

It's nice to know I'm not alone for a change. :slight_smile:

I'm using 3.00 (bb6b5a062e), which is the latest available. Or, as apt lists it:

transmission is already the newest version (3.00-2ubuntu2.1).

1 Like
6

Mine is 4.0.5 (a6fe2a64aa)

1 Like
7

I guess you install outside of apt? Not that it matters, since the issue remains.

1 Like
8

No, transmission was upgraded during UM latest LTS upgrade.

1 Like
9

Well, I'm still running an older 22.04.5 LTS, so that might explain it. Nevertheless, the point remains that Transmission doesn't know (or recognize) what port it's using. That one can specify a port is nice for security and management, but Transmission also allows for randomizing its port, so I guess the developers haven't given it too much thought.

1 Like
10

Provided that local port scan shows port to be open, I'm inclined to blame my ISP to block P2P traffic or fancy ports.

1 Like
11

I tried it on my um24, d/l some iso. netstat shows port 51413 listen (tcp/udp)

tcp        0      0 0.0.0.0:51413           0.0.0.0:*               LISTEN      75665/transmission- 
udp        0      0 0.0.0.0:51413           0.0.0.0:*                           75665/transmission-

nmap -p51413 um24 shows this port as open
51413/tcp open unknown

Closed transmission, nmap shows port closed.
51413/tcp closed unknown

Not sure I understand the issue.

1 Like
12

Transmission is working fine for me after I cleaned up the leftover crud (I think there were multiple instances running). So, I'm not being blocked, but it's curious that Transmission reports the port it's listening on is closed.

1 Like
13

I'm not sure there's an issue more than Transmission is (incorrectly) reporting the port it's set to listen on is closed. It's working for me regardless.

1 Like
14

I'm running transmission on 22.04.5 LTS as well.
Strangely enough I don't happen to encounter this problem. Transmission nicely reports that the port I set is open.

Version: transmission 4.0.5-1 (xtradeb)

2 Likes
15

BitTorrent is pretty nice in that you don't need an open port to send/receive files with other peers, as long as one of the peers in the swarm has an open port to initiate a connection. A closed port just means they can't directly connect to you, so progress might be less performant.

If you have μTP enabled, that uses UDP and would need forwarding too.

Randomization might work better with UPnP enabled, since UPnP allows the program to ask the router "Hey! I'd like to open a port across our NAT to the WAN (internet) please!" aka. incoming connections to that port number (51412) via public IP address will be forwarded to that computer.

It's also possible that a router (with UPnP on) is still forwarding an earlier request, possibly if the program didn't tell the router that it's done and can close that port. In which case, restarting the router should do the trick.

I tested in a VM. It's working as expected in 24.04.

My VM behind its own [NAT] → [Main Network] → Router → Internet = :no_entry: Closed
[:laptop:] → [:mobile_phone: :desktop_computer: :desktop_computer:] :telephone_receiver: → :globe_showing_europe_africa: Nope, stuck behind 2 NATs and didn't get forwarded.

My VM is bridged, part of the [Main Network] → Router → Internet = :white_check_mark: Open (with UPnP)
[:laptop: :mobile_phone: :desktop_computer: :desktop_computer:] :telephone_receiver: → :globe_showing_europe_africa: :51413

To rule it out, try using an online tool to test that port number at your public IP address. Odds are it'll be closed. Could mean:

  • The local firewall is blocking that port when accessed from anywhere (0.0.0.0).
  • Wrong protocol (TCP/UDP) being forwarded.
  • The static port forward on the router isn't set up properly, or points to the wrong computer. (Could happen if the LAN IP address is dynamic, aka. DHCP)
  • UPnP is disabled and there isn't a static port forward.
  • Rarely, ISP monitors and blocks the port. Try another number.
    • Configuring Transmission to require encryption :locked: and not use μTP could be an option.
4 Likes
16

As you have mentioned above regarding NATted VM, there are ISP options which effectively prevent connection to the port in question from Internet. That is ISP could use NAT in overload mode or transparent proxy/gateway.

2 Likes
17

Any ISP that attempts to modify what ports I can and cannot use will not be my ISP much longer.

2 Likes