https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=5651
Cal Turney <turney_cal@xxxxxxx> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |turney_cal@xxxxxxx
--- Comment #4 from Cal Turney <turney_cal@xxxxxxx> 2011-02-03 13:21:49 PST ---
(In reply to comment #3)
> (In reply to comment #0)
>
> I just checked the RFC and it does not state that the options should always be
> 12 bytes long. It just states that it needs to be a multiple of 32 bits. That > > means it can also be 4 or 8 bytes long.
> Also, your patch won't work for packets that have 32 bytes of options which get > cut after the 30th bytes of the options.
> I agree that when a snaplength is used that cuts part of the TCP options off,
> TCP analysis should still take place. Maybe a better way to handle this is to
> check whether a snaplength is indeed responsible for having only part of the
> TCP options and forget about dissecting them (although it would still be nice
> to dissect the ones that have not been cut off). If snaplength was not
> responsible, it still makes sense to throw the exception.
I agree that options can be far smaller than 12 bytes. In fact the SACK
permitted option requires only 2 bytes. Good catch. Thanks.
Is there any reason why the analysis should not take place before the options
are dissected? If not, that would be the easiest way to go. If it's not a
good idea, the goal would be to dissect all the options that are intact, only
throw an exception if the snaplen was not responsible for the inability to
dissect an option, and otherwise to allow the analysis of the TCP header to
proceed if requested. Let me know if you'd prefer to work on this. If not, I'll
get started.
--
Configure bugmail: https://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
