https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=5651
--- Comment #3 from Sake <sake@xxxxxxxxxx> 2011-02-03 11:12:27 PST ---
(In reply to comment #0)
> The minimum TCP header length with one TCP option is 32. If it's > 20 but <
> 32, the capture has been frame-sliced.
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.
> If so, the code that dissects the
> options field should be skipped; otherwise, an exception gets thrown which
> prevents the packet from being analyzed (tcp_analyze_seq) if configured to do
> so.
> Note the TCP analysis feature does not use or require any of the info in the
> options field including such things as SACK ranges, so there is no do downside
> to allowing analysis to proceed when the options field is truncated provided
> the entire 20-byte TCP header is intact.
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.
--
Configure bugmail: https://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
