Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Magui]

I was wondering if somebody here could explain to me how the "Bind Address" option in amule is supposed to work.  I'm experimenting with it, and according to the packets coming from amule, it doesn't seem to affect the source address at all in amule's packets. 

What's kind of annoying is that amule ignores this IP address when starting an upload or a download with a queued peer.  In other words, if I'm downloading a file, and I wait in someone else's queue, and then I begin downloading from them, amule ignores the IP address in the "Bind Address", and uses the normal (default) IP address instead.  Similar thing happens when I'm uploading to someone who is waiting in queue, and when the upload begins, amule again ignores whatever I put in for "Bind Address".  Quick explanation:  my default IP address is associated with my eth1 interface, which is the default.  I'm trying to get amule to use the ppp0 interface.  The IP address associated with ppp0 is what I'm using in the "Bind Address" box.  This set-up works very well in Azureus, and I can get high ID (green arrow) when connecting to both ed2k and Kad using ppp0.  But I keep having trouble with uploads/downloads that start after some queueing.

A quick search in this forum showed me that other people in the past have had trouble using "Bind Address" in amule.  Maybe this feature is still somewhat incomplete in amule?  If so, I would appreciate it if anybody in here would give me some tips on some alternative ways to accomplish what I'm doing, maybe with iptables or some other way.  I've spent time looking through the file amule.conf, but I don't see any other way of doing this.

Or, maybe someone can tell me how uploads and downloads start up after queueing?  If I knew more about what's involved here, I might be able to come up with some rules in iptables to stop amule from misbehaving.

Anyway, I don't know what else to try, so I would appreciate any kind of reply. 

Thanks.

edit:  I just noticed that amule does the same thing when I first start it up, and it tries to find the old sources for files that I'm downloading.  It starts TCP connections with these old sources, but it uses the default IP address, not the address that I have put in "Bind Address".

[Xaignar]

1) What version of aMule are you using?
And 2) can you check if aMule has correctly bound the ports? (try running 'netstat -npltu|grep amule')

[Magui]

1) What version of aMule are you using?

Yeah, I forgot to mention this.  It's a CVS version, dated from 3 Sept. 2007.

And 2) can you check if aMule has correctly bound the ports? (try running 'netstat -npltu|grep amule')

Code: [Select]

$ sudo netstat -npltu|grep amule
tcp        0      0 83.233.183.45:44976     0.0.0.0:*               LISTEN      21058/amule     
udp        0      0 83.233.183.45:44977     0.0.0.0:*                           21058/amule     
udp        0      0 83.233.183.45:44979     0.0.0.0:*                           21058/amule     

The IP 83.233.183.45 is the IP for ppp0.  That's what I have set for "Bind Address" in amule. 
When amule ignores this, it uses the IP 192.168.0.2, which belongs to eth1.  The port numbers shown
here look OK, I think.  The only one I haven't specified myself is the 2nd udp port, 44979.  I'm not exactly sure
what that port is for, but I have no trouble running Kad, and I don't see any obvious trouble with
finding sources (I've had trouble finding them in the past when Kad is 'firewalled' or won't connect for
some reason).

[Xaignar]

Ok, thanks for the information.

Out of curiosity, do all connections to other clients use the wrong interface, or only some of them? The reason why I ask is that, AFAICS, the problem is that we fail to specify the interface when initiating connections to new clients, but that shouldn't be a problem when accepting inbound connections.

[Xaignar]

In any case, I've committed a fix that should fix this problem.
You can try tomorrows snapshot, or try applying this patch:

Code: [Select]

Index: src/EMSocket.cpp
===================================================================
--- src/EMSocket.cpp    (revision 7997)
+++ src/EMSocket.cpp    (working copy)
@@ -34,7 +34,9 @@
 #include "GetTickCount.h"
 #include "UploadBandwidthThrottler.h"
 #include "Logger.h"
+#include "Preferences.h"

+
 const uint32 MAX_SIZE = 2000000;

 IMPLEMENT_DYNAMIC_CLASS(CEMSocket, CEncryptedStreamSocket)
