Re: Source IP not corresponding to interface

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

Georgios Cheimonidis wrote:
> 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.

Interesting...  Can you send a log when this occurs?

Also,  does this 1 second delay occur if you disable debug output?  I now
sometimes the output itself can cause delays.

-vlad

> 
> 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.
>>
>> -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
>>>>
>>>
> 
> -- 
> To unsubscribe from this list: send the line "unsubscribe linux-sctp" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>