Re: Source IP not corresponding to interface
|[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]|
Hi Vlad!I have applied the patch and repeated the same test. The results are good. I don't see any packets with wrong source IP in the wlan interface any more. Most of the times the switchover from 3G to wlan (when wlan's IP is made available and added to the association) is quite fast. Sometimes, I observe a small delay between the ASCONF_ACK received from the server (corresponding to the ASCONF for adding the wlan's IP address) and the first packet (SACK or ASCONF for setting peer's primary) transmitted from the wlan interface. The maximum value of this delay is about 1 second. During this small delay, no packets are transmitted from wlan or 3G interface.
Best regards, George On 05/25/2010 09:12 PM, Vlad Yasevich wrote:
Hi George Georgios Cheimonidis wrote:Hi Vlad! Thanks for the quick reply! - The default route is recreated with a different metric but always smaller than the metric corresponding to the default route of the 3G interface. - The IP addresses were all IPv4, but I used AF_INET6 sockets, since in some other tests I add and remove IPv6 addresses as well. I don't know if this matters. - I am also attaching the kernel log from the client host. Address X of the previous description is 192.XXX.XXX.XXX (client's wlan), Y is 95.YYY.YYY.YYY (client's 3G) and Z is 213.ZZZ.ZZZ.ZZZ (server's single IP address). I will also try to examine it and check the sctp_v4_get_dst() calls. Nice to hear about the v6 patch! I will also do some testing and let you know about the results. Have you already published it in the mailing list?Ok, so here is a simple patch to try along with the explanation. When you add a address we send an ASCONF, but the new address is not usable for anything other then Heartbeats util ASCONF_ACK is received. Also, the addition of a new default route causes something to timeout or change such that the transport looses a route. When we look up the new route, we get an updated route with the lower metric; however, we can't use the source provided by that route because we have not received the ASCONF_ACK yet. So, we try to do a lookup with the source addresses provided. We still can only use 1 of the addresses (the 3G one). The routing table still appears to return us the route with a lower metric. I can reproduce this with a simple 'ip route get' command. Try it on your system: ip route get<dest> from<second source> You will see a route that will have the source set to 'second source', but using the interface that the preferred source is configured on (since that one has a lower metric). Thus we end up using the wrong interface, with the 'correct' source address. I don't think there is anything we can do about this before ASCONF_ACK is received. However, when we receive the ASCONF_ACK, we can trigger a route lookup and source address selection again. I've attached the patch. So, looks like you will still see this strange condition for a short duration, but once ASCONF_ACK is received it should clear up. Let me know how if this works. I'll look back in history to see why the code is the way it is. -vladBest regards George On 05/25/2010 07:11 PM, Vlad Yasevich wrote:Georgios Cheimonidis wrote:Hi! I have observed a problem while doing some tests with dynamic address reconfiguration. Let me first describe my setup and application. Setup: I have two hosts, one that acts as a client and another that acts as a server. The client has two IPv4 addresses (one on wlan, let's call it X, and another on a 3G p-to-p connection, let's call it Y). There are two default routes on the client, and the wlan default has a smaller metric than the 3G default. The server is single homed. All addresses belong to different subnets. Both hosts are running the net-next kernel, downloaded from David Miller's net-next source tree on 12-May-2010). I have also applied two extra patches found in: (a) http://www.spinics.net/lists/linux-sctp/msg00881.html and (b)http://www.spinics.net/lists/linux-sctp/msg00882.html. I have also enabled SCTP debugging messages.Hi George Thanks for this report. I am setting up a reproduction environment now. Will let you know what I find. It sounds like the routing might get kind-of funky after you add the address back. Does the default route get recreated with the right metric? Kernel logs are always nice to have. You can even look through them and try finding references to sctp_v4_get_dst() call to see what it shows you. Thats where routing and source address selection is done. I am also assuming that this is all v4, right? I've got v6 patch ready finally. Passed all the tests I could throw at it. -vlad
-- To unsubscribe from this list: send the line "unsubscribe linux-sctp" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html