Since the latest (189) update, it does not download the transmission. I can see, but the download doesn’t work.
1 Like
I think it would be good to get some logs to see what they show.
I will have a look at them but as I don’t use and haven’t used transmission, I may not be able to understand the logs well enough. Hopefully other more experienced transmission users will have a look and be able to help also.
Which logs do you want? (Also write the command how to retrieve them.)
Well presumably the transmission logs but I think you already said in the previous thread that transmission doesn’t provide logs unless you start it with
I am not familiar enough with transmission to know which logs would be needed and I wasn’t aware that transmission needed to be started as above to provide logs.
I would presume that if the above is the way to get any logs, then you need to run that command and then try and get a download running that fails, then hopefully there will be some info in the log created.
> [root@wrouter ~]# cat /var/ADAT/transmission2/transmission.log
> [2024-09-25 19:41:51.605] inf session.cc:646 Transmission version 4.0.5 (a6fe2a64aa) starting (session.cc:646)
> [2024-09-25 19:41:51.605] inf session.cc:404 Listening to incoming peer connections on [0.0.0.0]:6970 (session.cc:404)
> [2024-09-25 19:41:51.605] inf session.cc:404 Listening to incoming peer connections on [::]:6970 (session.cc:404)
> [2024-09-25 19:41:51.605] inf tr-udp.cc:168 Bound UDP IPv4 address [0.0.0.0]:6970 (tr-udp.cc:168)
> [2024-09-25 19:41:51.605] inf tr-udp.cc:202 Bound UDP IPv6 address [::]:6970 (tr-udp.cc:202)
> [2024-09-25 19:41:51.605] inf session-alt-speeds.cc:91 Time to turn on turtle mode (session-alt-speeds.cc:91)
> [2024-09-25 19:41:51.605] inf rpc-server.cc:763 Added '127.0.0.1' to host whitelist (rpc-server.cc:763)
> [2024-09-25 19:41:51.605] inf rpc-server.cc:907 Serving RPC and Web requests on 0.0.0.0:9091/transmission/ (rpc-server.cc:907)
> [2024-09-25 19:41:51.605] inf rpc-server.cc:713 Listening for RPC and Web requests on '0.0.0.0:9091' (rpc-server.cc:713)
> [2024-09-25 19:41:51.605] inf rpc-server.cc:917 Password required (rpc-server.cc:917)
> [2024-09-25 19:41:51.605] inf rpc-server.cc:923 Serving RPC and Web requests from '/usr/share/transmission/public_html' (rpc-server.cc:923)
> [2024-09-25 19:41:51.605] inf daemon.cc:715 Loading settings from '/etc/transmission' (daemon.cc:715)
> [2024-09-25 19:41:51.605] inf daemon.cc:751 Requiring authentication (daemon.cc:751)
> [2024-09-25 19:41:51.605] inf session.cc:1406 Loaded 109 torrents (session.cc:1406)
I don’t understand most of the content of that log but no where in there are there any warnings or errors being shown, which I would expect if there was some problem in making the downloads work due to transmission.
Have you added any firewall rules in the recent past that might block transmission from downloading?
Nothing has changed anywhere. But I turned off everything as a test (IPS, Locblock, etc) and it doesn’t even download.
Did the Permissions change?
I don’t know how to check.
Permissions have not changed. If you cannot write to the disk because of that, then an error is written on the web interface. The transmission doesn’t show any errors here.
It might be worth asking your questions about the download problem and how to debug it on the transmission forum.
Maybe try looking at the transmission traffic to see at which point in the download process it is being stopped. You should be able to use tshark or tcpdump for that, i would think. The transmission forum people might be better placed to help on what the download process involves and how to check it with something like tshark or tcpdump or…
I set Transmission to port 6970. My firewall logo on this port says:
10:29:08 DROP_INPUT ppp0 UDP 80.99.34.199 81.182.253.73 24292 6970
I am attaching a photo.
The torrent port is open.
Your port forward is rule 3. Are rules 1 and 2 dropping the traffic before it gets to rule 3.
Maybe move your rule 3 up to become rule 1 so it is dealt with first and see if that allows downloads.
I would just move it up to rule 1 and test to be 100% certain.
Also you don’t need a rule to allow the OpenVPN port access. It is done automatically by IPFire for the port number you define in the OpenVPN WUI page.
1 Like
Thanks, I’ll remove the ovpn rule then. I just put it in out of habit. 
I’ll test it right now.
Same. It says DROP on everything
Looking again at your Rules to allow access to the firewall, rule three is set for protocol TCP but the traffic that is being dropped is UDP so that is why it doesn’t match with your firewall rule.
You should either change it to UDP, or if it can come in on both TCP and UDP then you should create services for UDP:6970 and TCP:6970 and then combine the two into a service group Transmission ports and then use that service group in your firewall.
1 Like
Except that now you have drop traffic for TCP but not related to port 6970. You will always have a lot of DROP_INPUT traffic on RED.
With the udp rule in place do you still see the DROP_INPUT traffic for destination port 6970 or has that stopped now?
If yes and the download still does not work then there must still be some other rule blocking it.
Have you ever added anything into the firewall.local file?
The firewall was not set. Everything is the same as before, when the system worked.
Only the ipfire updates were installed.