Opened 9 years ago

Closed 7 years ago

Last modified 3 years ago

#1716 closed Enhancement (invalid)

send "&ip=" arg in tracker announces

Reported by: Yogarine Owned by:
Priority: Low Milestone: None Set
Component: Transmission Version: 1.73
Severity: Normal Keywords: ip proxy socks ssh tor announce
Cc: garrych@…

Description

Transmission doesn't announce an IP to the tracker. Normally this isn't a problem, even behind a NAT, as long as port forwarding is set up properly.

Buuut, some trackers (like BitGamer? or Underground Gamer) use the announce IP to detect whether the client is connectable... Unconnectable clients on these trackers will have a harder time.

What Transmission should do is properly announce the correct IP (not the local IP, it should detect the public IP) to the Tracker.

Change History (24)

comment:1 Changed 9 years ago by charles

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

Detecting the public IP is difficult to do and more difficult to get right, and impossible to do reliably. I can just see all kinds of nightmare scenarios with automatic detection finding the wrong gateway, for example, and people not knowing why their trackers are rejecting them.

In addition, the spec says "Some only honor it only if the IP address that the request came in on is in RFC1918 space. Others honor it unconditionally, while others ignore it completely.",

In short, the amount of effort to implement this far, far outweighs the benefits IMO.

comment:2 Changed 9 years ago by livings124

  • Milestone changed from 1.50 to None Set

Please don't set milestones unless you plan on implementing it.

comment:3 Changed 9 years ago by Yogarine

  • Resolution invalid deleted
  • Status changed from closed to reopened

In that case, you don't have to bother with auto-detection, just add an option to set an announce IP, that would be much less effort, and make most users that care/know about the problem happy.

comment:4 Changed 9 years ago by livings124

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

Allowing a user to set this value manually is hacky at best. IMO a user should have no direct control over the information that could be sent to a tracker.

comment:5 Changed 9 years ago by Yogarine

Well, in my case (and probably the case of every other member of BitGamer?/UG and related trackers that are behind a NAT) setting this value is very important. Important enough to have a big, bloated Azureus running instead of a sleek Transmission, just because Azureus does have a configuration option to modify the announce IP.

It might be hacky, but P2P, especially behind a NAT, is such a complicated topic that sometimes these kind of settings are essential. Setting a port manually can also be considered similarly hacky... When did you last configure a port number for Jabber in Pidgin? Even so, even Pidgin has an option to configure a public IP, and that's just a messenger.

In my idea, there would be one additional textinput to the Network tab in the Preferences, (Which hardly has any options to start with anyway.) with a simple label like "Public IP:". Leave it empty for nothing, put an IP in it if you're behind a NAT... Easy enough.

comment:6 Changed 8 years ago by someone

  • Keywords proxy socks ssh tor announce added
  • Resolution wontfix deleted
  • Status changed from closed to reopened
  • Version changed from 1.42+ to 1.73

The ability to manually set the announce IP (or a reliable way to detect the public IP address) is very important when the tracker communication is tunnelled through SSH using dynamic port forwarding or TOR because there is no way for the tracker or the peers to discover the real public IP. This makes seeding and leeching much slower because initially Transmission can only communicate with peers through outbound connections.

comment:7 Changed 8 years ago by charles

  • Type changed from Bug to Enhancement

comment:8 Changed 8 years ago by garrych

  • Cc garrych@… added

comment:10 Changed 8 years ago by charles

  • Summary changed from No announce IP address to send "&ip=" arg in tracker announces

comment:11 Changed 8 years ago by extasy

  • Priority changed from Low to Normal
  • Version changed from 1.73 to 1.76+

As stated in earlier posts this is a very important function.

In times when Internet is being watched by different organizations and government, vpn:ing is a good way of staying off the radar, I've got no reason of giving up my right to have my political view's private.

Most other clients on the market both on torrent, dcpp and ftp have tis function already implemented please make a prediction when or if it can be implemented. I will unfortunately need to look for alternative if this function is not being implemented.

comment:12 Changed 8 years ago by livings124

  • Priority changed from Normal to Low
  • Version changed from 1.76+ to 1.73

