Huge thanks to our Platinum Members Endace and LiveAction,
and our Silver Member Veeam, for supporting the Wireshark Foundation and project.

Wireshark-bugs: [Wireshark-bugs] [Bug 3998] New: tshark with a read filter of smb.response_in do

Date: Thu, 10 Sep 2009 13:27:16 -0700 (PDT)
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=3998

           Summary: tshark with a read filter of smb.response_in does not
                    output SMB REQs to which there is a response
           Product: Wireshark
           Version: 1.2.1
          Platform: x86
        OS/Version: Windows XP
            Status: NEW
          Severity: Normal
          Priority: Low
         Component: TShark
        AssignedTo: wireshark-bugs@xxxxxxxxxxxxx
        ReportedBy: jdicker@xxxxxx


Build Information:
C:\Program Files\Wireshark>tshark -v
Could not open file: 'eap.xml', error: No such file or directory
TShark 1.2.1 (SVN Rev 29141)

Copyright 1998-2009 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.20.3, with WinPcap (version unknown), with libz 1.2.3,
without POSIX capabilities, with libpcre 7.0, with SMI 0.4.8, with c-ares
1.6.0,

with Lua 5.1, with GnuTLS 2.8.1, with Gcrypt 1.4.4, with MIT Kerberos, with
GeoIP.

Running on Windows XP Service Pack 3, build 2600, with WinPcap version 4.1
beta5

(packet.dll version 4.1.0.1452), based on libpcap version 1.0.0, GnuTLS 2.8.1,
Gcrypt 1.4.4.

Built using Microsoft Visual C++ 9.0 build 30729
--
I am trying to run tshark with the -R option to filter SMB Requests that go
unanswered. 

tshark.exe -R "(smb.flags.response == 0) and not(smb.response_in)" -r
C:\smb.cap

When I use Wireshark Locking smb.cmd 0x24 and others are displayed while tshark
displays all the SMB Requests.

Maybe this is an issue with all derived information where the next packet is
needed to populate the derived information for the Request?

I turned off and on tcp allow subdissector reassembly, to no avail. I have an
Ubuntu machine running:

ene@ene01:~$ tshark -v
TShark 1.0.7

And that does not work either.

An easy way to reproduce the issue, if neccessary, is to get a small capture of
smb traffic and filter using -R smb.response_in. In my experience tshark does
not list any packets.

- John


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