Chronological Thread 

< Chronological >      < Thread >

---

Hi Oleg,

this has been reported a lot of times. The point is that RFC 2960 says in section 10:

o payload protocol-id - A 32 bit unsigned integer that is to be
passed to the peer indicating the type of payload protocol data
being transmitted. This value is passed as opaque data by SCTP.

This has also been made clearer in the socket API ID, section 5.5.2:

sinfo_ppid: 32 bits (unsigned integer)

This value in sendmsg() is an unsigned integer 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 the SCTP stack performs no byte order
modification of this field. For example, if the DATA chunk has to
contain a given value in network byte order, the SCTP user has to
perform the htonl() computation.

So basically, it is NOT a bug in the sctplib. The application must call htonl() if
it wants to send the ppid in network byte order.

Best regards
Michael


On Apr 15, 2006, at 3:04 AM, Oleg Levy wrote:

Hello

I captured an SCTP data stream the other day in Ethereal, and noticed that the protocolID field was not displayed properly. I checked the RFC and it states that all fields must be sent in the network byte order (section 3 of the RFC). It seems that the SCTP stack does not convert this field to the network byte order.

regards
oleg

---

• [SCTP-Discussion] protocolID & byte order, Oleg Levy, 04/15/2006
  • Re: [SCTP-Discussion] protocolID & byte order, Michael Tuexen, 04/15/2006

---

Archive powered by MHonArc 2.6.19+.