Wireshark-bugs: [Wireshark-bugs] [Bug 6194] fixes for SCPS TCP option

Date: Fri, 11 Nov 2011 18:15:51 -0800 (PST)
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=6194

Eric Travis <eric.dot.travis@xxxxxxxxx> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
                 CC|                            |eric.dot.travis@xxxxxxxxx
         Resolution|FIXED                       |

--- Comment #3 from Eric Travis <eric.dot.travis@xxxxxxxxx> 2011-11-11 18:15:49 PST ---
See Bug 6562 for more detailed explanation and corrective patches


The modifications made are incorrect in function;

Wireshark *was* properly handling the included pcap file regarding 
the malformed TCP Options. 

I can easily modify any random TCP implementation to include 2-octet SACK 
options on every TCP segment, but that doesn't mean Wireshark should be 
altered so that they don't get flagged as malformed.

    SCPS(TCP Option 20) is:

        -  a variable length option with a minimum length of 4, NOT 2.

        -  As a negotiated option, it is legal only on segments where 
           the SYN flag is set, NOT during an established connection flow.

     If SCPS capabilities are not successfully negotiated during
           connection handshake, no SCPS-related options are legitimate
           and wireshark's flagging occurrences as illegal helps developers
           debug implementations (such as the source of the triggering
           implementation)

     The on-the-wire bit specification of the three reserved bits was 
     correct (read: as specified) prior to modification.

If unfamiliar with the specification of the SCPS TCP enhancements,
please refer to (http://public.ccsds.org/publications/archive/714x0b2.pdf)
Specifically Section 3.2.4 & Section 3.2.5 for this bug.

Wireshark is an invaluable tool for developers, even more so when it can be
depended on to parse correctly.

Rather than simply trusting the contents of a packet trace (regardless of
the source), it is best to verify the CORRECTNESS of observed behavior (per
protocol specification) prior to altering Wireshark behavior so it conforms 
to the illustrative trace.

Sorry if this comes off harsh, but the existing comments in the pre-patched
packet-tcp.c should have *at least* prompted a slight pause prior to 
committing the patch.  This bug took less than 12-hours from submission to 
resolution...

-- 
Configure bugmail: https://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.