@@ -42,6 +44,19 @@
 CEMSocket::CEMSocket(const CProxyData *ProxyData)
        : CEncryptedStreamSocket(wxSOCKET_NOWAIT, ProxyData)
 {
+       // If an interface has been specified,
+       // then we need to bind to it.
+       if (thePrefs::GetAddress().IsEmpty() == false) {
+               amuleIPV4Address host;
+
+               // No need to warn here, in case of failure to
+               // assign the hostname. That is already done
+               // in amule.cpp when starting ...
+               if (host.Hostname(thePrefs::GetAddress())) {
+                       SetLocal(host);
+               }
+       }
+
        byConnected = ES_NOTCONNECTED;
        m_uTimeOut = CONNECTION_TIMEOUT; // default timeout for ed2k sockets



[Magui]

Ok, thanks for the information.

Out of curiosity, do all connections to other clients use the wrong interface, or only some of them? The reason why I ask is that, AFAICS, the problem is that we fail to specify the interface when initiating connections to new clients, but that shouldn't be a problem when accepting inbound connections.

Only some of them.

From what I can see, it only happens when amule is dealing with a queue.  When my amule client enters another client's queue, to wait for the download, my client uses the wrong interface.  Similarly, after restarting amule, and my client re-establishes a connection with a previously known source for a download, it again uses the wrong interface.  Same thing when I'm uploading.  When another client comes out of queue, and begins downloading from me, this also happens on the wrong interface.

But there are several inbound clients that always connect through the correct interface.  These are the clients that, after I first launch amule, start downloading from me with no queueing.

I agree with what you're saying, that amule appears to only be misbehaving when it initiates contact.  I know very little about what amule is doing, but the packet-captures I'd done all seemed to indicate this.  I spent some time looking for a way in iptables to more strictly control the way amule initiates connections, but had no luck.  In any case, I thought it best to keep such a big assumption about amule's behavior to myself:).

[Magui]

In any case, I've committed a fix that should fix this problem.
You can try tomorrows snapshot, or try applying this patch:
[snip]

I'll give it a try! 

I'm not really a programmer, so I probably won't bother to edit the source-code and re-compile myself.  But I'll get the snap-shot and I'll post back here and let you know what happens.

[Magui]

Well, no luck.

amule is showing much of the same behavior that it did before. 

But this time I let it run longer (for about an hour), and I noticed a few things in the amule traffic that might also have been happening with the other snapshot (I'm not really sure).

1) When I start up amule, my client still always uses the wrong interface, eth1, to contact previously-known sources for my current downloads.  What I noticed this time around is that, when it does this, it does not use the ports that I've specified for amule in preferences (TCP=44976, UDP=44977, as shown above).   Actually, I don't see any pattern to the ports that it is using here.  They seem randomly chosen.  But I always see a SYN packet go out from my client to these sources, as soon as amule starts up.

1) The majority of amule clients that are downloading from me are using the right interface, ppp0.  About 10-15% of these clients, at any time, are using the wrong interface.  From what I can see, it doesn't matter if these clients have been queued, or are just immediately beginning to download from me when I start up amule.  For these clients using the wrong interface, just as in #1, my client is using random ports to communicate with them.  As for the clients that are using the right interface, all of them are using the correct ports.

This is all I can figure out from looking over packet-capture data.  But I cannot see a pattern in which clients are using the right interface, and the clients using the wrong one.  I looked for obvious things:  name and version of remote client software, remote port number, type of file being downloaded, server being used by remote client, etc.  I don't know, maybe if I spend a few hours doing this, I might notice something, but I'm not sure.

By the way, this is what I'm running now:
aMule SVN Snapshot
 Wed Jan 23 07:01:57 CET 2008

[Kry]

Outgoing connections never use the preferences ports - those are for incoming connections.

[Xaignar]

Outgoing connections never use the preferences ports - those are for incoming connections.

Seems a bit odd to only apply it to one way, IMO.

[phoenix]

Hi Magui,

Well, no luck.

amule is showing much of the same behavior that it did before. 

But this time I let it run longer (for about an hour), and I noticed a few things in the amule traffic that might also have been happening with the other snapshot (I'm not really sure).

1) When I start up amule, my client still always uses the wrong interface, eth1, to contact previously-known sources for my current downloads.  What I noticed this time around is that, when it does this, it does not use the ports that I've specified for amule in preferences (TCP=44976, UDP=44977, as shown above).   Actually, I don't see any pattern to the ports that it is using here.  They seem randomly chosen.  But I always see a SYN packet go out from my client to these sources, as soon as amule starts up.

The bind interface is for incomming connections. In a normal situation, it should be "0.0.0.0", which means "any interface will do". If you put some address here, then you can limit the interface that is able to accept a connection.

If aMule or any other program starts a connections, then it is up to the kernel to look at the routing tables to choose the right outgoing interface. Messing with that is possible, though subtle. Those connections you see using the wrong interface have probably been started by aMule itself. For some reason the kernel has choosen this interface. Take a look at the routing table to understand what is going on, or post it here.

1) The majority of amule clients that are downloading from me are using the right interface, ppp0.  About 10-15% of these clients, at any time, are using the wrong interface.  From what I can see, it doesn't matter if these clients have been queued, or are just immediately beginning to download from me when I start up amule.  For these clients using the wrong interface, just as in #1, my client is using random ports to communicate with them.  As for the clients that are using the right interface, all of them are using the correct ports.

What you describe seems perfectly normal to me. If you start the connection, you will use a random port number in the interface that the kernel chooses. If you receive and accecpt a connection, then you will use the bind interface and the port number specified.

