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

From: Randall Stewart <rrs@cisco.com>
Date: Fri Feb 04 2005 - 05:20:04 EST

('binary' encoding is not supported, stored as-is) ('binary' encoding is not supported, stored as-is) 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:
> 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
>

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

Received on Fri Feb 4 05:24:46 2005