https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=4050
Jeff Morriss <jeff.morriss.ws@xxxxxxxxx> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |jeff.morriss.ws@xxxxxxxxx
--- Comment #6 from Jeff Morriss <jeff.morriss.ws@xxxxxxxxx> 2009-10-16 11:39:01 PDT ---
(In reply to comment #4)
> Hi,
> Wiresharks dissectors get's handed tvb(buffer) with the protocol data.
> In this trace the ISUP dissector gets handed
> 0000 1b 00 06 10 14 01 29 01 01 00 e.g no extra octet locking further
> the MTP2 lenght is "Message length: 35" the SCTP info is:
> DATA chunk(ordered, complete segment, TSN: 649430584, SID: 1, SSN: 3211, PPID:
> 5, payload length: 36 bytes).
>
> So I guess the SCTP data is one octet longer than the MTP2 data
> >I am told by my vendor Squire Technologies
> >(http://www.squire-technologies.co.uk) that they are padding to the 32bit
> >boundary per the SPEC. I personally don't see this in the SPEC.
> This would bet the SCTP spec I would think...
I think the sender's SCTP is broken. I think they're trying to pad the SCTP
chunk to a 32-bit boundary, BUT they included the pad in the length of the
chunk. From section 3.2 of RFC 4960 (with emphasis added by me):
The total length of a chunk (including Type, Length, and Value
fields) MUST be a multiple of 4 bytes. If the length of the chunk is
not a multiple of 4 bytes, the sender MUST pad the chunk with all
zero bytes, **and this padding is not included in the Chunk Length
field**. The sender MUST NOT pad with more than 3 bytes. The receiver
MUST ignore the padding bytes.
(FYI if Wireshark's SCTP dissector had detected padding, it would add the
padding bytes to the tree as such; we're not seeing that here because there is
no padding because the length is a multiple of 4.)
--
Configure bugmail: https://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
