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

From: La Monte H.P. Yarroll <piggy@timesys.com>
Date: Fri Feb 04 2005 - 10:36:21 EST

('binary' encoding is not supported, stored as-is) ('binary' encoding is not supported, stored as-is) Randall Stewart wrote:

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

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.

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

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

Received on Fri Feb 4 10:43:25 2005