Subject: Jan24-2005snap+Patch24 loopback source value ?

From: Brad Penoff <[email-masked]>
Date: Thu, 3 Feb 2005 23:54:44 -0800 (PST)

Greetings,

I wanted to inquire about some behavior I'm seeing when running a client 
and server on the SAME HOST via kame sctp with either one-to-one or 
one-to-many style.  I've reduce the problem to this trivial example where 
I used one-to-many style.  Essentially the difference is that 127.0.0.1 
comes up often in kame sctp but NEVER in similar tests on lksctp, BSD TCP, 
nor Linux TCP.

Say the server does this:

socket, bind(INADDR_ANY), listen, sctp_recvmsg, close

While the client, when passed an IP from the command line, does this:

socket, puts given-IP into sockaddr_in, sctp_sendmsg, close

I run this with "client 192.168.10.x" on the following examples.  All the 
data was gotten by snooping on the loopback interface.

When running on kame sctp, I get something like:

#  Source         Destination        Info

a  127.0.0.1      192.168.10.200     [Short frame]
b  127.0.0.1      127.0.0.1          [Short frame]
c  127.0.0.1      192.168.10.200     [Short frame]
d  127.0.0.1      127.0.0.1          COOKIE_ACK
e  127.0.0.1      192.168.10.200     DATA
f  127.0.0.1      127.0.0.1          SACK
g  127.0.0.1      127.0.0.1          SHUTDOWN
h  127.0.0.1      192.168.10.200     SHUTDOWN_ACK
i  127.0.0.1      127.0.0.1          SHUTDOWN_COMPLETE

Whereas with lksctp, I get:

j  192.168.10.112  192.168.10.112    [Short frame]
k  192.168.10.112  192.168.10.112    [Short frame]
l  192.168.10.112  192.168.10.112    [Short frame]
m  192.168.10.112  192.168.10.112    COOKIE_ACK
n  192.168.10.112  192.168.10.112    SACK
o  192.168.10.112  192.168.10.112    SHUTDOWN
p  192.168.10.112  192.168.10.112    SHUTDOWN_ACK
q  192.168.10.112  192.168.10.112    SHUTDOWN_COMPLETE

I'm not exactly sure why I'm getting these "Short frame"s.  They'd be nice 
to see in full to see the interfaces in the INITs but honestly they are 
somewhat irrelevant to my exact concern...

This same test ran over TCP on either BSD or Linux ends up looking like 
the lksctp data above (i.e. they NEVER show 127.0.0.1).  And these tests 
were run on the EXACT hosts so it isn't a routing or name resolution 
issue.  Is kame sctp acting incorrectly here (should it NOT be having 
127.0.0.1 ever as the others on the loopback interface when an 
application itself does not use 127.0.0.1)?

Thanks,
brad

---

From: Michael Tuexen <[email-masked]>
Date: Fri, 4 Feb 2005 09:44:04 +0100

Hi Brad,

what tool are you using for capturing the traffic? It looks like
it uses a small snaplen such that the long packets containing the
INIT, INIT-ACK and COOKIE-ECHO are not completely captured.

Can you specify a long snaplen and post the capture file?

Best regards
Michael

On Feb 4, 2005, at 8:54 Uhr, Brad Penoff wrote:

> Greetings,
>
> I wanted to inquire about some behavior I'm seeing when running a 
> client and server on the SAME HOST via kame sctp with either 
> one-to-one or one-to-many style.  I've reduce the problem to this 
> trivial example where I used one-to-many style.  Essentially the 
> difference is that 127.0.0.1 comes up often in kame sctp but NEVER in 
> similar tests on lksctp, BSD TCP, nor Linux TCP.
>
> I run this with "client 192.168.10.x" on the following examples.  All 
> the data was gotten by snooping on the loopback interface.
>
> I'm not exactly sure why I'm getting these "Short frame"s.  They'd be 
> nice to see in full to see the interfaces in the INITs but honestly 
> they are somewhat irrelevant to my exact concern...
>
> This same test ran over TCP on either BSD or Linux ends up looking 
> like the lksctp data above (i.e. they NEVER show 127.0.0.1).  And 
> these tests were run on the EXACT hosts so it isn't a routing or name 
> resolution issue.  Is kame sctp acting incorrectly here (should it NOT 
> be having 127.0.0.1 ever as the others on the loopback interface when 
> an application itself does not use 127.0.0.1)?
>
>
> Thanks,
> brad

---

From: Randall Stewart <[email-masked]>
Date: Fri, 04 Feb 2005 05:20:04 -0500

Brad:

A couple of things..

1) I don't think the behavior is invalid... if all
    addresses are bound its ok... since any source
    address is valid.

2) I believe this was due to an issue with source address
    selection.. which has been completely re-written since
    patch24.. so I am not sure if you would still see this
    behavior in a more "current" release.. even though I have
    not released patch25 yet :-0... still struggling with
    SMP issues

R

Brad Penoff wrote:
> one-to-many style.  I've reduce the problem to this trivial example 
> where I used one-to-many style.  Essentially the difference is that 
> 127.0.0.1 comes up often in kame sctp but NEVER in similar tests on 
> lksctp, BSD TCP, nor Linux TCP.
> 
> nice to see in full to see the interfaces in the INITs but honestly they 
> are somewhat irrelevant to my exact concern...
> 

-- 
Randall Stewart
ITD
803-345-0369 <or> 815-342-5222

---

From: Brad Penoff <[email-masked]>
Date: Fri, 4 Feb 2005 02:44:30 -0800 (PST)

hey Michael,

I increased the snaplen and got full frames now.  It appears as if on the 
lksctp run, 127.0.0.1 isn't one of the IPv4 address parameters, whereas on 
kame sctp, it is.  I've attached each trace for you to take a gander, if 
you want.  Just curious, but what would be your opinion as to if 
127.0.0.1 should be there or not?

While this is a simple example, where we're seeing this become an issue is 
with a vanilla port of LAM-MPI; when it gets items from 127.0.0.1 it gets 
confused and doesn't make it past lamboot...  it may just mean we'll have 
to change this confusion within the MPI middleware, but overall this just 
made me curious as to what was "right" within any SCTP since such loopback 
tests have different behaviors from lksctp to kame sctp.

As I write this I just saw Randall's response...  any clues for how I 
might be able to edit the kame sctp patch 24 code to NOT include 127.0.0.1 
as one of its IPv4 address parameters?  I've only been a user up until 
this point so I haven't really dove into the kernel code yet...

bedtime :-),
brad

On Fri, 4 Feb 2005, Michael Tuexen wrote:

>> 127.0.0.1 ever as the others on the loopback interface when an application 
>> itself does not use 127.0.0.1)?
>> 
>> 
>> Thanks,
>> brad
>

---

From: "La Monte H.P. Yarroll" <[email-masked]>
Date: Fri, 04 Feb 2005 10:36:21 -0500

>    addresses are bound its ok... since any source

As long as the address is "in scope" for the correspondant...
Randy's code puts a lot more effort into deciding valid scope
than lksctp.  In lksctp we simply always remove loopback
from the list of valid addresses.

On a Linux box, bring down all interfaces except lo and you'll
see behavior closer to the Kame behavior.

>> resolution issue.  Is kame sctp acting incorrectly here (should it 
>> NOT be having 127.0.0.1 ever as the others on the loopback interface 
>> when an application itself does not use 127.0.0.1)?
>>
>>
>> Thanks,
>> brad
>>
>
>

-- 
"Beware of bugs in the above code; I have only proven it correct,
not tried it."  -Donald Knuth