PRB: net.outgoing_ip doesn't appear to work / bind correctly + example

[dbczero]

First off, uTorrent is one of the best programs I've ever run across. It truly is old-school hacker.

I have a pretty complicated configuration: Dual Internet connections (8mpbs cable + 7mbps dsl) bound together with a hardware load balancer (xincom502). The load balancer is capable of taking a given LAN IP and binding it to a single WAN connection. Using this, I had planned to put two network cards in my PC and bind the IP of one of them to a single WAN port. This NIC would be set as non-default (high metric) in windows and I would run uTorrent against it - effectively freeing up my second connection for regular traffic and keeping it all nice and segmented.

Well, in the course of experimenting, I was completely baffled by my poor torrent performance and sluggish machine performance. I disabled one of my WAN ports and started experimenting with the multiple LAN adapters and here is what I've found:

The net.bind_ip setting appears to work - although it may just be a matter of being reported on the right port. However, the net.outgoing_ip doesn't seem to work at all. It will see a little bit of traffic (which may only be responses to incoming traffic), but it appears all or most of the outgoing traffic goes over the primary NIC.

I have provided illustrations below for a typical session.

This bug is related to the following forum topics:

#4842 net.bind_ip & net.outgoing_ip Dual WAN Connections Question...

#4021 Local Binding option

#2326 µTorrent creates an incorrect UPnP portmap

#1572 "IP to report to tracker" vs net.bind_ip

The settings to bind the IP to the second network adapter. 5.5 is the primary adapter (metric 1), 5.6 is the secondary adapter (metric 9999). I am wanting uTorrent to only use the second adapter to control the WAN binding in the load balancer.

This is the typical behaviour on the NICs. Task Manager with fast refresh. As you can see, all of the outbound traffic is going out of the primary NIC and all of the inbound traffic is coming into the secondary one. Note that the graphs are not on the same scale, as NIC2 is only 6mbps and NIC1 is 100mbps - look instead at the Bytes Sent and Bytes Received in the lower right.

Turning to slow refresh, we see the same imbalance. Note that this still works, as the Load Balancer is aggregating them into a single WAN IP. However, if I reenable my second WAN connection, then the outgoing traffic goes out one WAN IP and the inbound comes in on another WAN IP - which is pretty catastrophic. Needless to say, it doesn't work so good when every machine you connect to thinks you're lying about your IP.

Also of note is that some traffic does escape the second NIC, but it's bursty and is probably only response traffic on the existing inbound connections.

This is one of those things that would be really nice to have, because I essentially have to disable half of my pipes to use uTorrent. Also, while I'm making requests, enumerating the NICs and presenting a dropdown would be beyond cool also. If you guys are accepting code submissions, I wouldn't mind throwing down on it either, and I'm happy to do more research if needed. Either way uTorrent is the slickest thing out there, and it's my pleasure to be one of your users.

Thanks,

-DBCZERO

[SumiVano]

I noticed something similar. I have a network card (192.168.18.1) and a Technotrend DVB-S 1.6 Premium (identical to Skystar1 or Hauppauge Nexus) satellite television card in my computer. The sat card installes a virtual network adapter (192.168.46.21) for internet-over-satellite. I don't use or need it but I cannot disable this adapter because tv software doesn't work if it's not present. I also cannot unbind TCP/IP from this adapter for the same reason.

I have set both net.bind_ip and net.outgoing_ip to the ip 192.168.18.1 of the real lan card but while uTorrent is running my linux router complains about a large amount of invalid routed packets coming from 192.168.46.21 to a lot of different external IPs. Obviously uTorrent sends out packets over the sat interface (which is never working as 99% of the time the sat application is not running and I don't have any subsciption to a sat internet service) instead of the lan card and windows is routing it to the default gateway (my linux router) who complains and drops this packets. This surely causes uTorrent to work much less effective as it could.

I had this behavior never before. I formerly used Azureus and this didn't happen.

SumiVano

Pentium4HT 3.06, 512 MB, 200GB SATA HDD, WinXP SP2, DSL 2048/384, Linux-Router (Ports correctly forwarded)

[cjard]

did you try running a socks server and binding it to one IP only, then sockscapping UT and sending it through the server? does it behave correctly then? if so, it points to a broken net_bind in UT

[ludde]

1) Make sure your router is portmapped to the right internal ip. (I bet you did since you use bind_ip)

2) Did you test with the latest beta version? I don't remember if I changed something or not.

3) Use a packet logger such as Ethereal, and check what outgoing IP the packets have.

I played around with it a bit, and I set utorrent to use the wireless LAN as outgoing (it has low metric in windows). µTorrent changed the outgoing IP appropriately, Still Windows used the ethernet port for the outgoing packets.

[Aqualung]

did you try running a socks server and binding it to one IP only

where do you find a socks/proxy server that you can bind to a certain NIC/IP (meaning whose Internet/outgoing traffic can be selectively routed)? I've been looking for one such proxy server for at least 6 mths., freeware or not. The only one I managed to find is Apache's proxy, however that one is a pain in the ass to configure properly.

[Aqualung]

I played around with it a bit, and I set utorrent to use the wireless LAN as outgoing (it has low metric in windows). µTorrent changed the outgoing IP appropriately, Still Windows used the ethernet port for the outgoing packets.

Here's what: why don't you just set uTorrent to use the wireless NIC as both incoming and outgoing, set the ethernet NIC as default (give it a lower metric), and then just disable the wireless NIC while uTorrent is working at full capacity. See what happens (i.e. wait a little while, say 3-4 mins. before rushing to conclusions). (Yep, I'm only trying to get you to replicate my experiments.)

Cheers, and keep up the good work!