Wireshark-dev: Re: [Wireshark-dev] [Wireshark-commits] rev 46239: /trunk/epan/dissectors/ /trun
On Dec 5, 2012, at 4:30 PM, Jeff Morriss wrote:
> Michael Tuexen wrote:
>> On Nov 29, 2012, at 8:32 PM, Jeff Morriss wrote:
>> The change committed in
>> http://anonsvn.wireshark.org/viewvc/viewvc.cgi?view=rev&revision=46290
>> is now pretty defensive. It covers both cases.
>>>> RFC 4960 says regarding the chunk length:
>>>> The Chunk Length value does not include terminating padding of the
>>>> chunk. However, it does include padding of any variable-length
>>>> parameter except the last parameter in the chunk. The receiver
>>>> MUST ignore the padding.
>>>> Note: A robust implementation should accept the chunk whether or
>>>> not the final padding has been included in the Chunk Length.
>>>> So I changed the code to make the "except the last parameter in the chunk"
>>>> visible. At least this made me aware of a bug in the FreeBSD implementation.
>>>> So we should have such an expert info.
>>> I have to admit that exception confused me greatly. I was going to ask the tsvwg about it. I'm not quite sure I see the point. And of course there's no key word (MUST, SHOULD) to tell us how important is the exception. My presumption would be not many implementations would blow up if the exception were not taken into account--thus my comment about maybe including the expert info but not making it PI_ERROR. PI_NOTE maybe?
>> FreeBSD doesn't follow the RFC currently. I'm fixing this right now...
>> I don't think the level makes much of a difference. I was surprised
>> that FreeBSD doesn't do it correctly, so I really want the expert
>> warning to find also other problems and fix it. Without being aware
>> of it, it wouldn't be fixed.
>
> OK, makes sense. But PI_ERROR should normally be reserved for real errors (things which are wrong and likely to cause problems); I reduced the warning down to a NOTE (r46401) so people can be aware but without making them think they've got a serious interop problem. (I'm guessing FreeBSD's been interop'ing like this without problems for a while now. :-))
I think it is an error, but RFC4960 also states:
Note: A robust implementation should accept the chunk whether or
not the final padding has been included in the Chunk Length.
So I guess most SCTP implementations classify as "robust", even FreeBSD, since
it can talk to itself. So the impact of the error is limited...
Best regards
Michael
> ___________________________________________________________________________
> Sent via: Wireshark-dev mailing list <wireshark-dev@xxxxxxxxxxxxx>
> Archives: http://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
> mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe
>
