Opened 11 years ago

Last modified 19 months ago

#2313 new Enhancement

interface binding

Reported by: gornack Owned by: charles
Priority: Low Milestone: None Set
Component: Transmission Version: 1.73
Severity: Normal Keywords: patch-needed
Cc: udovdh@…, atm999@…, abaustin@…, trac.transmissionbt.com@…, mathewparet@…, dmnd@…, jisloane@…

Description

I think it would be great to implement "bind-to-an-interface" (aka SO_BINDTODEVICE passed to socket()) support ?

I have a network interface with a dynamic IP address (see #2312 for details on my configuration), so I have to change settings.json each time my IP address changes.

It would be great to be able to set a binding device in settings.json :

bind-interface-ipv4: "ppp0",

Thanks in advance.

Attachments (13)

0001-Work-in-progress.patch (42.3 KB) - added by dreamcat4 10 years ago.
Mac only supported so far... & doesnt work yet
0001-patch-2313-dreamcat4-v2.patch (51.4 KB) - added by dreamcat4 10 years ago.
This patch is based off r10715
vpn-bind-interface.patch (83.9 KB) - added by shaun.tancheff 10 years ago.
ubuntu 10.04, patch based on launchpad transmission v 203, July 23, 2010. ~0 hrs GMT
vpn-bind-interface-minimal.patch (5.4 KB) - added by shaun.tancheff 10 years ago.
bind-to-interface-r11819-2.1x_branch.patch (51.7 KB) - added by ThornsArcana 10 years ago.
Bind to an interface patch against 2.1x branch r11819
bind-to-interface-r11819-trunk.patch (57.7 KB) - added by ThornsArcana 10 years ago.
Bind to an interface patch against trunk r11819. Use SO_BINDTODEVICE when possible.
bind-to-interface-r11829-trunk.patch (36.1 KB) - added by ThornsArcana 10 years ago.
Bind to an interface patch against trunk r11829. SO_BINDTODEVICE / getifaddrs.
bind-to-interface-r11870-trunk.patch (40.1 KB) - added by ThornsArcana 10 years ago.
Added libnetlink support.
bind-to-interface-thorns-r11870-v2.2.patch (46.4 KB) - added by dreamcat4 10 years ago.
Reworked the Mac OS-X Support
BindInterface Setting.png (64.3 KB) - added by dreamcat4 10 years ago.
Where to enable this feature on mac os x
bind-to-interface-thorns-r11870-v2.21.patch (48.2 KB) - added by dreamcat4 10 years ago.
Fixed linking to System Configuration Framework. Mac os x.
transmission-netdev.patch (66.8 KB) - added by marlemion 5 years ago.
Patch adopted to apply to and compile with 2.90
bind-to-interface-r14706.patch (67.1 KB) - added by ThornsArcana 5 years ago.
Bind to interface against SVN 14706.

Download all attachments as: .zip

Change History (135)

comment:1 Changed 11 years ago by charles

I don't have any big objection to this, so long as it stays out of the gui. however this nuts-and-bolts networking is not my forte, so it will happen *much* faster (ie, ever) if you cook up another patch for it.

comment:2 Changed 11 years ago by jhujhiti

  • Owner set to jhujhiti
  • Status changed from new to assigned

gornak: I saw your note on #2312 about which address gets announced to the tracker. Currently, we don't announce any address per-se. The tracker will use our source address, so the address at which other peers actually attempt to connect to you is really determined by your routing table (so it's very likely your default gateway). In your configuration, is ppp0 or eth0 the default?

comment:3 Changed 11 years ago by charles

  • Summary changed from Support interface binding to interface binding

comment:4 Changed 11 years ago by charles

  • Keywords patch-needed added

comment:5 Changed 11 years ago by charles

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

Six months have gone by and nobody has volunteered a patch or even seconded this request. Closing due to lack of interest.

As in my first comment, I still don't have any big objection to this so long as it stays out of the gui. But if nobody is going to use the feature, there's no need to add it.

If some future user sees this ticket because they want this feature, feel free to reopen, preferably with a patch. It's not even a complicated patch...

comment:6 Changed 11 years ago by udo

We might also need this patch if we want to use IPv6 privacy numbers (IPV6_PRIVACY=rfc3041).

I.e.: we want to open the firewall for bittorrents for this one IP but we want to surf from an ever changing IPv6. We could use an IP-alias on our interface and have transmission bind only to the not-rfc3041-treated number.

comment:7 Changed 11 years ago by udo

  • Cc udovdh@… added
  • Resolution invalid deleted
  • Status changed from closed to reopened

comment:8 Changed 11 years ago by jch

While I support this idea (being able to bind to a given IP address), the following is not true:

We might also need this patch if we want to use IPv6 privacy numbers (IPV6_PRIVACY=rfc3041).

RFC 3041 addresses are dynamic, but they tend to remain stable for a few hours at a time, which is well within the BitTorrent?'s protocol abilities. As a matter of fact, binding to RFC 3041 addresses is a good idea, since it keeps your MAC address secret from trackers.

--Juliusz

comment:9 Changed 11 years ago by jch

  • Component changed from Transmission to libtransmission
  • Priority changed from Normal to Low

I may not have been clear enough. The two features requested here (binding to a device and binding to a given address) are highly desirable for people running non-orthodox network configurations, such as VPNs or multiple network interfaces (say, both cheap satellite and expensive 3G).

They are not difficult to implement, but will require a lot of care, since there's quite a few places where Transmission binds sockets.

--Juliusz

comment:10 Changed 11 years ago by udo

  • Priority changed from Low to Normal

Maybe put the socket bindings in a sub routine? Please implement for both IPv4 and IPv6. Please bind to interface *and* number. (we can have multiple numbers to choose from...)

In my specific case I want the IPv6 privacy for browsing but don't need it (yet) for firewalling the open port 6881 for the one PC that is doing transmission.

comment:11 Changed 11 years ago by charles

  • Priority changed from Normal to Low

comment:12 Changed 11 years ago by udo

If you think that broswer privacy is of no concern to us, the consumers, then you must certainly set stuff like this to LOW priority. We want to combine privacy with safety on the firewall. Therefor we need this option.

comment:13 Changed 11 years ago by charles

udo: I don't see any "us, the consumers" here -- It's you who reopened this ticket, you who requested various checklist items for it, you who is complaining about the ticket's priority not being higher.

If this is something that "the consumers" were interested in, then "the consumers" would have probably added a comment to this ticket over the last 8 months. That didn't happen. I interpret that as users don't want or don't care about this feature. It sounds like this is a high priority to you, and you're throwing a temper tantrum that the development team hasn't stopped what it was doing to work on your request.

If you want this to be implemented in Transmission faster, please submit a patch.

comment:14 Changed 11 years ago by udo

Yes, I reopened. And yes, me submitting a patch would take a while as I am not a programmer. OTOH it is quite weird that a network-intensive program like transmission cannot be taugth to behave in certain ways like this because this ticket was closed because of lack of a patch with a few standrad system calls and a little logic. We (we are at xs4all.nl) got into IPv6 recently and got our attention to the dumbness in certain IPv6 design decisions. So we need to compensate. Blame me for discovering late. But: I do want to sponsor. Where can I pay 100 euros for someone to pick this ticket up?

comment:15 Changed 10 years ago by ben_murphy

It might help to learn how Vuze does this. Vuze can recognise the ppp0 who has dynamic address. And update itself accordingly (when ppp connection up/down, Vuze knows).

On linux, this can be done with setsockopt() SO_BINDTODEVICE. But that feature doesnt exist on Mac OSX. Otherwise, we might have done this:

dht_socket = socket(PF_INET, SOCK_DGRAM, 0);
char* devname = "ppp0";
setsockopt(dht_socket, SOL_SOCKET, SO_BINDTODEVICE, (char*)devname, sizeof(devname)) != 0
bind(dht_socket, ...);

Reference: http://stackoverflow.com/questions/1175108/specify-source-ip-address-for-tcp-socket-when-using-linux-network-device-aliases

Last edited 10 years ago by ben_murphy (previous) (diff)

comment:16 Changed 10 years ago by ben_murphy

And here appears a page of the Vuze source code...

http://svn.vuze.com/public/client/trunk/azureus2/src/com/aelitis/azureus/core/networkmanager/admin/impl/NetworkAdminImpl.java

It seems sensible to define a method that is from time-to-time called to check what is the current ip address. Then just before bind(); to retrieve what is the interface's last known IP address.

At line 238, checkNetworkInterfaces()

Last edited 10 years ago by ben_murphy (previous) (diff)

Changed 10 years ago by dreamcat4

Mac only supported so far... & doesnt work yet

comment:17 Changed 10 years ago by dreamcat4

Ahem, if anyone can help get this patch working... That'd be really great.

And we can work on adding support for other platforms.

0001-Work-in-progress.patch is based off r10715.

Last edited 10 years ago by dreamcat4 (previous) (diff)

comment:18 Changed 10 years ago by dreamcat4

  • Cc dreamcat4@… added
  • Version changed from 1.73 to 1.93+

comment:19 Changed 10 years ago by charles

  • Version changed from 1.93+ to 1.73

comment:20 Changed 10 years ago by dreamcat4

Hey, I was mistaken and 001 patch is actually working! Only OS-X at the moment. A timer updates the bind ip address every 10 seconds (can be adjusted).

I have set Transmission to point to various local network interfaces, and find its behaving as expected. If the interface's ip changes, transmission will notice the next timeout occurs and bring its connections down, then bring everything back up again, bind()'ing its sockets to the new ip. So that (the application-level part added to session.c) is all done. It could really help to have it code reviewed. Charles?

The Darwin-based source for mac calls sysctl(). It may need to be tweaked for the other bsd OSes. The linux source code is not in there yet. Its just a case of borrowing from the linux "ip" cmd (GNU v2 or higher license). The linux side is a lot more code to look through however.

I have written a file "network-interfaces-test.c" to help test this part. It just prints out a list of the interfaces and those information which can be compared to ifconfig -a or ip addr.

For both ipv4 and ipv6.

comment:21 Changed 10 years ago by dreamcat4

Good news!

Today it was possible to run net-interfaces-test (as per 001 patch) on FreeBSD 8.0 system. The result was that it worked just the same as for darwin / osx. So that same code covers all Darwin based, and Freebsd based OSes (including DragonflyBSD, etc). Without any modification.

Im not gonna test OpenBSD and netBSD b/c its too difficult to build the trunk version of transmission (with all its dependencies) on those OSes. But we expect they should be fine. This decision leave the BSD* code as "good enough", so we can move onto doing the linux support.

comment:22 Changed 10 years ago by Eszet

Charles asked me to have a look into this code. Without having it compiled, I'd say the infrastructure for detecting and reacting to an interface change is quite OK, but there is much stuff (supposedly from the ifconfig/ip code) which does seem to be just copied but does not add much value for the problem at hand. Copying mac addrs/ipv6 lifetimes around makes the code overly complex. The main problem is to have reliable code for enumerating the interface on all platforms. If Linux is the only platform for which the code is unavailable yet, it's not much that is missing.

If nobody else is working on the submitted patch atm, I may try to clean up the code a bit and add the Linux parts (which seems to be comparatively easy; there are example snippets on the web, only a couple dozen lines of code).

comment:23 Changed 10 years ago by dreamcat4

Hi Eszet!

1. Its great to hear that the part for checking the interface change is OK. For the code which retrieves the list of interfaces, those are kept a little seperate. Because perhaps those information (the list of network interfaces) can be used for other features in Transmission.

2. Im going to simplify the tr_addr4/6_info so its less duplication of the ip addresses. No problem.

3. For Linux patch, please dont start yet because I am just finishing it! My version for Linux will be ready very soon in about 1-2 days. Then you can please take those newer patch and move forward from there.

Changed 10 years ago by dreamcat4

This patch is based off r10715

comment:24 Changed 10 years ago by dreamcat4

Okay, My part is finished here and pleased to hand off to Eszet. Please use 2nd attachment "0001-patch-2313-dreamcat4-v2.patch".

BTW, A compile command for OSX in case you need to run the test program.

# osx: build in xcode the libtransmission, then run
gcc -D__TRANSMISSION__ -L../build/Debug -ltransmission -lcrypto -lcurl -framework Cocoa  net-interfaces-test.c -o net-interfaces-test && ./net-interfaces-test

Thank you.

comment:25 Changed 10 years ago by dreamcat4

  • Cc dreamcat4@… removed

comment:26 Changed 10 years ago by Eszet

I will check out your patch for review, however, I will only be able to verify compatibility with respect to my own development environment (Linux, that is). AFAICT, the new Linux-specific part looks straightforward.

comment:27 Changed 10 years ago by shaun.tancheff

Based on 0001-patch-2313-dreamcat4-v2.patch, modified tr_refreshPublicIp to be a little clearer. I am now able to force transmission traffic to be bound to the interface specified in bind-interface.

When the interface does not exist no traffic occurs. When ppp0 if-up then traffic restarts.

I followed this tutorial for creating a vpn / tunnel: http://ubuntuforums.org/archive/index.php/t-1472045.html I tested with http://checkmytorrentip.com/

On initial startup somewhere it appears that some traffic is not being driven through the bind-interface. After that initial error traffic channels properly.

The relevant bits of my configuration:

"bind-address-ipv4": "xxx.xxx.133.92", "bind-address-ipv6": "fd7f:54eb:9f51:be9a:1:2:3:4", "bind-interface": "ppp0", "dht-enabled": true, "lpd-enabled": false, "pex-enabled": false,

Hopefully this can start moving toward the trunk.

Changed 10 years ago by shaun.tancheff

ubuntu 10.04, patch based on launchpad transmission v 203, July 23, 2010. ~0 hrs GMT

comment:28 follow-up: Changed 10 years ago by dreamcat4

Hi Shaun, Your modification has a couple of problems:

  • Your baseline revision is different (probably newer), so the patch has pulled in some other stuff.
  • In the function tr_refreshPublicIp() of session.c...

Its a little more readable BUT:

  • Not comparing the new ip address to nullAddress anymore. That means that if the interface is a kind that sets the ip to 0.0.0.0 when down... it will cause the whole program to open up to the default interface. So then all torrent traffic would end up going out as if there were no bind interface set. Just remember there are many kinds of network interface drives, not just ppp0. Some of the more obscure ones will do this. So it would be a good idea to put back that particular check and not sacrifice the security for readability here (elsewhere yes).
  • After that, you are otherwise setting the ip address to either "1.2.3.4" or "::1". However on some local users system, theres nothing to stop them from assigning those IP addresses for their local interfaces. For example some guy might configure their local computer to 1.2.3.4 because they find that number easy to remember. So instead you should call unavailableBindAddress() as per the original v2 patch. That function is specifically to return a random ip address that is gauranteed to be unassigned on the local system. If you dont to that either - well then it also will leak all the torrent traffic too.

Hopefully with that commentary shaun you can better understand what its doing there. Thanks for testing my patch. Perhaps you can remember if you have modified any other functions. I'd be happy to just double-check through those too. Sorry but its hard to see from your patch because of all those other changes you pulled in.

comment:29 follow-up: Changed 10 years ago by dreamcat4

Oh, and it may be good idea to wait now for Charles to say when he is ready to accept this patch onto Trunk. Then we can know its the right time to rebase the patch onto the latest revsision.

comment:30 Changed 10 years ago by dreamcat4

  • Owner changed from jhujhiti to charles
  • Status changed from reopened to new

comment:31 in reply to: ↑ 29 Changed 10 years ago by charles

Replying to dreamcat4:

Oh, and it may be good idea to wait now for Charles to say when he is ready to accept this patch onto Trunk. Then we can know its the right time to rebase the patch onto the latest revsision.

I think I'd be ready to accept this into trunk whenever everyone involved is satisfied with the patch. I can review it for superficial things such as integration with other parts of Transmission, but I'm not the right person to weigh in on the actual interface binding code.

attachment vpn-bind-interface.patch

Would it be possible to base the diff off of trunk instead of the 2.0x branch?

Also, it would be best to do a "make distclean" before the diff so that there's less noise from diffs to configure, Makefile, Makefile.in, etc

Last edited 10 years ago by charles (previous) (diff)

comment:32 Changed 10 years ago by dreamcat4

Well I thought that the v2 patch was pretty allright. But then again I was the guy who wrote it.

Shaun also said that apparently there may be some leaked request during application initialization. I think this is because we have to wait until transmission has loaded the config settings. So we can check the bind_interface string. That happens in tr_sessionSet().

If we can move tr_sessionSet() to an earlier time in the initialization sequence, then we can check that bind_interface string earlier on an avoid making network calls on the default interface. There must be some network call(s) before the bit

evtimer_set( session->networkInterfacesTimer, networkInterfacesTimer, session ); networkInterfacesTimer( 0, 0, session );

So thats along the calling path:

tr_sessionInit() --> tr_sessionInitImpl() --> tr_sessionSet()

in libtransmission/session.c

comment:33 in reply to: ↑ 28 ; follow-up: Changed 10 years ago by shaun.tancheff

Replying to dreamcat4:

Hi dreamcat4,

Not comparing the new ip address to nullAddress anymore.

So that was the intent of the extra compare. I think you should do an explicit compare against TR_DEFAULT_BIND_ADDRESS_IPV4 / TR_DEFAULT_BIND_ADDRESS_IPV6.

However when I use unavailableBindAddress() as is I get a ton of peers connecting when my ppp0 is not connected. Ouch! CheckMyTorrentIP also reports activity from my public interface.

Mostly it looks like the IPs 0.99.0.99 and ::99:0:99 act like 0.0.0.0 and :: on ubuntu 10.04 x64.

For myself I am now seeding unavailableBindAddress() with 1.2.3.4 and fd7f:54eb:9f51:be9a:1:2:3:4, which while sorta valid ips are not used and have the desired effect here. I don't have any ipv6 here to test my research so my ipv6 seed could be a bad starting point.

Attaching a minimal set of changes on top of 0001-patch-2313-dreamcat4-v2.patch.

Changed 10 years ago by shaun.tancheff

comment:34 in reply to: ↑ 33 Changed 10 years ago by dreamcat4

Replying to shaun.tancheff:

So that was the intent of the extra compare. I think you should do an explicit compare against TR_DEFAULT_BIND_ADDRESS_IPV4 / TR_DEFAULT_BIND_ADDRESS_IPV6.

tr_refreshPublicIp()

Hi Shaun, Have had another look at tr_refreshPublicIp() from your latest patch. Its definately more readable. Thank you for making those improvements. I checked again and can't see any problems or issues with it.

However when I use unavailableBindAddress() as is I get a ton of peers connecting when my ppp0 is not connected. Ouch! CheckMyTorrentIP also reports activity from my public interface.

Mostly it looks like the IPs 0.99.0.99 and ::99:0:99 act like 0.0.0.0 and :: on ubuntu 10.04 x64.

For myself I am now seeding unavailableBindAddress() with 1.2.3.4 and fd7f:54eb:9f51:be9a:1:2:3:4, which while sorta valid ips are not used and have the desired effect here. I don't have any ipv6 here to test my research so my ipv6 seed could be a bad starting point.

The function has a loop limit and gives up after checking 100 ip addresses within the same ip block. Seeding from a different address range is a good idea Shaun and I have no problem with the change in your patch being a default for all the platforms.

We could improve things even further, i guess. For example by apply rand() to try up to N more ip addresses if the starting address was already occupied.

Attaching a minimal set of changes on top of 0001-patch-2313-dreamcat4-v2.patch.

comment:35 Changed 10 years ago by lacerus

Hi! Is this going to be in the official Transmission version? I need it to bind Transmission to my IPredator VPN interface without having to route all my traffic through there.

comment:36 Changed 10 years ago by dreamcat4

lacerus - We would like it to be. However nobody has had the time to spare to make these finishing touches.

See earlier comments for: 1) "move tr_sessionSet() to an earlier time in the initialization sequence" 2) "apply rand() to try up to N more ip addresses if the starting address was already occupied"

