Wireshark-bugs: [Wireshark-bugs] [Bug 3293] New: HTTP packet not recognized in some occasions

Date: Mon, 2 Mar 2009 02:10:49 -0800 (PST)
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=3293

           Summary: HTTP packet not recognized in some occasions
           Product: Wireshark
           Version: 1.0.5
          Platform: PC
        OS/Version: Red Hat
            Status: NEW
          Severity: Normal
          Priority: Low
         Component: TShark
        AssignedTo: wireshark-bugs@xxxxxxxxxxxxx
        ReportedBy: baboinen@xxxxxxxxx


Created an attachment (id=2794)
 --> (https://bugs.wireshark.org/bugzilla/attachment.cgi?id=2794)
The capture and the XML format of the capture

Build Information:
[root@LASS-pc-1 tmp]# tshark -v
TShark 1.0.5

Copyright 1998-2008 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 with GLib 2.16.6, with libpcap 0.9.8, with libz 1.2.3, without POSIX
capabilities, with libpcre 7.3, without SMI, without ADNS, without Lua, with
GnuTLS 2.0.4, with Gcrypt 1.4.0, with MIT Kerberos.

Running on Linux 2.6.25-14.fc9.i686, with libpcap version 0.9.8.

Built using gcc 4.3.0 20080428 (Red Hat 4.3.0-8).

--
Depending on the content of the HTTP the packet might be not recognized.

I use the wireshark on linux box and open/save packets into XML format (-T
pdml) into a text file which is then analyzed. After some text parsing I
noticed some packets were not shown correctly. opening it on Windows box with
wireshark 1.0.4 showed the packet correctly but the XML format from linux box
was not.

Attachment traces_new.cap.zip contains the full traces in which is the packet
in question. The packet 24 gets opened with 1.0.4 on windows box but when the
same file I push through: tshark -V -r traces_athens.0.9.cap > traces.xml

the file traces.xml doesn't contain the packet in question correctly dissected.
Hint: search through for POST and you will find the first packet "POST" only
inside the data part of the packet while the second packet (the previous
encapsulated into the GTP) is dissected correctly.

The behavior somehow looks like a bug 1958
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=1958

I am not sure if these traces help anything but though to report it anyway.

Slaven


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