comment:13 Changed 8 years ago by User294

As for me, this could be useful in some cases when running through complicated NAT setup. As for autodetection, at least aMule implements the following technique: it asks several random peers what they see as external IP and if they can access external port and makes a conclusion if possible (i.e. most of peers agree on what is your external address and port). Surely in some cases it's problematic to detect IP at all (for example if IP changes for each connection due to load balancing techniques in use, etc).

comment:14 follow-up: Changed 8 years ago by extasy

Why make it so difficult? Why not just let the user enter their external IP. just like uTorrent or Deluge? If you need to use it, then you know how to find your own ip and enter it.

comment:15 in reply to: ↑ 14 Changed 8 years ago by jch

Replying to extasy:

Why not just let the user enter their external IP. just like uTorrent or Deluge?

Because we're aiming to make a program that "just works" without the need for complicated settings. If you want a BitTorrent? implementation with dozens of tweakable knobs, I most warmly recommend Deluge, KTorrent and Azureus.

As noted above, the ip argument is ignored by most trackers. If you have a usage scenario that actually makes this feature useful, I'll be glad to implement it.

--Juliusz

comment:16 Changed 8 years ago by charles

I'd be interested to hear if anyone has an answer for Juliusz' question about usage scenarios. If there aren't any practical use cases for this ticket it doesn't make sense to leave it open.

comment:17 Changed 8 years ago by extasy

Well, I have left Transmission for Deluge for this function. After changing I have gotten alot better speed for dl:s and if I loose my VPN tunnel the client stops uploading and downloading. Just the way I want it. I really liked Transmission. But it's not my baby and since the crew have been against this function from start, I gave up very easy. I can just say that function really gave me more peers to download from.

So I wish you guys luck with Transmission. Try to avoid making it "to simple" good functions should be implemented imho anyway.

comment:18 Changed 8 years ago by charles

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

Depending on the scope of this feature I'm not really against it. autodetection is a nonstarter and GUI-level support is very unlikely; on the other hand, a simple entry in settings.json would not be hard to do, and would at least provide a mechanism for heavily motivated users.

On the other hand, there's only been one pro-&ip post in this ticket in the last year except for extasy, who's now moved on to greener pastures. So it's not clear to me how many users this would benefit. It would be nice to hear from other users on this.

I'm closing this ticket due to lack of interest, but am open to the idea of end uses reopening it to give use cases for this feature.

comment:19 Changed 8 years ago by garrych

  • Resolution invalid deleted
  • Status changed from closed to reopened

The idea was commented a bit earlier. The scenario with proxy usage is what I see as a good reason. We announce out ip address through proxy. Some trackers can utilize it some just don't. But this is a useful feature. Thanks

comment:20 Changed 8 years ago by garrych

I can explain the "lack of interest" with your continuos denying this feature. So people try to find some way around and choose another solution. Not good.

comment:21 Changed 7 years ago by jordan

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

Nobody new has requested this ticket in a year.

garrych's suggestion that the development team is the reason users are silent on this ticket isn't persuasive to me -- the "bring back proxies" ticket shows users aren't afraid of arguing with the development team. What's happening here is that nearly nobody cares about this feature.

As has already been pointed out, most trackers don't support this feature anyway.

So most trackers don't support this, and most users don't care about this.

comment:22 Changed 5 years ago by stevenc648

I for one would like to see this feature, I was just going to use another client because registering to ask for a feature that should be included in the outset seems like a waste of time to most people. However this is the client that came preinstalled in my operating system so I will see if the development team will include it. Come on its 2012 and people dont just connect to the internet direct as much as they used to.

comment:23 Changed 4 years ago by yozik04

I would be also interested in this feature. I have a tracker and a Transmission client on the same network and many clients on the external network. Internal client needs to be configured to give it's external address to the tracker to be able to seed. Currently it is not possible with Transmission.

comment:24 Changed 3 years ago by Stealth

I'm also interested in such feature, because I have both main seeding box and the tracker itself behind the firewall.

Note: See TracTickets for help on using tickets.