Point 1) is mandatory. Point 2) is optional.

The official status of this bug is "on hold". Until somebody submits a final patch with those changes, and its been peer-reviewed.

comment:37 Changed 10 years ago by lacerus

Thank you for the quick reply. I would offer to do it, but lack the skill of programming C, so I can only hope someone more capable than me has the same need and reads this. I offer a case of beer or the equivalent in Paypal dollars, too! Thanks!

comment:38 follow-up: Changed 10 years ago by fijam

I'm interested in this feature as well.

comment:39 in reply to: ↑ 38 Changed 10 years ago by Misery

Replying to fijam:

I'm interested in this feature as well.

So am I! Hopefully some skilled coder or dev will have a second look at this, so it could be adopted into the vanilla code.

Changed 10 years ago by ThornsArcana

Bind to an interface patch against 2.1x branch r11819

comment:41 Changed 10 years ago by ThornsArcana

I updated the old patches to the latest revisions in SVN -r11819. Also fixed a file handle leak in the Linux version. I am currently testing the trunk build on Ubuntu 10.10 and hoping for other people to report any issues. You may find #3836 helpful in building the trunk until libevent2 is commonly included in distributions. Currently testing SO_BINDTODEVICE when SO_BINDTODEVICE is defined.

Changed 10 years ago by ThornsArcana

