Magui,
I don't think you are doing anything wrong. But messing with NAT and routing tables is tricky.
Yeah, I have to agree with you here. The iptables stuff is mostly stuff I guessed at and adjusted and re-adjusted until I got azureus to work. But I was pretty lost on how to do the routing until I came upon the one webpage that explained how to set up multiple routes
In principle, we should have closed all the possibilities, but we can deduce from your results that there is something escaping.
Yeah, I think of it as a "hole".
You could do some tests. First, disable all the other sockets and test one network at a time. See if there is a situation where you don't get mixed sources.
I didn't understand what you meant by "disable all other sockets", but after reading "test one network at a time", I decided to try running amule with the UDP port disabled and Kad also disabled.
We have the listening socket bound to an interface, so it is unlikely that these connections are incomming. The other possibility is that somewhere in the code aMule still uses an unbound socket to connect. Could you use wireshark to follow one of these connections since its begining to be sure of who initiated it? Also, if you can disable obfuscation, maybe wireshark is able to dissect ed2k and give us some more information.
Yeah, I've been running with obfuscation disabled while I try to sort this out. And it also appears to me that I am having no problems with incoming connections. This mix-up with the interfaces seems to only happen with outgoing connections.
Anyway, I did notice something interesting a few minutes ago.
One client connected to my client (it sent a syn packet to my client) on the ppp0 interface, on the correct port, 44976. A few TCP packets went back and forth, and then this connection was closed (I think this client entered my queue at this time). About eight minutes later, my client sent a syn packet to this client, using the eth1 interface and port 55503 (just a random port, I guess). This TCP exchange went much longer. When I checked in amule, I was able to match the IP of this client in wireshark with the IP of a client in amule that had just come out of queue, and had begun downloading from me. I noticed that this client was one of the first few to come out of queue, but two or three clients had come out of queue before it, and had also begun downloading. I'm guessing they were downloading in pppo, because the packet-capture showed no downloading activity on eth1, aside from this client, and another one that I describe next.
I looked in the packet-capture for another pattern like this, and found the same thing happened with another client, at about the same time. This other client also sent a syn packet to my client on ppp0, port 44976. A short TCP exchange followed, and then was closed. Nearly 10 minutes later, my client sent a syn packet to this other client using eth1, port 40980. This TCP exchange went on until it ended with a bunch of "TCP Retransmission" packets. Seeing this, I remembered that in amule, one of the first clients to come out of queue had begun downloading from me, and almost immediately disappeared. Connection went bad, I guess.
All this happened after running amule for about a half-hour. I don't have time to do much more of this right now, but I'll try come back to this tomorrow and let amule run longer and see if this happens again. Probably also try downloading a file too, and see what happens. The reason I noticed this today is that I set wireshark to capture all network traffic, not just traffic on eth1 (as I did previously).
Based just on this, it appears as if amule handles the bind-address differently when initiating connections with
some clients in queue. I had suspected something like this in the past few days, but I never could find anything about these clients that would cause this misbehavior in my client, while others just start downloading in pppo. I'll have to look more closely at the queued clients that start downloading on ppp0, and see if that reveals anything.
Also, I couldn't get any more useful information about the problem of using eth1 on previously-known sources for some of my ongoing downloads. The packet-capture only showed that, as soon as I connect to an ed2k server in amule, my client uses eth1 to send out syn packets to several IPs (the source-clients), and this initiates TCP connections with them, and my client gets into their download queues. But I already knew this, so nothing new there.
Another thing, make sure that NAT is not fooling you somehow. Use only the strict necessary rules for your setup.
I'm not quite sure what you mean by NAT fooling me. I think the nat rules that I have created in iptables are doing just what I want, and my previous testing indicates that packets tend to get lost without them.
By the way, I'm running:
aMule SVN Snapshot:
Sat Jan 26 07:01:58 CET 2008
I'll stop downloading these snap-shots for now:). Like I said, I'll try to find time to do more of this tomorrow, and probably also start writing down the IPs of these clients. When a few of them come out of queue at about the same time, and you look back through the packet-capture later, it can be a bit difficult to reconstruct which client was doing what and when.