This is all I can figure out from looking over packet-capture data.  But I cannot see a pattern in which clients are using the right interface, and the clients using the wrong one.  I looked for obvious things:  name and version of remote client software, remote port number, type of file being downloaded, server being used by remote client, etc.  I don't know, maybe if I spend a few hours doing this, I might notice something, but I'm not sure.

Try to figure out which machine has initiated the connection, yours or the other one. That must be the difference.

Cheers!

[Xaignar]

If aMule or any other program starts a connections, then it is up to the kernel to look at the routing tables to choose the right outgoing interface. Messing with that is possible, though subtle. Those connections you see using the wrong interface have probably been started by aMule itself. For some reason the kernel has choosen this interface. Take a look at the routing table to understand what is going on, or post it here.

Hmm, the wx-docs does suggest that it's possible to specify the local address before connecting:
http://www.wxwidgets.org/manuals/2.8/wx_wxsocketbase.html#wxsocketbasesetlocal

[phoenix]

Xaignar,

I see, the documentation for wxSocketBase::SetLocal() says that for a wxSocketClient, bind() will be called before connect(), and this indeed should set the IP address and port. Normally, one does not call bind() before connect() because one doesn't care about the outgoing IP/Port that will be used, the kernel takes care of it.

I didn't know about wxSocketBase::SetLocal(), and I totally agree that your patch should have fixed the matter that Magui is reporting.

[Magui]

Outgoing connections never use the preferences ports - those are for incoming connections.

Yeah, there's something I never mentioned.  Among the iptables rules that I have set up, there are two that I use for outgoing connections.

Code: [Select]

$ sudo iptables -t nat -A POSTROUTING -p tcp --source 83.233.181.199 -j SNAT --to 83.233.181.199:44976
$ sudo iptables -t nat -A POSTROUTING -p udp --source 83.233.181.199 -j SNAT --to 83.233.181.199:44977

I don't remember exactly what I was thinking when I decided to use these rules.  I was just fumbling around, trying to get this set-up right for Azureus, and I think my reasoning went like, "If I force Azureus to only initiate connections from a certain IP and a certain port, then all replies from other clients will come to that IP and port."

This kind of assumption seems to work well enough in Azureus.  I thought it would work in amule too.  I guess the problem is because of what phoenix says:  that the "Bind address" feature is not meant to be used for outgoing connections.

The bind interface is for incomming connections. In a normal situation, it should be "0.0.0.0", which means "any interface will do". If you put some address here, then you can limit the interface that is able to accept a connection.

I must say, it surprised me when I read this from you.  I just assumed that it did more than that.  I mean, I thought amule would accept only packets that have the bind address as a destination, and would set the bind address as the source for all packets that it generates.  I guess, from what you're saying, amule only does the first part.  Well, some of the iptables rules that I had set were based on this wrong assumption.

If aMule or any other program starts a connections, then it is up to the kernel to look at the routing tables to choose the right outgoing interface. Messing with that is possible, though subtle. Those connections you see using the wrong interface have probably been started by aMule itself. For some reason the kernel has choosen this interface. Take a look at the routing table to understand what is going on, or post it here.

Yeah, I do believe that these problematic connections are all out-going.  But in Azureus, the routing I have set up already works exactly the way I want, so I'm a bit reluctant to mess with them any more.  I've pasted below the routing tables that I'm using.

What you describe seems perfectly normal to me. If you start the connection, you will use a random port number in the interface that the kernel chooses. If you receive and accecpt a connection, then you will use the bind interface and the port number specified.

Try to figure out which machine has initiated the connection, yours or the other one. That must be the difference.

Sorry about this, but my wording was wrong in my post.  What I meant was that I was seeing clients begin downloads from me after spending some time in queue.  Most of these clients would download on ppp0, but some would download on the wrong interface, on eth1.  For the clients that download on eth1, I could not see anything they have in common.  I was looking for some cause, some reason, why amule ignores the bind address for these clients, and initiates connections with them on the wrong interface, using some random port that completely ignores the port that I set using the iptables rules that I mentioned above.  I think you already gave the answer to this question.  amule will not use the bind address for outgoing connections, and I do believe that these trouble-some connections are all out-going.  Same thing happens when my amule client contacts previously-known sources for files that I am downloading.

I'm not sure what else to try now.  Xaignar has already applied a patch that I was hoping to fix this, but it looks like there's still a hole in my routing or iptables set-up somewhere.  I'll probably run amule a few more times, download more SVN snap-shots, examine closely these clients that keep showing up on the wrong interface, etc.

Here is the routing table I'm using at the moment:

Code: [Select]