Bind to an interface patch against trunk r11819. Use SO_BINDTODEVICE when possible.

comment:44 follow-up: Changed 10 years ago by jordan

ThornsArcana: your patching skill is impressive, but the patch itself has several characteristics that make me wary:

  • It's 1,600+ new lines for a feature that isn't likely to have many users
  • Since it's networking code, there are probably portability issues
  • There's not anyone on the dev team who lives & breathes this kind of low-level networking code, so future tickets filed against this patch are unlikely to get fixed quickly, if at all

This may be a naive question, but is there a well-maintained third party library out there that can do some of this heavy lifting, so that maintenance is Someone Else's Problem?

Last edited 10 years ago by jordan (previous) (diff)

comment:45 in reply to: ↑ 44 Changed 10 years ago by ThornsArcana

Replying to jordan:

ThornsArcana: your patching skill is impressive, but the patch itself has several characteristics that make me wary:

  • It's 1,600+ new lines for a feature that isn't likely to have many users

Granted the initial pickup is coming from VPN users. It is also useful to people who want to partition their usage across different mediums .. for example I may want to force my torrent to only use my least expensive network when I have a GSM modem and a Wireless or Ethernet connection. I also find it useful to push my torrents into my Ethernet and leave the Wireless free for the other people in the house.

  • Since it's networking code, there are probably portability issues

True. dreamcat4 did the OSX and initial Linux code and I have provided some minor additions to the Linux portion that I test.

  • There's not anyone on the dev team who lives & breathes this kind of low-level networking code, so future tickets filed against this patch are unlikely to get fixed quickly, if at all

This may be a naive question, but is there a well-maintained third party library out there that can do some of this heavy lifting, so that maintenance is Someone Else's Problem?

This patch is actually doing two things. The bulk of the patch is attempting to implement 'bind to a device' for platforms which don't have it. This done by extracting the address from the device and then binding to the address. Every N seconds (current 15) it polls to see if the address associated with the device has changed. The actual SO_BINDTODEVICE which I just added is really tiny and is really only useful for Linux users (IMO).

To be honest I have not spent time trying to re-factor to original 0001-patch-2313-dreamcat4-v2.patch, I just pulled it forward.

In the mean time I will try to find other options for enumerating devices and extracting ip addresses.

comment:46 Changed 10 years ago by dreamcat4

I'd just like to say to Jordan that its great that you have left the other parts for the non-linux OS's alone as clearly you arent set up to retest on other OSes. Someone else here said that it doesnt work (your improvement) for non-root privelidges? Jordan you might want to investigate if thats in fact actually the case.

