Wireshark-bugs: [Wireshark-bugs] [Bug 7607] New: Websocket analyzer wrongly reporting Malformed
Date Index · Thread Index · Other Months · All Mailing Lists
Date Prev · Date Next · Thread Prev · Thread Next
From: bugzilla-daemon@xxxxxxxxxxxxx
Date: Wed, 8 Aug 2012 18:53:56 -0700 (PDT)
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=7607

           Summary: Websocket analyzer wrongly reporting Malformed packets
           Product: Wireshark
           Version: 1.8.1
          Platform: x86
        OS/Version: Windows 7
            Status: NEW
          Severity: Normal
          Priority: Low
         Component: Wireshark
        AssignedTo: bugzilla-admin@xxxxxxxxxxxxx
        ReportedBy: simon@xxxxxxxxxxxxxxxx


Created attachment 8926
  --> https://bugs.wireshark.org/bugzilla/attachment.cgi?id=8926
websocket packet capture

Build Information:
Version 1.8.1 (SVN Rev 43946 from /trunk-1.8)

Copyright 1998-2012 Gerald Combs <gerald@xxxxxxxxxxxxx> and contributors.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Compiled (64-bit) with GTK+ 2.24.10, with Cairo 1.10.2, with Pango 1.30.0, with
GLib 2.32.2, with WinPcap (4_1_2), with libz 1.2.5, without POSIX capabilities,
with SMI 0.4.8, with c-ares 1.7.1, with Lua 5.1, without Python, with GnuTLS
2.12.18, with Gcrypt 1.4.6, without Kerberos, with GeoIP, with PortAudio
V19-devel (built Jul 23 2012), with AirPcap.

Running on 64-bit Windows 7 Service Pack 1, build 7601, with WinPcap version
4.1.2 (packet.dll version 4.1.0.2001), based on libpcap version 1.0 branch
1_0_rel0b (20091008), GnuTLS 2.12.18, Gcrypt 1.4.6, without AirPcap.

Built using Microsoft Visual C++ 10.0 build 40219
--
When a websocket message from a server to a host is split into multiple tcpip
packets on the wire the WebSocket decoding incorrectly reports a malformed
packet on the first packet and gets confused by the remaining parts of the
websocket message in subsequent packets.

I have attached a capture file that shows this.  In the capture 10.0.1.70 is
the server and 10.0.1.30 is the client.  The packets that contain the long
websocket message are 66,67,69 and 70.  This is a perfectly legal message
according to RFC6455 and is being received by the client correctly (chrome
browser).

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