Re: [Lksctp-developers] Some Bugs?

[Michael T. <Mic...@lu...>]

Sridhar.

see my comments iline.

Best regards
Michael

On 22. Mar 2004, at 23:58 Uhr, Sridhar Samudrala wrote:

> On Sun, 21 Mar 2004, Michael Tuexen wrote:
>
>> Dear all,
>>
>> I'm using the 2.6.2 kernel.
>>
>> It seems that the Linux SCTP implementation does some little/big
>> endian byte order transformation of the PPID field. From the ID:
>>
>>     sinfo_ppid: 32 bits (unsigned integer)
>>
>>     This value in sendmsg() is an opaque unsigned value that is 
>> passed to
>>     the remote end in each user message.  In recvmsg() this value is 
>> the
>>     same information that was passed by the upper layer in the peer
>>     application.  Please note that byte order issues are NOT accounted
>>     for and this information is passed opaquely by the SCTP stack from
>>     one end to the other.
>>
>> Therefore the user has to call htonl() by himself.
>>
>> To reproduce the problem you can use the following Scheme Code,
>> translation
>> to C is trivial:
>>
>> (define s (socket AF_INET SOCK_STREAM IPPROTO_SCTP))
>> (connect s AF_INET (inet-aton "192.168.1.30") 5555)
>> (sctp-sendmsg s "Hallo" 1 0 0 0 AF_INET (inet-aton "192.168.1.30") 
>> 5555)
>> (sctp-sendmsg s "Hallo" (ntohl  1) 0 0 0 AF_INET (inet-aton
>> "192.168.1.30") 5555)
>>
>> The first message shows an incorrect PPID on the wire whereas the
>> second shows
>> the correct. So I assume that you call htonl() in your code.
>
> Yes. We do a htonl() before sending and a ntohl() after receiving the 
> chunk.
> This does conflict with the above sinfo_ppid description from the API 
> draft.
>
> So an application needs to do a htonl() on the ppid, but should not do 
> a
> htons() on the stream_no passed to sctp_sendmsg(). Isn't it little 
> confusing?
Possibly. The example in UNP also does not show the htonl() call. I 
will see
if we change the ID.
>
>>
>> The next problem is that for a 1-1 style socket I would think that I
>> can use
>> (sctp-sendmsg s "Hallo" 1 0 0 0 AF_INET INADDR_ANY 0)
>> because the destination address and port is known. sctp-sendmsg 
>> returns
>> an error.
>> This should not occur.
>
> I guess here sctp_sendmsg() is called on on a connected 1-1 style 
> socket.
> Currently it is OK to pass a NULL destination address, but you get an 
> error
> if you pass an invalid or INADDR_ANY address.
Ahh.
> I think the right behavior is to ignore the destination address on a
> connected 1-1 style socket or a peeled-off socket. This needs to be 
> fixed.
>
Except when you use the MSG_OVER flag...
>>
>> The last problem I found is that the following code just works:
>> (define s (socket AF_INET SOCK_STREAM IPPROTO_SCTP))
>> (sctp-sendmsg s "Hallo" 1 0 0 0 AF_INET (inet-aton "192.168.1.30") 
>> 5555)
>>
>> I think there should be an error returned, because the socket is not
>> connected.
>
> This is due to the fact that lksctp supports auto-connect even on a 
> 1-1 style
> socket. This enables bundling of data with cookie-echo.
I see.
> I hope this is OK unless there are any negative sideeffects with 
> auto-connect
> on 1-1 style socket.
I think it is OK. Thanks for the clarification.
>
> Thanks
> Sridhar
>
>>
>> Best regards
>> Michael
>>
>> PS.: The examples are given in scheme, which just wraps the
>> corresponding C functions.
>>
>>
>>
>>
>> -------------------------------------------------------
>> This SF.Net email is sponsored by: IBM Linux Tutorials
>> Free Linux tutorial presented by Daniel Robbins, President and CEO of
>> GenToo technologies. Learn everything from fundamentals to system
>> administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
>> _______________________________________________
>> Lksctp-developers mailing list
>> Lks...@li...
>> https://lists.sourceforge.net/lists/listinfo/lksctp-developers
>>
>