It sounds like Jordans additions here are meant to make a fewer computational overhead for the linux platform. I have no strong preferences either way myself. So perhaps its better to leave me out of that and just continue to discuss with the others here who are interested.

Finally I'd also like to draw some attention back to the main problem which is that during the application initialization, the new hooks we added arent quite kicking in early enough. Somebody found a small leakage going out on their regular (default) net interface. Which then goes away after startup. Perhaps anyone here who can successfully detect that, would be kind enough to just move the calls we added up to an earlier point during the init() functions. As i never figured out how to do the testing for that.

Im not going to offer to review anybody else's patches until somebody claims to have fixed that issue, as it seems necessary requirement for closing this ticket.

comment:47 follow-up: Changed 10 years ago by jch

I am not positive that SO_BINDTODEVICE is always a macro.

It is.

POSIX says the following about the SO_* constants:

The <sys/socket.h> header shall define the following macros

(Now you might want to argue that SO_BINDTODEVICE is not specified by POSIX, and hence the above does not apply to it. I'd rather you didn't.)

--jch

comment:48 Changed 10 years ago by jch

The bulk of the patch is attempting to implement 'bind to a device' for platforms which don't have it.

I don't really have strong opinions here, since I think that functionality is useful, but shouldn't we just give up on those platforms? I don't think it's our job to be papering over missing functionality, we should ask our users to complain to their vendor.

I would therefore suggest that you should submit in a separate patch "The actual SO_BINDTODEVICE which I just added is really tiny and is really only useful for Linux users (IMO)."

--jch

comment:49 in reply to: ↑ 47 Changed 10 years ago by ijuxda

Replying to jch:

(Now you might want to argue that SO_BINDTODEVICE is not specified by POSIX, and hence the above does not apply to it. I'd rather you didn't.)

Why not? Is there something obvious I am missing? Since I am not an expert, would you be kind enough to point it out for me?

comment:50 Changed 10 years ago by jch

Are you seriously suggesting that there are implementations that implement only some of the SO_* constants as macros?

--jch

comment:51 Changed 10 years ago by ijuxda

You yourself said SO_BINDTODEVICE is not specified by posix, so why assume that every system that exists or will ever exist in the future would necessarily be the same as the systems you are familiar with? Why couldn't SO_BINDTODEVICE be part of an enum for example?

comment:52 Changed 10 years ago by jch

What I'm saying is that the 16 SO_* constants defined by POSIX must be macro.

A system on which SO_BINDTODEVICE is not a macro would be having some SO_* macros, and some others not. While technically possible, I find that somewhat unlikely.

--jch

Changed 10 years ago by ThornsArcana

Bind to an interface patch against trunk r11829. SO_BINDTODEVICE / getifaddrs.

comment:53 Changed 10 years ago by ThornsArcana

I hope this patch is little more palatable. However I re-wrote the net-interfaces code to use the getifaddrs. While not a strictly POSIX function it started in BSDi, exists in all OSX releases and has since been adopted into glibc. I do not know if its is in the official uClibc library or not (for those wanting to run torrents on their mobile phone and wireless router they may not be able to use this feature without some effort).

  • Added configure check for SO_BINDTODEVICE and --disable-bindtodevice for those that have and do not want to use it.
  • Added configure check for getifaddrs()
  • Changed polling to 3 seconds

The only known bug at this time is that when the non-default interface is dropped there is a window between the interface dropping and the next polling. In this window of time TCP connections can re-route to the default interface. For those with libnetlink (linux only afaik) we can listen for kernel events and drop when the interface drops shortening the window considerably.

comment:54 follow-up: Changed 10 years ago by ijuxda

Here are some observations on the latest patch:

  • In configure.ac:
    • Are the CXXFLAGS="${save_CXXFLAGS} -Wall -Werror" lines necessary?
    • The added checks in configure.ac should probably be moved closer to the other function/header checks and given a comment header (cf. posix_fadvise, va_copy).
    • There is trailing whitespace after "[{struct ifaddrs * pIfa;", and an extra period in the HAVE_GETIFADDRS description.
  • In tr_netBindSocketInterface:
    • tr_strlcpy is probably a better choice than strncat. In fact on compilation I get:
      In function 'strncat',
          inlined from 'tr_netBindSocketInterface' at net.c:261:
      /usr/include/bits/string3.h:153: error: call to __builtin___strncat_chk might overflow destination buffer
      
    • The setsockopt call now uses struct ifreq, but IFNAMSIZ is passed as the length parameter.
    • Is there any reason why the implementation was changed to use struct ifreq?
    • If a system has SO_BINDTODEVICE, does that imply that it has struct ifreq as well?
    • The backslashes in the tr_err call can be removed without changing the output.
    • sockerrno should be immediately saved after the setsockopt call, in case tr_err expands to or invokes functions which modify it. (I made this mistake in my implementation as well.)
  • In net-interfaces.c:
    • index should be avoided as a variable name since there is also a standard library function with that name.
    • C++ style comments should probably not be used. (Though there are a few other places in libtransmission where they appear, these seem like exceptions for the sake of convenience.)
    • There should not be tabs mixed in with spaces for indentation.
  • In tr-udp.c there are formatting changes in code that is otherwise unchanged by the patch. In general this should be avoided because it needlessly enlarges the patch.

There are probably more issues but I will not analyze any more until at least the major points are fixed and the style is improved.

On a more general design note, if getifaddrs can be used to learn the addresses corresponding to the interfaces, could the setsockopt SO_BINDTODEVICE call be avoided entirely and instead replaced by a regular bind() to the interface's address?

Last edited 10 years ago by jordan (previous) (diff)

Changed 10 years ago by ThornsArcana

Added libnetlink support.

comment:55 in reply to: ↑ 54 Changed 10 years ago by ThornsArcana

Replying to ijuxda:

Here are some observations on the latest patch:

  • In configure.ac:
    • Are the CXXFLAGS="${save_CXXFLAGS} -Wall -Werror" lines necessary?

It's a configure test for 'does this compile?'. So yes.

  • The added checks in configure.ac should probably be moved closer to the other function/header checks and given a comment header (cf. posix_fadvise, va_copy).
  • There is trailing whitespace after "[{struct ifaddrs * pIfa;", and an extra period in the HAVE_GETIFADDRS description.
  • In tr_netBindSocketInterface:
    • tr_strlcpy is probably a better choice than strncat. In fact on compilation I get:
      In function 'strncat',
          inlined from 'tr_netBindSocketInterface' at net.c:261:
      /usr/include/bits/string3.h:153: error: call to __builtin___strncat_chk might overflow destination buffer
      

Using tr_strlcpy now.

  • The setsockopt call now uses struct ifreq, but IFNAMSIZ is passed as the length parameter.
  • Is there any reason why the implementation was changed to use struct ifreq?
  • If a system has SO_BINDTODEVICE, does that imply that it has struct ifreq as well?

Just because I thought you would like it better, and struct ifreq is in Linux, BSD and OSX. So while it may not be in the current revision of POSIX it is reasonable to expect it in a future one. Remember standards codify current practice, they don't lead the industry.

  • The backslashes in the tr_err call can be removed without changing the output.

True but that would be less correct.

  • sockerrno should be immediately saved after the setsockopt call, in case tr_err expands to or invokes functions which modify it. (I made this mistake in my implementation as well.)

It isn't really much of a mistake if you look at the macro pretending to be a function call, it acts likes a function call, why would you assume that variables being pushed onto the stack aren't? Anyway I made the suggested change so as to be a good example to others.

  • In net-interfaces.c:
    • index should be avoided as a variable name since there is also a standard library function with that name.

man 3 index --

4.3BSD; marked as LEGACY in POSIX.1-2001. POSIX.1-2008 removes the specifications of index() and rindex(), recommending strchr(3) and strrchr(3) instead.

  • C++ style comments should probably not be used. (Though there are a few other places in libtransmission where they appear, these seem like exceptions for the sake of convenience.)

Funny even my deep embedded stuff has shifted to prefer the C++ style in the last few years. I avoided C++ style comments for a long time, now it's hard to find shipping compilers that didn't support it.

  • There should not be tabs mixed in with spaces for indentation.

