Opened 8 years ago

Last modified 5 years ago

#3452 reopened Enhancement

Port forwarding stopped working between 2.01 and 2.03

Reported by: 2toke Owned by:
Priority: Normal Milestone: None Set
Component: Transmission Version: 2.03
Severity: Normal Keywords:
Cc:

Description (last modified by charles)

2010-07-25 22:31:07 -0700 tracker.c:616 [Debug] Season 12: scrape response: 0
2010-07-25 22:31:07 -0700 tracker.c:332 [Info] Season 12: Trying tracker "http://tracker.openbittorrent.com/announce"
2010-07-25 22:31:16 -0700 port-forwarding.c:116 [Info] Port Forwarding: Closing port 51413 on ::
2010-07-25 22:31:16 -0700 port-forwarding.c:116 [Info] Port Forwarding: Closing port 51413 on 0.0.0.0
2010-07-25 22:31:16 -0700 net.c:542 [Debug] Transmission: Bound socket 12 to port 51413 on ::
2010-07-25 22:31:16 -0700 port-forwarding.c:153 [Info] Port Forwarding: Opened port 51413 on :: to listen for incoming peer connections
2010-07-25 22:31:16 -0700 net.c:542 [Debug] Transmission: Bound socket 15 to port 51413 on 0.0.0.0
2010-07-25 22:31:16 -0700 port-forwarding.c:153 [Info] Port Forwarding: Opened port 51413 on 0.0.0.0 to listen for incoming peer connections
2010-07-25 22:32:12 -0700 tracker.c:616 [Debug] Season 12: scrape response: 0
2010-07-25 22:33:25 -0700 tracker.c:616 [Debug] Season 12: scrape response: 0
2010-07-25 22:33:25 -0700 tracker.c:332 [Info] Season 12: Trying tracker "http://tracker.openbittorrent.com/announce"
2010-07-25 22:34:30 -0700 tracker.c:616 [Debug] Season 12: scrape response: 0
2010-07-25 22:36:43 -0700 tracker.c:616 [Debug] Season 12: scrape response: 0
2010-07-25 22:36:43 -0700 tracker.c:332 [Info] Season 12: Trying tracker "http://tracker.openbittorrent.com/announce"
2010-07-25 22:37:48 -0700 tracker.c:616 [Debug] Season 12: scrape response: 0

Change History (22)

comment:1 Changed 8 years ago by livings124

  • Resolution set to worksforme
  • Status changed from new to closed

Since it just stopped working, something more than likely changed on your end. This is better suited for the forums.

comment:2 Changed 8 years ago by howl

I don't know if I have to fil a new ticket but the issue I have found is described here.

Using transmission - 2.03-0ubuntu1.09.10.2 port is not forwarded anymore with upnp, log shows like this:


Tue Jul 27 16:19:27 2010 Transmission 2.03 (11030) iniciado
Tue Jul 27 16:19:27 2010 RPC Server Adding address to whitelist: 127.0.0.1
Tue Jul 27 16:19:27 2010 DHT Reusing old id
Tue Jul 27 16:19:27 2010 DHT Bootstrapping from 80 nodes
Tue Jul 27 16:19:27 2010 LPD Descubrimiento de pares locales activado
Tue Jul 27 16:19:27 2010 Impedir hibernación de escritorio
Tue Jul 27 16:19:27 2010 La lista de bloqueo «level1.bin» contiene 224846 entradas
Tue Jul 27 16:19:27 2010 Reenvío de puertos (NAT-PMP) initnatpmp tuvo éxito (0)
Tue Jul 27 16:19:27 2010 Reenvío de puertos (NAT-PMP) sendpublicaddressrequest tuvo éxito (2)
Tue Jul 27 16:19:27 2010 Cargados 117 torrents
Tue Jul 27 16:19:27 2010 Reenvío de puertos El estado cambió de "No reenviado" a "Iniciando"
Tue Jul 27 16:19:35 2010 Reenvío de puertos El estado cambió de "Iniciando" a "???"
Tue Jul 27 16:19:50 2010 «/home/transmission.config/settings.json» guardado
Tue Jul 27 16:19:50 2010 «/home/transmission.config/settings.json» guardado
Tue Jul 27 16:19:50 2010 «/home/transmission.config/settings.json» guardado
Tue Jul 27 16:20:15 2010 «/home/transmission.config/settings.json» guardado
Tue Jul 27 16:20:15 2010 «/home/transmission.config/settings.json» guardado
Tue Jul 27 16:20:15 2010 «/home/transmission.config/settings.json» guardado
Tue Jul 27 16:20:26 2010 Reenvío de puertos Detenido
Tue Jul 27 16:20:26 2010 «/home/transmission.config/settings.json» guardado
Tue Jul 27 16:20:33 2010 «/home/transmission.config/settings.json» guardado
Tue Jul 27 16:20:33 2010 Reenvío de puertos (NAT-PMP) initnatpmp tuvo éxito (0)
Tue Jul 27 16:20:33 2010 Reenvío de puertos (NAT-PMP) sendpublicaddressrequest tuvo éxito (2)
Tue Jul 27 16:20:33 2010 Reenvío de puertos El estado cambió de "No reenviado" a "Iniciando"
Tue Jul 27 16:20:41 2010 Reenvío de puertos El estado cambió de "Iniciando" a "???"


