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

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

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

> 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.
>>
>> 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 05:57:56 2005