Agreed. Found and fixed.

  • In tr-udp.c there are formatting changes in code that is otherwise unchanged by the patch. In general this should be avoided because it needlessly enlarges the patch.

Removed the indentation fix.

There are probably more issues but I will not analyze any more until at least the major points are fixed and the style is improved.

On a more general design note, if getifaddrs can be used to learn the addresses corresponding to the interfaces, could the setsockopt SO_BINDTODEVICE call be avoided entirely and instead replaced by a regular bind() to the interface's address?

Why remove an available layer of security?

Last edited 10 years ago by jordan (previous) (diff)

comment:56 Changed 10 years ago by jordan

ThornsArcana,

To reiterate what I said in comment:44, the deciding factor will be how small and simple the patch can be. Big, complicated code is a bitch to maintain. Transmission doesn't need to implement "bind to device" for platforms that don't support it. Transmission doesn't need to be all-singing and all-dancing, and doesn't need every nice-to-have-but-not-essential feature.

Why am I saying this? Because there's been a lot of talk in the time since comment:44, which might wrongly have given you false hope. I don't want you to be disappointed if your patch isn't used, because then you might be less likely to submit other patches... ;)

Last edited 10 years ago by jordan (previous) (diff)

comment:57 Changed 10 years ago by ThornsArcana

Jordan,

As it sits the patch is complete. I am not planning to make any further changes. I did it because I wanted it and I use. I posted the patch because other people may find it useful and I certainly am not the first one to want it. Personally I won't run a torrent client without this patch when I am in the US.

I believe that I have removed all the low level networking in favor of the medium level variants getifaddrs() and modern libraries libnetlink. It's also hard to argue that setsockopt() is not well understood.

I also feel that this last version is quite reasonable in size.

  • 300 lines to dynamically change the default bound ip address (session.c).
  • 180 lines digesting getifaddrs() for use by above (net-interfaces.c)
  • libnetlink 50 lines (session.c).
  • SO_BINDTODEVICE 40 lines.
  • 80 lines to configure.ac for guessing at SO_BINDTODEVICE, getifaddrs() and libnetlink

If you would be interested in including this patch and have specific concerns please let me know what I can do. A little work now will save merge conflicts in the future.

With that said I am open to help anyone who asks.

comment:58 follow-up: Changed 10 years ago by dreamcat4

Ah! I can see whats happened here...

The ticket DESCRIPTION says "would be nice to implement bind to interface AKA SO_BINDTODEVICE..." Thorns must have been taking this description a little too literally and taken that far too literally. AKA means - "like* and not literally to do exactly the same. This was added on top of my v2 patch (thus complicating it somewhat).

Thorns - I never actually explained my reasons for NOT using SO_BINDTODEVICE. But they are pretty obvious. Reason this: 1) SO_BINDTODEVICE is not a multi-platform solution. 2) It would be rather "elitist" or exclusionary to implement ONLY SO_BINDTODEVICE in the patch as suggested in the initial description of this ticket. 3) My alternative with binding to the IP address IS multiplatform (for all unixes so no win32 sorry). And it makes for the simplest / smallest possible patch (important!). Owning some non-linux system myself (OSX) and wanting others to be able to use my patch - that was the most sensible choice.

The main goal is obviously stated by jordan here - and complicating a patch (without due cause) is to be avoided. Because the transmission project maintainers wont accept it and of course it must be incredibly frustrating to discover that so much of your efforts are wasted.

But the good news is that Thorns your "bind-to-interface-r11819-2.1x_branch.patch" doesnt have SO_BINDTODEVICE in it. So not all of that work is wasted - as the revision updates substantially (from the much older now v2 patch). And thats pretty useful.

Replying to ijuxda:

Here are some observations on the latest patch: On a more general design note, if getifaddrs can be used to learn the addresses corresponding to the interfaces, could the setsockopt SO_BINDTODEVICE call be avoided entirely and instead replaced by a regular bind() to the interface's address?

That was mostly how things worked in the dreamcat-v2 patch (although not using getifaddrs).

Last edited 10 years ago by dreamcat4 (previous) (diff)

comment:59 Changed 10 years ago by dreamcat4

Oh I had not seen this last comment...

Well Thorns thats a lot less bloated than I was lead to assume. It seems that in several areas the last patch is quite reasonable in terms of the line counts / complexity. Givens Thorns latest comments I would support Thorns final patch as over what was in the v2 patch.

It would be nice to be sure it still works on Mac OS-X.

Last edited 10 years ago by dreamcat4 (previous) (diff)

comment:60 in reply to: ↑ 58 Changed 10 years ago by ThornsArcana

I would be really curious to know if doesn't work. I don't have a OS-X environment but according to the documentation it should be fine from 10.3 to current.

Also it would be nice to know what OS-X and the BSDs recommend as a libnetlink equivalent. I get a warm fuzzy when all my connections drop hard the instant the kernel drops the interface.

comment:61 follow-up: Changed 10 years ago by dreamcat4

Well i compiled thorn's latest patch for OSX. And just ran the really simple net-interfaces-test.c. I noticed thorns that you updated this file and ask that you confirm its still working on your system with that r11870 patch.

tr_net_interfaces() returns NULL - so its effectively broken on OSX until that can be fixed. Thorns - the original v2 code you replaced wasnt pretty to look at because it was from Berkely UNIX ifonfig and therefore hadnt been touched since about 1995. Reasion: reliable and known to work as its actually the same code that runs when you type $ ifconfig -a.

Here is my guess:

BSD/Mach kernel network calls are all through sysctl. So although some public linux networking calls might exist on BSD they arent connected to sysctl inside the kernel and therefore return nothing on the BSD OSes.

comment:62 Changed 10 years ago by dreamcat4

Thorns - i had no idea what netlink was. For the benefit of others - its a userland-kernal IPC messaging system. Fairly new addition to the linux kernel. There is no direct low-level equivalent on other oses. You want it for the C callback (so we can refresh) as soon as the routing table changes.

Actually Mac OS-X this kind of functionality diverges a lot from the other BSDs. Here is the briefest explanation i can find:

http://www.afp548.com/article.php?story=20041015131913324

Apple implement configd above the sysctl layer with a launchd system service. (so thats a root-level process). So I dont know if you can get direct userland notification at C-api level like you can with linux/libnetlink.

Normally on Mac, the developer links their binary to SystemConfiguration?.framework. And uses CF (CoreFoundation?) / SC api calls to register for the necessary notification. Here is an example:

http://growl.info/hg/growl/file/2e787f50d3c7/Extras/HardwareGrowler/NetworkNotifier.m#l232

I am still investigating if above is really the best method for libtransmission.a

comment:63 in reply to: ↑ 61 ; follow-up: Changed 10 years ago by ThornsArcana

Replying to dreamcat4:

Well i compiled thorn's latest patch for OSX. And just ran the really simple net-interfaces-test.c. I noticed thorns that you updated this file and ask that you confirm its still working on your system with that r11870 patch.

Yes it works here. For sanity check that HAVE_GETIFADDRS is defined in your build. I added a configure.ac test but I don't know if that gets picked up in your OSX build. Another sanity check is to grab this: http://kai.tancheff.com/code/iflist.c and see if that works on OSX.

comment:64 in reply to: ↑ 63 Changed 10 years ago by dreamcat4

Replying to ThornsArcana:

For sanity check that HAVE_GETIFADDRS is defined in your build. I added a configure.ac test but I don't know if that gets picked up in your OSX build.

Thanks for pointing that out as I cant find those autoconf defines anywhere in the XCode build. Im happy to switch back over to gnu toolchain. Although I must admit its pretty concerning if XCode doesnt generate those. Something for discussion on IRC i guess.

Another sanity check is to grab this: http://kai.tancheff.com/code/iflist.c and see if that works on OSX.

This example works on osx, if you include #include <netinet/in.h> before the line #include <net/if.h>. (which is already like that in your patch so it should be fine). So things are looking good.

Changed 10 years ago by dreamcat4

Reworked the Mac OS-X Support