There are two tries to forward, one at the start and the second one because I disabled and then enabled again, but the same result.

Going back to transmission - 2.01-0ubuntu1.09.10.1 port forward works and the lines I highlighted are not shown.

comment:3 Changed 8 years ago by howl

  • Resolution worksforme deleted
  • Status changed from closed to reopened

comment:4 Changed 8 years ago by charles

  • Summary changed from Port forwarding not working, used to download fast, heres debug to Port forwarding stopped working between 2.01 and 2.03
  • Version changed from 1.52+ to 2.03

comment:5 Changed 8 years ago by charles

The only change to port forwarding between 2.01 and 2.03 was this one:

https://trac.transmissionbt.com/changeset/10910

If you take 2.03's source code and remove that change, does the modified version of 2.03 work for you?

comment:6 Changed 8 years ago by howl

Yes, it works. I have get the deb.src corresponding the same one I used to install and reverting that code it works as usual.

comment:7 Changed 8 years ago by charles

  • Description modified (diff)
  • Priority changed from Highest to Normal
  • Severity changed from Major to Normal

comment:8 Changed 8 years ago by charles

r10910 was added to address #3385, which was that UPNP_GetValidIGD()'s return value wasn't being checked closely enough. According to miniupnp's documentation:

/* UPNP_GetValidIGD() :
 * return values :
 *     0 = NO IGD found
 *     1 = A valid connected IGD has been found
 *     2 = A valid IGD has been found but it reported as
 *         not connected
 *     3 = an UPnP device has been found but was not recognized as an IGD

The change made between 2.01 and 2.03 that caused this ticket was that we used to check for UPNP_GetValidId()'s return value to be nonzero, and now we check to see if its value is 1.

Unless I'm misunderstanding, values other than 1 are undesirable. Is it possible that the port wasn't really forwarded in 2.01, but that due to this code Transmission incorrectly reported that it was port forwarded?

On the other hand, if you can confirm (outside of Transmission) that the ports *were* forwarded in 2.01 but not in 2.03, what is the return value of UPNP_GetValidId() in 2.01 and 2.03?

comment:9 Changed 8 years ago by howl

Yes I checked it from the outside by asking the tracker to handshake with me, with 2.01 was response with the number of pieces completed and with 2.03 could not connect.

comment:10 follow-up: Changed 8 years ago by charles

Howl, could you please modify the call to UPNP_GetValidIGD() so that we can see its return code?

Index: upnp.c
===================================================================
--- upnp.c	(revision 11153)
+++ upnp.c	(working copy)
@@ -105,8 +105,10 @@
                 tr_strerror( errno ) );
         }
         errno = 0;
-        if( UPNP_GetValidIGD( devlist, &handle->urls, &handle->data,
-                             handle->lanaddr, sizeof( handle->lanaddr ) ) == UPNP_IGD_VALID_CONNECTED )
+        ret = UPNP_GetValidIGD( devlist, &handle->urls, &handle->data,
+                                handle->lanaddr, sizeof( handle->lanaddr ) );
+        tr_ndbg( getKey( ), "UPNP_GetValidIGD() returned %d", ret );
+        if( ret == UPNP_IGD_VALID_CONNECTED )
         {
             tr_ninf( getKey( ), _(
                          "Found Internet Gateway Device \"%s\"" ),

comment:11 Changed 8 years ago by howl

Until the mid end of the next week I can't, but be sure I will do it then :)

comment:12 in reply to: ↑ 10 Changed 8 years ago by howl

Thats the ouput with debugs messages and the patch applied. I used version 2.04 instead of 2.03 but still the same, without the change from 2.01 port is not redirected and removing the change in upnp from 2.01 port is redirected.


Sat Aug 14 16:16:56 2010 Transmission 2.04 (11151) iniciado
Sat Aug 14 16:16:56 2010 debug No se pudo leer «/home/ubuntu/.config/transmission/stats.json»: No existe el fichero ó directorio
Sat Aug 14 16:16:56 2010 debug No se pudo leer «/home/ubuntu/.config/transmission/stats.benc»: No existe el fichero ó directorio
Sat Aug 14 16:16:56 2010 RPC Server Adding address to whitelist: 127.0.0.1
Sat Aug 14 16:16:56 2010 debug Bound socket 12 to port 51413 on 0.0.0.0
Sat Aug 14 16:16:56 2010 debug Bound socket 13 to port 51413 on ::
Sat Aug 14 16:16:56 2010 debug setrlimit( RLIMIT_NOFILE, 1024 )
Sat Aug 14 16:16:56 2010 debug socket limit is 240
Sat Aug 14 16:16:56 2010 debug DHT Initializing DHT
Sat Aug 14 16:16:56 2010 debug No se pudo leer «/home/ubuntu/.config/transmission/dht.dat»: No existe el fichero ó directorio
Sat Aug 14 16:16:56 2010 DHT Generating new id
Sat Aug 14 16:16:56 2010 debug DHT DHT initialized
Sat Aug 14 16:16:56 2010 debug LPD Descubrimento de pares locales desactivado
Sat Aug 14 16:16:56 2010 debug setrlimit( RLIMIT_NOFILE, 1024 )
Sat Aug 14 16:16:56 2010 debug socket limit is 240
Sat Aug 14 16:16:56 2010 Reenvío de puertos (NAT-PMP) initnatpmp tuvo éxito (0)
Sat Aug 14 16:16:56 2010 Reenvío de puertos (NAT-PMP) sendpublicaddressrequest tuvo éxito (2)
Sat Aug 14 16:16:56 2010 debug Reenvío de puertos (UPnP) UPNP_GetValidIGD() returned 3
Sat Aug 14 16:16:56 2010 debug Reenvío de puertos (UPnP) UPNP_GetValidIGD failed (errno 0 - Éxito)
Sat Aug 14 16:16:56 2010 debug Reenvío de puertos (UPnP) If your router supports UPnP, please make sure UPnP is enabled[[BR]] Sat Aug 14 16:16:56 2010 Reenvío de puertos El estado cambió de "No reenviado" a "Iniciando"
Sat Aug 14 16:17:04 2010 debug Reenvío de puertos (NAT-PMP) readnatpmpresponseorretry failed. natpmp returned -7 (the gateway does not support nat-pmp); errno is 111 (Conexión rechazada)
Sat Aug 14 16:17:04 2010 Reenvío de puertos El estado cambió de "Iniciando" a "???"
Sat Aug 14 16:17:34 2010 DHT Attempting bootstrap from dht.transmissionbt.com


Despite 3 is returned, actually in my network the only one UPnP device is the modem-router, so it should be saw as a IGD and also connected as is always :)

Edit: I lied, I have recheck my network and I have one UPnP device that isn't an Internet Gateway Device. I have no time now but I will try to see if the first time Transmission redirect using the right UPnP device (it does because the port is redirected in previous versions) and when checking for an IGD device found the other UPnP device instead of the router. If trying without my another UPnP device connected doesn't work, I suppose the bug should be in libupnp returning incorrect igd, or, in the router identifying as bad itself. If it works without the another UPnP device i suppose it should be a way to tell libupnp to check igd in the device used to redirect the port and not in another one.

Last edited 8 years ago by howl (previous) (diff)

comment:13 Changed 8 years ago by howl

I have tested now only with the router as a UPnP device in my network, the result is the same as above.

comment:14 Changed 8 years ago by charles

Howl,

I've just read through the libtransmission code and reread this ticket and I think this may be a problem with the miniupnpc library rather than Transmission.

Could you please report this issue upstream to http://miniupnp.tuxfamily.org/forum/viewforum.php?f=5 ?

comment:15 Changed 8 years ago by howl

  • Resolution set to invalid
  • Status changed from reopened to closed

Done: http://miniupnp.tuxfamily.org/forum/viewtopic.php?t=666, interesting topic id :) I suppose this should be closed as invalid then, if not reopen it.

comment:16 Changed 8 years ago by charles

Yes I agree: if you find this is a Transmission bug after all, please reopen this ticket. Thank you!

comment:17 Changed 6 years ago by howl

  • Resolution invalid deleted
  • Status changed from closed to reopened
  • Type changed from Bug to Enhancement

I change this from bug, as it's not even in miniupnpc, to enhancement. The problem is that the router doesn't idetify itself as an igd so it's a hardware bug.

A suggestion done by the miniupnp admin is that the application offer an option to let redirection even with an invalid igd.

I think that this is not going to be consider as it's a very special situation, but had to try it :)

comment:18 follow-up: Changed 6 years ago by jordan

  • Resolution set to invalid
  • Status changed from reopened to closed

howl, I think this preferences option would only be used by one person :)

comment:19 in reply to: ↑ 18 Changed 6 years ago by x190

Replying to jordan:

howl, I think this preferences option would only be used by one person :)

Jordan: Could you expand on this issue a bit? I deal with dozens of these uPnP issues on the forum (used to work, now doesn't or works with µT but not T, etc.). Why would it need to be an option? I think most users just want their port opened if it is at all possible.

comment:20 Changed 5 years ago by bviktor

  • Resolution invalid deleted
  • Status changed from closed to reopened

x190 is right. I have no idea how it'd be more desirable to work on fewer devices than on more. Neither do I know how it's "invalid" when someone complains if you intentionally break a feature that already worked. It's just not justifiable in any way to be pedantic at the cost of usability. I have a TP-Link 1043ND which is quite mainstream, yet MiniUPnP doesn't seem to support it, and so Transmission can't make the required ports open either. Of course, all my other applications can open the ports via UPnP just fine.

It's not quite logical or affordable to require anyone affected to set up DMZ or manual port forwarding just because Transmission decides to deny not-so-correct responses. It'd be great if we could stick to the paper form, but until buggy devices are out there (yes, there's a lot), you don't need to be that strict just for the sake of compliance.

Patching doesn't make too much sense either. Look, I have a really old (Pentium 1) headless OpenBSD server with an 1GB CF card, so compilation's just out of question. I don't think all seedboxes are powerful enough to do this either. Is it really supposed to be necessary for me to set up a separate OpenBSD or whatever build VM just to patch out some 2 words in the code to get it work? I don't think so. If you don't want it by default, just make it an option or whatever. It won't hurt.

So basically, from what I see, this change causes quite some harm, for absolutely no good. Unless I'm seriously missing something.

comment:21 Changed 5 years ago by jordan

  • Resolution set to wontfix
  • Status changed from reopened to closed

I'm still against this change for a handful of reasons.

  1. It doesn't appear to affect very many people. x190 mentioned people with port forwarding issues in the forums, but it's impossible to know if those issues are caused by this particular case, and only a couple of people have commented on this ticket in the three years it's been open.
  1. If we change libtransmission's code to pretend that port forwarding succeeded even when miniupnp returned failure, what errors will that cause? For one thing, the code retries periodically if port forwarding fails. This change would prevent those retries from being triggered.
  1. If this was made into a preferences option, how on earth do you explain in a brief phrase what it does? Why should we be confusing all the users for a problem that only a few people are known to be having?
  1. This is all just for automatic port forwarding, there are other alternatives. If one's broken router doesn't support automatic port forwarding correctly, one could go into the router's configuration and have it always forward the desired port and disable the upnp toggle in Transmission.

comment:22 Changed 5 years ago by rb07

  • Resolution wontfix deleted
  • Status changed from closed to reopened

miniupnp returned failure

No it didn't, the meaning of the return codes is not clear, even miniupnp's own upnpc doesn't use only a UPNP_IGD_VALID_CONNECTED code, it opens the port also when other codes happen... and it works on those buggy/faulty routers. I don't have a faulty router to test, but Tr-Qt for Windows uses the reverted code after an user asked to fix the same problem reported here, the fix worked in that case, and nobody has complained in the 2 - 3 years that change has been in the released binaries.

The least that could be done is keep miniupnp updated, if the problem was in it maybe its solved now (1.8 was released last June, which also adds better support for IPv6). Transmission sources is using an older version; Transmission also has the option of using an installed miniupnp (libraries).

Note: See TracTickets for help on using tickets.