Re: Source IP not corresponding to interface

[Vlad Yasevich <vladislav.yasevich@hp.com>]

[-- Attachment #1: Type: text/plain, Size: 4120 bytes --]

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.

-vlad

> Best 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
>>    
> 

[-- Attachment #2: george.patch --]
[-- Type: text/x-patch, Size: 523 bytes --]

diff --git a/net/sctp/sm_make_chunk.c b/net/sctp/sm_make_chunk.c
index 24effdf..183d38c 100644
--- a/net/sctp/sm_make_chunk.c
+++ b/net/sctp/sm_make_chunk.c
@@ -3136,8 +3136,6 @@ static void sctp_asconf_param_success(struct sctp_association *asoc,
 		local_bh_enable();
 		list_for_each_entry(transport, &asoc->peer.transport_addr_list,
 				transports) {
-			if (transport->state == SCTP_ACTIVE)
-				continue;
 			dst_release(transport->dst);
 			sctp_transport_route(transport, NULL,
 					     sctp_sk(asoc->base.sk));