Changed 10 years ago by dreamcat4

Where to enable this feature on mac os x

Changed 10 years ago by dreamcat4

Fixed linking to System Configuration Framework. Mac os x.

comment:66 follow-up: Changed 10 years ago by dreamcat4

The patch "r11870-thorns-v2.21"

  • Tweaked XCode project file for Thorns HAVE_GETIFADDRS. Indeed getifaddrs() works on OS-X :)
  • Added functionality like the libnetlink for Mac OS-X (with the equivalent Apple APIs).
  • Improved the test program "net-interfaces-test.c". Return -1 when no network interfaces.
  • Minor cleanup - replace p_err() with tr_err()
  • (v2.21) Fixed linking to System Configuration Framework

Various files for Mac OS-X available for a limited time at the links below.

http://dl.dropbox.com/u/588496/Transmission-Ticket%232312%20BindInterface%20Setting.png http://dl.dropbox.com/u/588496/Transmission-v1.93-r10715-dreamcat-v2-patched.zip http://dl.dropbox.com/u/588496/Transmission-v2.21-r11870-thorns-v2.21-patched.zip

Note: Since Transmission v2.12/r11358 theres no Proxy setting anymore (#3688).

comment:67 Changed 10 years ago by atm999

  • Cc atm999@… added

Many thanks to all who worked on this patch. I'm not a programmer, but it looks like you managed to solve this, so what are the chances of this getting incorporated in the next official version of transmission(-daemon)? Thanks again for your hard work!

comment:68 Changed 9 years ago by Misery

Would it be possible to apply this patch to the latest 2.31 release, more specifically to transmission-daemon 2.31?

comment:69 Changed 9 years ago by astn

  • Cc abaustin@… added

I'm echoing the comments above. If this patch is working, can we integrate it into the release? Alternatively, could someone post a latest build with this patch applied (not my preference, but I'm not a coder so I take what I can get).

comment:70 Changed 9 years ago by jordan

astn, please see comment:44 and comment:56

comment:71 follow-up: Changed 9 years ago by karltc

I worked hard to get this patch worked into the current version of transmission. Can someone please post a link where I can download transmission for Mac pre-patched?

comment:72 Changed 9 years ago by platina5

Last comment is confusing... so excuse my confusion but, has it been integrated into the release or not? If not -- here is one more vote to get this into transmission. I have followed this thread every couple of weeks and i would think that a bind-to-address option would be a welcomed feature. As time progresses it will be on the increase, I'm sure. It certainly is a welcomed feature by me. I'm using Linux, btw.

comment:73 Changed 9 years ago by platina5

  • Cc aenima@… added

comment:74 in reply to: ↑ 71 ; follow-up: Changed 9 years ago by x190

Replying to karltc:

I worked hard to get this patch worked into the current version of transmission. Can someone please post a link where I can download transmission for Mac pre-patched?

I think you would need to select a file hosting site yourself and then post the link here and maybe also in the forum. I'd be interested in obtaining a copy if you decided to do that. Thanks!

comment:75 in reply to: ↑ 74 Changed 9 years ago by karltc

Replying to x190:

Replying to karltc:

I worked hard to get this patch worked into the current version of transmission. Can someone please post a link where I can download transmission for Mac pre-patched?

I think you would need to select a file hosting site yourself and then post the link here and maybe also in the forum. I'd be interested in obtaining a copy if you decided to do that. Thanks!

I'm sorry if my comment was a bit confusing. I meant that I tried hard to get the patch to work BUT I was unsuccessful. I was looking to see if someone else could compile it and throw it up on a server. The compiled version would be great but I did find a work around. I now have a dedicated VPN where the interface IP doesn't change allowing me to bind to the IP which is already built into transmission. Astrill has a great deal on dedicated private VPN's ;)

comment:76 follow-up: Changed 9 years ago by ThornsArcana

I put an updated patch here.

http://tancheff.aeonazure.com/thorns/bind-to-interface-r12779-trunk.patch

This includes a fix for 'too many open files' by maintaining a list of open peers with activity. Peers with no activity for > 120s get culled when the Maximum peers overall limit is reached. NOTE: you can now set this value to your ulimit maximum as the used limit is 100 file handles less the value than the value specified in the UI.

See libtransmission/fdlimit.c for details.

comment:77 Changed 9 years ago by x190

Thanks! :-)

comment:78 Changed 9 years ago by gene_wood

  • Cc trac.transmissionbt.com@… added

comment:79 Changed 9 years ago by astn

Using current svn, I tried to build in Xcode 4.2 (OS X 10.7.2) using ThornsArcana?'s patch from comment:77, and getting 8 build errors. Below are the two unique errors (aside from the line numbers). The struct sockaddr shows up 6 times, struct sockaddr_storage shows twice.

net/if.h:300:19: error: field has incomplete type 'struct sockaddr' [3]
net/if.h:431:26: error: field has incomplete type 'struct sockaddr_storage' [3]

Since this isn't going to be integrated into the release, I'm content to try to build this myself, but I am well over my head. Any help or advice would be appreciated. Thanks.

comment:80 Changed 9 years ago by roeme

  • Version changed from 1.73 to 2.42+

+1 This feature would be indeed useful for some users.

Note that Vuze does it the "same" way; reading out what IPs are available on a particular interface, and then binding to all of them. So, this seems to be the right way to go to be multiplatform.

I'm currently familiarizing myself with the patch and would volunteer to help with future issues; should they arise. jordan; would this resolve the final issue you had with this patch? (the others now being moot. Or aren't they?).

comment:81 Changed 9 years ago by livings124

  • Version changed from 2.42+ to 1.73

comment:82 Changed 9 years ago by Gallomimia

I'll have to admit I was surprized and dismayed to find that this feature was not already supported. I would like to throw my hat in for a request for this one to be added to the general release. For the same reasons: VPN

I'd also like to comment that if a user's OS does not support the SO_BINDTODEVICE calls as you are discussing, they clearly don't need a program that will use a work around. Complain to your vendor? Uh, drop that vendor. Simple code for simple feature. If you have a 1600 line patch that adds support for any OS, well maybe there's a contest you can win somewhere. I'll agree that it's not necessary in this product.

comment:83 Changed 9 years ago by forty

Hello,

For the other people who may need this feature, here is the workaround I am using : a small shell script

#!/bin/sh
sed -i "s/\"bind-address-ipv4\":.*\$/\"bind-address-ipv4\": \"$(ifconfig tun0 | egrep -o 'addr:[^ ]* ' | cut -d':' -f2 | sed 's/ //')\",/" /etc/transmission-daemon/settings.json
invoke-rc.d transmission-daemon reload

I currently run it manually when needed (when my ip changes) but you can probably put it in your contab (or maybe do something more clever to run it only when needed by watching some logs for example). You will probably need to adapt it a little bit (for example the path to the config file may be different for you)

Hope that helps, and that the feature will be implemented soon. If the problem is only portability (if I understand correctly the previous discussion, I have no knowledge of this kind of problems), I suggest that you call this property "linux-bind-interface-ipv4:" so it will be a Linux only option for example.

comment:84 follow-up: Changed 9 years ago by kanka

Hello,

Another workaround:

  • Add an interface lo:1 and assign it to a local ip (e.g. 192.168.0.1)
  • NAT this local ip with the VPN interface (e.g. tun0)
  • Bind transmission to 192.168.0.1

This way, there is no need to update the bind ip for transmission-daemon

Details here (in french): http://tech.kanka.ch/?p=153

comment:86 Changed 8 years ago by cfpp2p

Updated patch:

Thank you for keeping this patch current :)

much appreciated...

comment:87 Changed 8 years ago by udo

When we are happily patching the ipv4 binding, can we please have a look at why THAT stops working when we bind an explicit ipv6? See ticket 5071 for details. This is an issue that is easily reproduced by choosing ::1 as ipv6 instead of ::.

comment:88 Changed 8 years ago by mattman

This is a sorely needed feature for me. I need Transmission to use my VPN interface, and all other traffic to use my normal interface, so I am disappointed that this feature is not available. +1 to get this working

