Jan24-2005snap+Patch24 loopback source value ?

From: Brad Penoff <penoff@cs.ubc.ca>
Date: Fri Feb 04 2005 - 02:54:44 EST

('binary' encoding is not supported, stored as-is) ('binary' encoding is not supported, stored as-is) 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
Received on Fri Feb 4 03:08:57 2005