transmission is using the wrong upnp device for portforwarding

Bug #500153 reported by fbraun
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
transmission (Ubuntu)
Invalid
Undecided
Unassigned

Bug Description

Binary package hint: transmission

Transmission gladly reports that it enabled port forwarding via UPnP on 172.16.3.10, but (as it should know!) 172.16.3.10 is *not* my gateway and not responsible for any port-forwarding regarding my internet connection.
A simple "route -n" would suffice, to check against this :)

ProblemType: Bug
Architecture: amd64
CheckboxSubmission: b2f2c3385a2bd6c186b5be455752c845
CheckboxSystem: d00f84de8a555815fa1c4660280da308
Date: Thu Dec 24 16:07:54 2009
DistroRelease: Ubuntu 9.10
ExecutablePath: /usr/bin/transmission
LiveMediaBuild: Ubuntu 9.10 "Karmic Koala" - Release amd64 (20091027)
Package: transmission-gtk 1.75-0ubuntu2
ProcEnviron:
 PATH=(custom, user)
 LANG=de_DE.UTF-8
 SHELL=/bin/bash
ProcVersionSignature: Ubuntu 2.6.31-16.53-generic
SourcePackage: transmission
Uname: Linux 2.6.31-16-generic x86_64

Revision history for this message
Charles Kerr (charlesk) wrote :

Thank you for taking the time to report this bug and helping to make Ubuntu better.

Transmission uses an unmodified version of miniupnpc for port forwarding, so I'm reassigning this ticket to the miniupnpc package. If there's more attention needed by the Transmission team, feel free to ping me.

Revision history for this message
Charles Kerr (charlesk) wrote :

It looks like there's no miniupnpc component in launchpad, so I've reported this bug upstream to the developers of the software. You can track it and make comments at: http://miniupnp.tuxfamily.org/forum/viewtopic.php?p=1539#1539

Changed in transmission (Ubuntu):
status: New → Invalid
Revision history for this message
fbraun (fbraun) wrote :

Thanks Charles :)

Revision history for this message
miniupnp (miniupnp) wrote :

Please explain your network setup and include the output of "route -n".

Revision history for this message
fbraun (fbraun) wrote :

The point is: My network is using 172.16.3.1 - a debian box - for routing, internet access etc.
But there was also a normal "home router" (at 172.16.3.10) provided by my ISP connected to that debian box to provide wireless access at my home. This "home router" was advertising kinda rogueish, so miniupnc asked this one to do the portforwarding stuff.
What I expected is miniupnc to question whether 172.16.3.10 was truely in charge for port forwarding and discard its UPnP service, because it is not the current router.

This is route -n,
Default output is in german, sorry. But it should be kinda obvious, maybe except for "Routentabelle" (Routing table) and Ziel (Target).

Kernel-IP-Routentabelle
Ziel Router Genmask Flags Metric Ref Use Iface
172.16.3.0 0.0.0.0 255.255.255.0 U 2 0 0 eth0
169.254.0.0 0.0.0.0 255.255.0.0 U 1000 0 0 eth0
0.0.0.0 172.16.3.1 0.0.0.0 UG 0 0 0 eth0

Revision history for this message
miniupnp (miniupnp) wrote :

Well if the home router is the only UPnP IGD advertising its presence on the networks, it will be used. If several UPnP IGD are present on the network, mniupnpc will make a choice depending on which one reports it is online.
If you dont want your network hosts to use the UPnP services of your home route, you should disable the UPnP service.
UPnP IGD is not designed to work when several routers are present on the same LAN subnet.
Your network setup is indeed strange.

Revision history for this message
miniupnp (miniupnp) wrote :

I'm guessing that the port forwarding is indeed working. Isn't it ?
The UPnP redirection is doing this job. There is nothing in the UPnP Spec that forbid to use a device because it is not the /default/ router.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.