comment:89 Changed 8 years ago by karltc

If you're on Mac and using viscosity, you could make an Automator program to get the interface IP and bind it in the preference file everytime. That's what I've done

comment:90 Changed 8 years ago by mattman

I'm not using Viscosity, but I did just play around with Transmission trying to get it to bind to my VPN interface, and I couldn't get it working. Would you mind showing me how you've got the IP, and then importantly how you've managed to get Transmission to bind?

comment:91 follow-up: Changed 8 years ago by mattman

BTW. I am happy to use Viscosity if it could solve this problem. It seems ridiculous that I have to either route all traffic through my VPN, or no traffic through the VPN. I should be able to route all torrent traffic through my VPN and leave all other traffic as normal somehow. Thanks in advance for any advice, I'm sure it will help others too.

comment:92 in reply to: ↑ 84 Changed 8 years ago by x190

Replying to kanka:

Hello,

Another workaround:

  • Add an interface lo:1 and assign it to a local ip (e.g. 192.168.0.1)
  • NAT this local ip with the VPN interface (e.g. tun0)
  • Bind transmission to 192.168.0.1

This way, there is no need to update the bind ip for transmission-daemon

Details here (in french):

http://tech.kanka.ch/?p=153

kanka, do you know of a tutorial for a Mac? Have you found your method successful for routing only Transmission's traffic over your VPN while allowing other traffic to use the normal network configuration?

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

comment:93 in reply to: ↑ 66 ; follow-up: Changed 8 years ago by x190

The patch "r11870-thorns-v2.21"

http://dl.dropbox.com/u/588496/Transmission-v2.21-r11870-thorns-v2.21-patched.zip

thorns, thank you for making this patch available. I have successfully used your patch with my version of Transmission. As advertised, all connections are dropped immediately when the interface goes down. Transmission also binds correctly to the new IP when the connection is restored, however, it seems to need a restart and then a DHT 'toggle' to get UDP trackers and the DHT (udp) network working again. It would be great if that could be done automatically.

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

comment:94 Changed 8 years ago by sirkingchase

How are you guys routing two interfaces? Iev followed every guide I can find on the internet, non of them work. Its driving me crazy! If my wlan is on the same subset as my eth0 (i.e. 192.168.1.*) itll return all traffic sent through wlan0 back to eth0. If my wlan0 is not on the same sub set (i.e. 192.168.2.*) it wont work at all.

Thanks for the patch BTW. I sure wish they would find us worthy enough to be put in the source. I think we would have a better chance if it was something that you could configure when building and it would normally be disabled by default ( so we wont burden these guys with a new feature). Ex. --enable-bind-to-interface

I dont see a reason they could be opposed to that, its a compromise, its in the source SVN but gets compiled out by default, everyone wins.

comment:95 in reply to: ↑ 91 Changed 8 years ago by karltc

Replying to mattman:

BTW. I am happy to use Viscosity if it could solve this problem. It seems ridiculous that I have to either route all traffic through my VPN, or no traffic through the VPN. I should be able to route all torrent traffic through my VPN and leave all other traffic as normal somehow. Thanks in advance for any advice, I'm sure it will help others too.

There could be a more efficient way of doing this but, if you download the following file and open it in automator, just replace where I inserted '*' in the following locations.

  1. Step 1, replace the asterisks with whatever your connection is named in Visocity
  2. Step 7, replace the asterisks with whatever your shortname is in Mac

Should be good to run. If it works, save it and next time, it'll be ran as an application.

https://mega.co.nz/#!jQBwVKRD!HeocMEV5qMBfpw4mW3LM2RRwio8ejawUAMXUjlsLIYw

comment:96 Changed 8 years ago by gene_wood

Just to keep in mind, until this ticket gets resolved there is a pretty simple workaround using the --bind-address-ipv4 argument. Here is the code to do this :

https://gist.github.com/gene1wood/5040735

comment:98 Changed 8 years ago by platina5

I'd like to add another way. If using Linux, one could simply use a Linux container (LXC) which can have its own networking stack. It's lightweight virtualization and, because this ticket is so old, that's what I'm currently doing.

comment:99 in reply to: ↑ 93 Changed 8 years ago by jhnielson

Replying to x190:

The patch "r11870-thorns-v2.21"

http://dl.dropbox.com/u/588496/Transmission-v2.21-r11870-thorns-v2.21-patched.zip

thorns, thank you for making this patch available. I have successfully used your patch with my version of Transmission. As advertised, all connections are dropped immediately when the interface goes down. Transmission also binds correctly to the new IP when the connection is restored, however, it seems to need a restart and then a DHT 'toggle' to get UDP trackers and the DHT (udp) network working again. It would be great if that could be done automatically.

Do you mind helping me with how to apply this to the build. I'm new to working with Transmission in xCode. Should I be editing the actual session.c file or should I be adding this as a stand-alone file?

Thanks for any help you can provide.

comment:100 follow-up: Changed 8 years ago by x190

Just click on the dropbox link which will give you a pre-built app. You just need to add a BindInterface? line to your .plist file with the appropriate entry, such as ppp0 or tun0, using a Property List Editor or Terminal. Please use Transmission's forum if you have further questions.

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

comment:101 in reply to: ↑ 100 Changed 8 years ago by jhnielson

Replying to x190:

Just click on the dropbox link which will give you a pre-built app. You just need to add a BindInterface? line to your .plist file with the appropriate entry, such as ppp0 or tun0, using a Property List Editor or Terminal. Please use Transmission's forum if you have further questions.

Thanks for the reply. But the Dropbox links to an app based on 2.21 not 2.77 and I didn't know if there were new features missing in 2.77 that would be missing in this app.

comment:102 Changed 8 years ago by x190

The latest patch is for r13619, as per comment:85.

  • In Terminal, svn co svn://svn.transmissionbt.com/Transmission/trunk -r 13619
  • Put the patch file in the just downloaded folder and cd in Terminal to that directory.
  • In Terminal, patch -p1 < ./<name of patch file>.patch.
  • Build in Xcode using the included .xcodeproj.

Add a BindInterface? line to your .plist file with the appropriate entry, such as ppp0 or tun0, using a Property List Editor or Terminal. Please use Transmission's forum if you have further questions.


comment:95 also provides a very good solution for using the BindAddressIPv4 option. Or simply use the BindAddressIPv4 option manually for each session. These options will work with the latest Transmission version.

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

comment:103 Changed 7 years ago by mathewparet

Guys a little help here. I am not good with SVN. I have v2.82 (14160) of transmission installed. Could you help me in applying this patch to my installation?

Also is the patch targeted to production any time soon?

comment:104 Changed 7 years ago by x190

"Also is the patch targeted to production any time soon?"

No. This is a third-party patch that you are welcome to test, and I for one use it regularly.

Your choices are outlined above, mainly in comment:99 and comment:102. Details and requirements are given in those comments.

comment:105 Changed 7 years ago by mathewparet

  • Cc mathewparet@… added
  • Component changed from libtransmission to Transmission
  • Milestone changed from None Set to 2.90

comment:106 Changed 7 years ago by livings124

  • Milestone changed from 2.90 to None Set

Don't set milestones for us.

comment:107 Changed 7 years ago by ThornsArcana

Finally posting an updated patch. I have been running against -r14215 using OpenVPN with split route scheme for a while and it is very stable and very fast.

I also have tested using a very large file handle maximums