$ sudo route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
83.233.181.2    192.168.0.1     255.255.255.255 UGH   0      0        0 eth1
83.233.181.2    0.0.0.0         255.255.255.255 UH    0      0        0 ppp0
192.168.0.0     0.0.0.0         255.255.255.0   U     0      0        0 eth1
0.0.0.0         192.168.0.1     0.0.0.0         UG    0      0        0 eth1
The first line is one that I added.  It just sets an outgoing route to the Internet for packets that are going out through the ppp0 interface.
The second line is added by pppd (I think) as soon as the ppp0 interface is established.
The last 2 lines are just default.  They're always there.

I also have created another routing table, specifically for the ppp0 interface.  It looks like this:

Code: [Select]

$ sudo ip route show table vpn
83.233.181.2 dev ppp0  scope link  src 83.233.181.199
default via 83.233.181.2 dev ppp0

And, just for completeness' sake,

Code: [Select]

$ sudo ifconfig
eth1      Link encap:Ethernet  HWaddr 00:a0:cc:a2:9c:ab 
          inet addr:192.168.0.2  Bcast:192.168.0.255  Mask:255.255.255.0
          inet6 addr: fe80::2a0:ccff:fea2:9cab/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:18044484 errors:0 dropped:0 overruns:0 frame:0
          TX packets:24706410 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:1569668379 (1.4 GiB)  TX bytes:2007729161 (1.8 GiB)
          Interrupt:11 Base address:0x6000

lo        Link encap:Local Loopback 
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:235896 errors:0 dropped:0 overruns:0 frame:0
          TX packets:235896 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:32111883 (30.6 MiB)  TX bytes:32111883 (30.6 MiB)

ppp0      Link encap:Point-to-Point Protocol 
          inet addr:83.233.181.199  P-t-P:83.233.181.2  Mask:255.255.255.255
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1400  Metric:1
          RX packets:2250098 errors:0 dropped:0 overruns:0 frame:0
          TX packets:3194497 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:3
          RX bytes:114763113 (109.4 MiB)  TX bytes:3708930705 (3.4 GiB)


Since this post is already becoming ridiculously long, here's my iptables set-up:

Code: [Select]

$ sudo iptables -t mangle -L
Chain PREROUTING (policy ACCEPT)
target     prot opt source               destination         

Chain INPUT (policy ACCEPT)
target     prot opt source               destination         

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         
MARK       all  --  83.233.181.199       anywhere            MARK set 0x1
MARK       tcp  --  anywhere             anywhere            multiport ports 6543,4232,4242,4321,4661,4662,5000 MARK set 0x1

Chain POSTROUTING (policy ACCEPT)
target     prot opt source               destination         


$ sudo iptables -t nat -L
Chain PREROUTING (policy ACCEPT)
target     prot opt source               destination         
DNAT       tcp  --  anywhere             83.233.181.199      to:83.233.181.199:44976
DNAT       udp  --  anywhere             83.233.181.199      to:83.233.181.199:44977
DNAT       tcp  --  anywhere             anywhere            multiport sports 6543,4232,4242,4321,4661,4662,5000 to:83.233.181.199:44976
DNAT       udp  --  anywhere             anywhere            multiport sports 6543,4232,4242,4321,4661,4662,5000 to:83.233.181.199:44977

Chain POSTROUTING (policy ACCEPT)
target     prot opt source               destination         
SNAT       tcp  --  83.233.181.199       anywhere            to:83.233.181.199:44976
SNAT       udp  --  83.233.181.199       anywhere            to:83.233.181.199:44977
SNAT       tcp  --  anywhere             anywhere            multiport dports 6543,4232,4242,4321,4661,4662,5000 to:83.233.181.199:44976
SNAT       udp  --  anywhere             anywhere            multiport dports 6543,4232,4242,4321,4661,4662,5000 to:83.233.181.199:44977

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         
Note:  about the "MARK" targets in the mangle table, I have another rule that forces all packets marked with '1' into the ppp0 routing table.   I'm talking about the second rule displayed below.

Code: [Select]

$ sudo ip rule show
0:      from all lookup local
32765:  from all fwmark 0x1 lookup vpn
32766:  from all lookup main
32767:  from all lookup default


[phoenix]

The bind interface is for incomming connections. In a normal situation, it should be "0.0.0.0", which means "any interface will do". If you put some address here, then you can limit the interface that is able to accept a connection.

I must say, it surprised me when I read this from you.  I just assumed that it did more than that.  I mean, I thought amule would accept only packets that have the bind address as a destination, and would set the bind address as the source for all packets that it generates.  I guess, from what you're saying, amule only does the first part.  Well, some of the iptables rules that I had set were based on this wrong assumption.

Since Xaignar's patch aMule sets the address for outgoing connections too.

I am not sure your routing table / NAT will work, it looks a complicated setup. What exactly are you trying to do? Make aMule use only ppp0, while the other programs use eth1? Or make incomming packets go through a different interface from the outgoing packets?