search

msantos / pkt

Erlang network protocol library
http://blog.listincomprehension.com/search/label/epcap
BSD 3-Clause "New" or "Revised" License
150 stars 44 forks source link

SCTP chunk's padding value is not zero #15

Closed ates closed 10 years ago

ates commented 10 years ago

Hello,

I've faced a strange situation when chunks's padding value was not filled with zeros, as it is stated in RFC. Here is an example of SCTP packet:

<<11,89,11,89,109,75,153,162,11,83,232,167,5,0,0,26,0,1,0,22,150,192,147,82,62,
  25,29,131,1,0,120,136,16,85,0,64,0,0,1,1>>

The last two bytes are "padding" and looks like it's incorrect behaviour to have value of padding different from zero.

Has someone seen anything like that before?

Please do not close this issue for some time. It's easy to fix that in pkt_sctp module, but I want to wait for someone who can share some knowledge about that.

ates commented 10 years ago

Fixed in https://github.com/msantos/pkt/commit/87d90b5af4d79e281253b4765c5d9f961a6488bc

ates commented 10 years ago

@laf0rge, Hello Harald, do you have any idea? (I asked you because you have added initial support of SCTP in pkt, maybe you know something about that)

msantos commented 10 years ago

@ates Apologies for the long delay, I meant to look into this. From what I can tell, with sctp, the padding should be ignored (rfc4820):

Padding Data: n bytes (unsigned integer)
      This holds the Padding Data.  The Padding Data MUST be ignored by
      the receiver.