(See: http://www.cyberciti.biz/faq/linux-increase-the-maximum-number-of-open-files/)

Eg: 100000 system, 65000 user hard, 60000 user soft.

This allows pushing the network peer limits.

Also added the UI for setting which interface to force traffic down.

For OpenVPN on Linux this will most often be set to tun0 For PPTP on Linux this will most often be set to ppp0

Instructions: ​http://tancheff.aeonazure.com/thorns/SETUP.txt Patch for iPredator OpenVPN config: ​http://tancheff.aeonazure.com/thorns/ipredator-add-route-up.patch My route-up script: ​http://tancheff.aeonazure.com/thorns/route-up.sh Reference to my rt_tables: http://tancheff.aeonazure.com/thorns/rt_tables

Patch against -r14215: http://tancheff.aeonazure.com/thorns/bind-to-interface-r14215-trunk.patch Patch against -r14243: ​http://tancheff.aeonazure.com/thorns/bind-to-interface-r14243-trunk.patch

NOTE: I just updated my SVN to 14243 and rebuilt. First impression looks good, patch included.

comment:108 Changed 7 years ago by syzygy

  • Cc dmnd@… added

comment:109 Changed 7 years ago by flirc

@ThornsArcana?

I complied the latest patch 14243 and am happy to share this.One thing I don't see is the UI for setting the interface, where is this found?

Also, if no UI exists, where does this setting live? Comments refer to a plist file, but the head of this thread lists a json file. Thanks so much.

comment:110 follow-up: Changed 7 years ago by flirc

I've compiled this and wanted to share with others to save people time and the headache. There was quite a bit of work to get it to compile. This is based on the latest patch by ThornsArcana?

There is a compile error about a struct mentioned above, that's because #include <sys/socket.h> needs to be included before the #include <net/if.h>

Also, net-interfaces.c needs to be added to the list to compile libtransmission. There are a handful of other libs that need to be installed.

Here is the App: http://downloads.flirc.tv/misc/Transmission/Transmission.2.82+.r14243.patch-2313.dmg

Now, if someone can return the favor with some instructions on where to add the interface line. The original post recommends a json file, which doesn't exist, and others mention the plist file. But which one? I'll follow up once/if I figure it out.

comment:111 in reply to: ↑ 110 Changed 7 years ago by x190

Now, if someone can return the favor with some instructions on where to add the interface line. The original post recommends a json file, which doesn't exist, and others mention the plist file. But which one? I'll follow up once/if I figure it out.

For the Mac Client, open ~/Library/Preferences?/org.m0k.transmission.plist with a Property List Editor and add BindInterface? (String). For the daemon, add "bind-interface": "", to your settings.json.

comment:112 Changed 7 years ago by flirc

This doesn't work: ~/Library/Preferences??/org.m0k.transmission.plist

The only thing I found to work is:

/Applications/Transmission?.app/Contents/Resources/Default.plist

And your instructions and string only work for the version in the dropbox, not the latest. The patch is different.

I just tried r14243 and the patch against that. Same thing. Doesn't work.

comment:113 follow-up: Changed 7 years ago by flirc

Follow-up. I played for hours with the patch and version -r14243. (the compiled version I posted on my website).

It doesn't work. I tried modifying the playlist with the appropriate strings and the enable boolean (after reading the source), and that did nothing. It wouldn't use the interface. To make sure I wasn't losing my mind, I compiled the interface into the default source and disabled getting the interface name and boolean flag from the plist. Torrents would not transfer....still broken.

I used the compiled version in the dropbox link provided, looked at the patch, added the string in that patch (which is different in the latest one by Thomas), and that one worked fine. However, two big problems with the version in the dropbox link:

  1. when the interface dies, so does the connection. That's not the problem. The problem is that when the interface goes back up, the torrent doesn't restart. You need to quit the app and run it again.
  1. The version in the dropbox link is so old, magnet links don't work.

I'm happy to compile this and share to help others, however, I'll need a bit of help to figure this out. I unfortunately don't have the time to re-write the patch or debug it. Any help from ThornsArcana? or another would be appreciated.

comment:114 Changed 7 years ago by flirc

This doesn't work: ~/Library/Preferences??/org.m0k.transmission.plist

The only thing I found to work is:

/Applications/Transmission?.app/Contents/Resources/Default.plist

And your instructions and string only work for the version in the dropbox, not the latest. The patch is different.

I just tried r14243 and the patch against that. Same thing. Doesn't work.

comment:115 in reply to: ↑ 113 Changed 7 years ago by x190

Replying to flirc:

I used the compiled version in the dropbox link provided, looked at the patch, added the string in that patch (which is different in the latest one by Thomas), and that one worked fine. However, two big problems with the version in the dropbox link:

  1. when the interface dies, so does the connection. That's not the problem. The problem is that when the interface goes back up, the torrent doesn't restart. You need to quit the app and run it again.

Yes, that problem has always been there. I have made numerous hacks to my personal copy of Transmission, which is based on 2.21+, to work around this problem, which I could try to document for you, if you are interested. Please make a post in the Mac Support section of the forum, if you are.

  1. The version in the dropbox link is so old, magnet links don't work.

Not sure what you are seeing here as I have no problems whatsoever with magnet links. EDIT: You are right. Seems I have made updates in many areas to fix this and other issues.

If ThornsArcana? could provide a recent build, that would be great.

Last edited 7 years ago by x190 (previous) (diff)

comment:116 Changed 7 years ago by flakespancakes

Hey guys. Happy to help with this in whatever way I can, but I'm very new to Transmission so not sure what I can do.

What's the normal procedure for getting a change merged into Transmission and is there a specific reason why that hasn't happened yet in this case?

comment:117 Changed 6 years ago by coeurnoir

Still waiting eagerly for this. Is there an updated version I can use from ThornsArcana? or others? Thanks!

comment:118 Changed 6 years ago by karltc

I have created/updated an application (made in Automator) for mac Transmission BindIP.

This checks for the IP on the tun0 interface and sets the BindIP to the tun0 interface IP. Run this before starting transmission. Tun0 is the interface of my VPN, this may vary, but you can open the Application in Automator and change it to fit your needs.

comment:119 Changed 6 years ago by gene_wood

And here is a workaround for Linux (Specifically Red Hat Enterprise Linux and derivatives like RHEL, CentOS, Scientific Linux) : /etc/sysconfig/transmission-daemon

This gist is for a /etc/sysconfig/transmission-daemon file which you can use to bind to an interface.

Save it as /etc/sysconfig/transmission-daemon and change the "INTERFACE=ppp0" to be whatever your interface name is.

In the event that the interface you wish to bind to is not available (for example if you wish to bind to a VPN interface and the VPN is down), this binds the daemon to the loopback interface.

comment:120 Changed 6 years ago by flirc

I gave up on this. I did the patches, got everything compiled, it was a pain in the butt. If you ever lost VPN and the VPN came back, you would need to restart the app.

I gave up, I don't want to deal with a workaround as suggested by others. I find them inconsistent and need attention and baby sitting.

I ended up installing vuze, they have this built in. They have an option to bind to a specific address where you can enter the VPN interface. It's a terrible app in comparison, but at least it works.

comment:121 Changed 6 years ago by walapu

I finally just decided to create a stand alone Mac OS X Application to deal with this problem.

Last edited 19 months ago by walapu (previous) (diff)

comment:122 Changed 6 years ago by sloany

  • Cc jisloane@… added

comment:123 Changed 6 years ago by paralyys

What Walapu did is great, unfortunately I'm still on OSX 10.8.5, so it doesn't work. So vote for integration in Transmission.

comment:124 Changed 6 years ago by jcviau

Im not on MAC OS, looking for a feature integrated in Transmission.

/vote for this or "Connect through VPN Only" Option.

comment:125 Changed 6 years ago by platina5

  • Cc aenima@… removed

comment:126 Changed 5 years ago by fletom

I'd love to see this natively in Transmission. Plenty of ISPs mess with or monitor torrent traffic so using a VPN is really important for some users.

Many thanks to everyone who's made progress on this so far!

Changed 5 years ago by marlemion

Patch adopted to apply to and compile with 2.90

comment:127 Changed 5 years ago by marlemion

Hi guys,

I have made this patch apply to and compile with the sources of 2.90 (gcc 4.9). However, even if transmission-daemon starts up and is accessible, it somehow seems to behave odd. I cannot add torrents from links and systemd keeps restarting the service, even though it runs without quitting itself or crashing from the command line.

Maybe some experienced guy can have a look into the code? The patch is waiting for being reviewed by the moderator, however, it can also be looked at beforehand here: http://www.filedropper.com/transmission-netdev

Changed 5 years ago by ThornsArcana

Bind to interface against SVN 14706.

Note: See TracTickets for help on using tickets.