[Wireshark-bugs] [Bug 13221] OpenFlow error messages dissected incorrectly

[bugzilla-daemon]

https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=13221

Alexis La Goutte  changed:

   What|Removed |Added

 CC||alexis.lagou...@gmail.com

-- 
You are receiving this mail because:
You are watching all bug changes.
___
Sent via:Wireshark-bugs mailing list 
Archives:https://www.wireshark.org/lists/wireshark-bugs
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-bugs
 mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe

[Wireshark-bugs] [Bug 13221] OpenFlow error messages dissected incorrectly

[bugzilla-daemon]

https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=13221

--- Comment #1 from Arc  ---
Created attachment 15116
  --> https://bugs.wireshark.org/bugzilla/attachment.cgi?id=15116=edit
Graphical explanations of the error

-- 
You are receiving this mail because:
You are watching all bug changes.
___
Sent via:Wireshark-bugs mailing list 
Archives:https://www.wireshark.org/lists/wireshark-bugs
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-bugs
 mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe

[Wireshark-bugs] [Bug 13221] New: OpenFlow error messages dissected incorrectly

[bugzilla-daemon]

https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=13221

Bug ID: 13221
   Summary: OpenFlow error messages dissected incorrectly
   Product: Wireshark
   Version: 2.2.1
  Hardware: All
OS: Linux (other)
Status: UNCONFIRMED
  Severity: Major
  Priority: Low
 Component: Dissection engine (libwireshark)
  Assignee: bugzilla-ad...@wireshark.org
  Reporter: zenta...@rambler.ru

Created attachment 15115
  --> https://bugs.wireshark.org/bugzilla/attachment.cgi?id=15115=edit
pcap with error message

Build Information:
Version 2.2.1 (Git Rev Unknown from unknown)

Copyright 1998-2016 Gerald Combs  and contributors.
License GPLv2+: GNU GPL version 2 or later

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 Qt 5.2.1, with libpcap, with POSIX capabilities (Linux),
with libnl 3, with GLib 2.40.2, with zlib 1.2.8, with SMI 0.4.8, with c-ares
1.10.0, with Lua 5.2.3, with GnuTLS 2.12.23, with Gcrypt 1.5.3, with MIT
Kerberos, with GeoIP, with nghttp2 0.6.7, with QtMultimedia, without AirPcap.

Running on Linux 4.2.0-42-generic, with locale ru_RU.UTF-8, with libpcap
version
1.7.4, with GnuTLS 2.12.23, with Gcrypt 1.5.3, with zlib 1.2.8.
Intel(R) Core(TM) i7 CPU 870  @ 2.93GHz (with SSE4.2)

Built using gcc 4.8.4.
--
Usually the Openflow error message body includes caused the error Openflow
message:

Quote from Openflow 1.3.5 spec
(https://www.opennetworking.org/images/stories/downloads/sdn-resources/onf-specifications/openflow/openflow-switch-v1.3.5.pdf)
page 114:
"
The field data is variable in length and interpreted based on the type and
code. Unless specified
otherwise, the data field contains at least 64 bytes of the failed request that
caused the error message
to be generated, if the failed request is shorter than 64 bytes it should be
the full request without any
padding.
"
But wireshark can not properly parse the error message body. Now he examines
only the few first fields of Openflow message (Version,Type,Length and
TransactionID). But fields as Match, Instructions, Role, GenerationId, Cookie,
Cookie mask, Idle_timeout, Hard_timeout, Command, Flags, Buffer ID, Out group,
Out port, etc... is not showing in human-readable form. These problem making
troubleshooting harder. pcap with error in attachement.

-- 
You are receiving this mail because:
You are watching all bug changes.
___
Sent via:Wireshark-bugs mailing list 
Archives:https://www.wireshark.org/lists/wireshark-bugs
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-bugs
 mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe

[Wireshark-bugs] [Bug 13220] New: Buildbot crash output: fuzz-2016-12-07-3380.pcap

[bugzilla-daemon]

https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=13220

Bug ID: 13220
   Summary: Buildbot crash output: fuzz-2016-12-07-3380.pcap
   Product: Wireshark
   Version: unspecified
  Hardware: x86-64
   URL: https://www.wireshark.org/download/automated/captures/
fuzz-2016-12-07-3380.pcap
OS: Ubuntu
Status: CONFIRMED
  Severity: Major
  Priority: High
 Component: Dissection engine (libwireshark)
  Assignee: bugzilla-ad...@wireshark.org
  Reporter: buildbot-do-not-re...@wireshark.org

Problems have been found with the following capture file:

https://www.wireshark.org/download/automated/captures/fuzz-2016-12-07-3380.pcap

stderr:
Input file: /home/wireshark/menagerie/menagerie/12802-iser_login.pcap

Build host information:
Linux wsbb04 4.4.0-47-generic #68-Ubuntu SMP Wed Oct 26 19:39:52 UTC 2016
x86_64 x86_64 x86_64 GNU/Linux
Distributor ID:Ubuntu
Description:Ubuntu 16.04.1 LTS
Release:16.04
Codename:xenial

Buildbot information:
BUILDBOT_REPOSITORY=ssh://wireshark-build...@code.wireshark.org:29418/wireshark
BUILDBOT_WORKERNAME=clang-code-analysis
BUILDBOT_BUILDNUMBER=3811
BUILDBOT_URL=http://buildbot.wireshark.org/wireshark-master/
BUILDBOT_BUILDERNAME=Clang Code Analysis
BUILDBOT_GOT_REVISION=49fcee3fcb997036f8677af081a5cbecab7c07e0

Return value:  0

Dissector bug:  0

Valgrind error count:  1



Git commit
commit 49fcee3fcb997036f8677af081a5cbecab7c07e0
Author: Роман Донченко 
Date:   Wed Dec 7 01:14:39 2016 +0300

Qt: don't append a second extension to save file names

When checking if the file already has one of the possible extensions,
MainWindow::fileAddExtension reuses file_suffix between iterations and
appends to it each time, so it ends up checking for the wrong suffix for
all
extensions except the first one. Scope file_suffix to the for loop to
fix that.

Change-Id: Idbc5a619a4793d8c477bfd88305cdb44ea844e13
Reviewed-on: https://code.wireshark.org/review/19123
Petri-Dish: Gerald Combs 
Tested-by: Petri Dish Buildbot 
Reviewed-by: Gerald Combs 


==8280== Memcheck, a memory error detector
==8280== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
==8280== Using Valgrind-3.11.0 and LibVEX; rerun with -h for copyright info
==8280== Command:
/home/wireshark/builders/wireshark-master-fuzz/clangcodeanalysis/install.plain/bin/tshark
-nr /fuzz/buildbot/clangcodeanalysis/valgrind-fuzz/fuzz-2016-12-07-3380.pcap
==8280== 
==8280== Invalid read of size 2
==8280==at 0x69977A1: ib_addr_to_str (address_types.c:451)
==8280==by 0x699FF6C: col_set_addr (column-utils.c:1913)
==8280==by 0x699FE57: col_fill_in (column-utils.c:2180)
==8280==by 0x416797: print_packet (tshark.c:3852)
==8280==by 0x416389: process_packet (tshark.c:3492)
==8280==by 0x4140D1: load_cap_file (tshark.c:3234)
==8280==by 0x4140D1: main (tshark.c:1934)
==8280==  Address 0xffefff5f0 is on thread 1's stack
==8280==  2336 bytes below stack pointer
==8280== 
==8280== 
==8280== HEAP SUMMARY:
==8280== in use at exit: 6,083,166 bytes in 9,742 blocks
==8280==   total heap usage: 293,197 allocs, 283,455 frees, 38,048,802 bytes
allocated
==8280== 
==8280== LEAK SUMMARY:
==8280==definitely lost: 360 bytes in 87 blocks
==8280==indirectly lost: 0 bytes in 0 blocks
==8280==  possibly lost: 0 bytes in 0 blocks
==8280==still reachable: 6,082,806 bytes in 9,655 blocks
==8280== suppressed: 0 bytes in 0 blocks
==8280== Rerun with --leak-check=full to see details of leaked memory
==8280== 
==8280== For counts of detected and suppressed errors, rerun with: -v
==8280== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)

[ no debug trace ]

-- 
You are receiving this mail because:
You are watching all bug changes.
___
Sent via:Wireshark-bugs mailing list 
Archives:https://www.wireshark.org/lists/wireshark-bugs
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-bugs
 mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe

[Wireshark-bugs] [Bug 13212] Wireshark shows "MS Video Source Request" in a RTCP packet as "Malformed"

[bugzilla-daemon]

https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=13212

--- Comment #11 from Gerrit Code Review  ---
Change 19141 had a related patch set uploaded by Michael Mann:
RTCP: Bugfix MS Video Source Request dissection

https://code.wireshark.org/review/19141

-- 
You are receiving this mail because:
You are watching all bug changes.
___
Sent via:Wireshark-bugs mailing list 
Archives:https://www.wireshark.org/lists/wireshark-bugs
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-bugs
 mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe

[Wireshark-bugs] [Bug 13212] Wireshark shows "MS Video Source Request" in a RTCP packet as "Malformed"

[bugzilla-daemon]

https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=13212

--- Comment #9 from Gerrit Code Review  ---
Change 19140 had a related patch set uploaded by Michael Mann:
RTCP: Bugfix MS Video Source Request dissection

https://code.wireshark.org/review/19140

-- 
You are receiving this mail because:
You are watching all bug changes.
___
Sent via:Wireshark-bugs mailing list 
Archives:https://www.wireshark.org/lists/wireshark-bugs
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-bugs
 mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe

[Wireshark-bugs] [Bug 13202] RPC-over-RDMA dissector no longer identifies any valid rpc/rdma frames

[bugzilla-daemon]

https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=13202

--- Comment #13 from Parav Pandit  ---
(In reply to Chuck Lever from comment #12)
> (In reply to Parav Pandit from comment #11)
> > (In reply to Chuck Lever from comment #8)
> > > Just as a data point, I applied the packet-infiniband.c diff from change
> > > 19107 on top of my tree with conversation logic removed from
> > > packet-rpcrdma.c. It does not change the behavior of the RPC dissector.
> > > 
> > Sorry, I didn't follow. Do you see them as Infiniband frames or as
> > RPC/PortMap/NFS frames after applying my patch?
> > 
> > With the pcap trace of bug 13213, with my change 19107 I am able to see them
> > as NFS/RPC frames.
> 
> Before changing anything, only the raw InfiniBand traffic appeared.
> 
> After removing the find_or_create_conversation() call site from
> packet-rpcrdma.c as 19107 does, RPC Calls were properly decoded as NFS
> requests, but RPC Replies appeared as "RPC ### V0 proc-0 Reply". This means
> the RPC dissector was not able to match the XID of each Reply to a previous
> Call message.
> 
> Though this is still broken, this is the until-now normal behavior for
> RPC-over-RDMA, up until the "remove duplicate conversations from
> packet-infiniband.c" patch. In a capture of NFS on IPoIB or NFS on TCP, you
> will see the proper expected way NFS Replies are supposed to appear.
> 
> After I applied the packet-infiniband.c hunk of 19107, nothing changed.
> 
> Thus my humble conclusion is that the packet-rpcrdma.c hunk of 19107 is the
> part that fixes the regression introduced by "remove duplication
> conversations" . The packet-infiniband.c hunk does not appear to change the
> behavior of either the RPC or RPC-over-RDMA dissector.
> 
> 
> > > I've filed bug 13213 to separately document the RPC reply dissection 
> > > failure.
> 
> I'll attach my fix to 13213, and we can compare and discuss both approaches.
> I see why fixing packet-infiniband.c might affect more ULP dissectors, and
> thus it might be a more broad fix. Getting PT_IBQP and PT_TCP conversations
> to behave more alike is probably a desirable long-term goal. 

Yes. This is required at minimum.

> But 19107 is
> either not quite right, or somehow it is not enough for RPC. (Probably the
> latter).
I think its later. Without reading the code of packet-rpc.c I added few debug
prints as below and I can see why it might not work for rpc as rpc might want
to work on TCP level ports from portmap vs qp number?

update_sport frame=13 updating sport = 546, dport=525
get_conversation_for_call frame=13 sport=55562 dport=111 conv=0x7f205dab1830

I am not able to comprehend how would ignoring src_qp in your patch fixes it.

> 
> It may be that the packet-infiniband.c hunk of 19107 is still appropriate to
> apply.
> I just wanted to note, however, that change by itself does not appear
> to address either 13202 or 13213 (unless I've done something wrong).

So I will drop the bug number from commit msg and still go ahead with the
change as its needed.

-- 
You are receiving this mail because:
You are watching all bug changes.
___
Sent via:Wireshark-bugs mailing list 
Archives:https://www.wireshark.org/lists/wireshark-bugs
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-bugs
 mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe

[Wireshark-bugs] [Bug 13193] Support for DTLS-SRTP (used by WebRTC) with SIP signalling over Websockets

[bugzilla-daemon]

https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=13193

--- Comment #5 from Gerrit Code Review  ---
Change 19139 had a related patch set uploaded by Peter Wu:
sdp: decode pt for more RTP transport protocols

https://code.wireshark.org/review/19139

-- 
You are receiving this mail because:
You are watching all bug changes.
___
Sent via:Wireshark-bugs mailing list 
Archives:https://www.wireshark.org/lists/wireshark-bugs
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-bugs
 mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe

[Wireshark-bugs] [Bug 13219] Buildbot crash output: fuzz-2016-12-07-9609.pcap

[bugzilla-daemon]

https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=13219

Guy Harris  changed:

   What|Removed |Added

 Status|RESOLVED|CONFIRMED
 Resolution|FIXED   |---

--- Comment #3 from Guy Harris  ---
No, that's not the problem here.

-- 
You are receiving this mail because:
You are watching all bug changes.
___
Sent via:Wireshark-bugs mailing list 
Archives:https://www.wireshark.org/lists/wireshark-bugs
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-bugs
 mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe

[Wireshark-bugs] [Bug 13219] Buildbot crash output: fuzz-2016-12-07-9609.pcap

[bugzilla-daemon]

https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=13219

Gerrit Code Review  changed:

   What|Removed |Added

 Status|CONFIRMED   |RESOLVED
 Resolution|--- |FIXED

-- 
You are receiving this mail because:
You are watching all bug changes.
___
Sent via:Wireshark-bugs mailing list 
Archives:https://www.wireshark.org/lists/wireshark-bugs
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-bugs
 mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe

[Wireshark-bugs] [Bug 13219] Buildbot crash output: fuzz-2016-12-07-9609.pcap

[bugzilla-daemon]

https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=13219

--- Comment #1 from Gerrit Code Review  ---
Change 19136 had a related patch set uploaded by Guy Harris:
Don't use a local variable's address in set_address().

https://code.wireshark.org/review/19136

-- 
You are receiving this mail because:
You are watching all bug changes.
___
Sent via:Wireshark-bugs mailing list 
Archives:https://www.wireshark.org/lists/wireshark-bugs
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-bugs
 mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe

[Wireshark-bugs] [Bug 13044] Buildbot crash output: fuzz-2016-10-25-19751.pcap

[bugzilla-daemon]

https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=13044

Peter Wu  changed:

   What|Removed |Added

 Status|CONFIRMED   |RESOLVED
 Resolution|--- |FIXED

--- Comment #24 from Peter Wu  ---
The latest build from v2.3.0rc0-1673-g29768d9 contains v2.3.0rc0-1666-g47829b9
which seems to have fixed the buildbot valgrind issue.

https://buildbot.wireshark.org/wireshark-master/builders/Clang%20Code%20Analysis/builds/3809

-- 
You are receiving this mail because:
You are watching all bug changes.
___
Sent via:Wireshark-bugs mailing list 
Archives:https://www.wireshark.org/lists/wireshark-bugs
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-bugs
 mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe

[Wireshark-bugs] [Bug 13203] Buildbot crash output: fuzz-2016-12-05-23758.pcap

[bugzilla-daemon]

https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=13203

Peter Wu  changed:

   What|Removed |Added

 Status|CONFIRMED   |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #4 from Peter Wu  ---
Marking as duplicate since it is exactly the same error, and both point to the
same variable.

*** This bug has been marked as a duplicate of bug 13044 ***

-- 
You are receiving this mail because:
You are watching all bug changes.
___
Sent via:Wireshark-bugs mailing list 
Archives:https://www.wireshark.org/lists/wireshark-bugs
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-bugs
 mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe

[Wireshark-bugs] [Bug 13044] Buildbot crash output: fuzz-2016-10-25-19751.pcap

[bugzilla-daemon]

https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=13044

--- Comment #23 from Peter Wu  ---
*** Bug 13203 has been marked as a duplicate of this bug. ***

-- 
You are receiving this mail because:
You are watching all bug changes.
___
Sent via:Wireshark-bugs mailing list 
Archives:https://www.wireshark.org/lists/wireshark-bugs
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-bugs
 mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe

[Wireshark-bugs] [Bug 13219] New: Buildbot crash output: fuzz-2016-12-07-9609.pcap

[bugzilla-daemon]

https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=13219

Bug ID: 13219
   Summary: Buildbot crash output: fuzz-2016-12-07-9609.pcap
   Product: Wireshark
   Version: unspecified
  Hardware: x86-64
   URL: https://www.wireshark.org/download/automated/captures/
fuzz-2016-12-07-9609.pcap
OS: Ubuntu
Status: CONFIRMED
  Severity: Major
  Priority: High
 Component: Dissection engine (libwireshark)
  Assignee: bugzilla-ad...@wireshark.org
  Reporter: buildbot-do-not-re...@wireshark.org

Problems have been found with the following capture file:

https://www.wireshark.org/download/automated/captures/fuzz-2016-12-07-9609.pcap

stderr:
Input file: /home/wireshark/menagerie/menagerie/13651-nfsv4rdma_mount.pcap

Build host information:
Linux wsbb04 4.4.0-47-generic #68-Ubuntu SMP Wed Oct 26 19:39:52 UTC 2016
x86_64 x86_64 x86_64 GNU/Linux
Distributor ID:Ubuntu
Description:Ubuntu 16.04.1 LTS
Release:16.04
Codename:xenial

Buildbot information:
BUILDBOT_REPOSITORY=ssh://wireshark-build...@code.wireshark.org:29418/wireshark
BUILDBOT_WORKERNAME=clang-code-analysis
BUILDBOT_BUILDNUMBER=3810
BUILDBOT_URL=http://buildbot.wireshark.org/wireshark-master/
BUILDBOT_BUILDERNAME=Clang Code Analysis
BUILDBOT_GOT_REVISION=f39389e945e11a82905bc5b71ada85f3b90e9bab

Return value:  0

Dissector bug:  0

Valgrind error count:  1



Git commit
commit f39389e945e11a82905bc5b71ada85f3b90e9bab
Author: Chuck Lever 
Date:   Tue Dec 6 11:25:59 2016 -0500

packet-rpcrdma: Fix selection size in chunk list dissectors

Use proto_item_set_len instead of walking the packet ahead of time
trying to compute the size.

Change-Id: I5eb3da1fef45895853cb5b6b198d0310394e4176
Signed-off-by: Chuck Lever 
Reviewed-on: https://code.wireshark.org/review/19120
Reviewed-by: Michael Mann 
Petri-Dish: Michael Mann 
Tested-by: Petri Dish Buildbot 
Reviewed-by: Anders Broman 


==18459== Memcheck, a memory error detector
==18459== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
==18459== Using Valgrind-3.11.0 and LibVEX; rerun with -h for copyright info
==18459== Command:
/home/wireshark/builders/wireshark-master-fuzz/clangcodeanalysis/install.plain/bin/tshark
-nr /fuzz/buildbot/clangcodeanalysis/valgrind-fuzz/fuzz-2016-12-07-9609.pcap
==18459== 
==18459== Invalid read of size 2
==18459==at 0x69977C1: ib_addr_to_str (address_types.c:451)
==18459==by 0x699FF8C: col_set_addr (column-utils.c:1913)
==18459==by 0x699FE77: col_fill_in (column-utils.c:2180)
==18459==by 0x416797: print_packet (tshark.c:3852)
==18459==by 0x416389: process_packet (tshark.c:3492)
==18459==by 0x4140D1: load_cap_file (tshark.c:3234)
==18459==by 0x4140D1: main (tshark.c:1934)
==18459==  Address 0xffefff5f0 is on thread 1's stack
==18459==  2336 bytes below stack pointer
==18459== 
==18459== 
==18459== HEAP SUMMARY:
==18459== in use at exit: 6,085,214 bytes in 9,743 blocks
==18459==   total heap usage: 266,280 allocs, 256,537 frees, 37,335,172 bytes
allocated
==18459== 
==18459== LEAK SUMMARY:
==18459==definitely lost: 360 bytes in 87 blocks
==18459==indirectly lost: 0 bytes in 0 blocks
==18459==  possibly lost: 0 bytes in 0 blocks
==18459==still reachable: 6,084,854 bytes in 9,656 blocks
==18459== suppressed: 0 bytes in 0 blocks
==18459== Rerun with --leak-check=full to see details of leaked memory
==18459== 
==18459== For counts of detected and suppressed errors, rerun with: -v
==18459== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)

[ no debug trace ]

-- 
You are receiving this mail because:
You are watching all bug changes.
___
Sent via:Wireshark-bugs mailing list 
Archives:https://www.wireshark.org/lists/wireshark-bugs
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-bugs
 mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe

[Wireshark-bugs] [Bug 13218] extcap: help page configuration mismatch

[bugzilla-daemon]

https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=13218

Stig Bjørlykke  changed:

   What|Removed |Added

 CC||lom...@gmail.com,
   ||rkn...@gmail.com

-- 
You are receiving this mail because:
You are watching all bug changes.
___
Sent via:Wireshark-bugs mailing list 
Archives:https://www.wireshark.org/lists/wireshark-bugs
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-bugs
 mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe

[Wireshark-bugs] [Bug 13218] New: extcap: help page configuration mismatch

[bugzilla-daemon]

https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=13218

Bug ID: 13218
   Summary: extcap: help page configuration mismatch
   Product: Wireshark
   Version: Git
  Hardware: All
OS: All
Status: UNCONFIRMED
  Severity: Normal
  Priority: Low
 Component: Extras
  Assignee: bugzilla-ad...@wireshark.org
  Reporter: s...@bjorlykke.org

Build Information:
Paste the COMPLETE build information from "Help->About Wireshark", "wireshark
-v", or "tshark -v".
--
The extcap help page link can be configured in the "extcap" entry when dumping
--extcap-interfaces.  This is printed in extcap_print_version() and the output
looks like this:

  extcap {version=1.0}{help=http://www.wireshark.org}
  interface {value=interface1}{display=Interface ONE}

But in extcap_get_help_for_ifname() the help entry is fetched from the
"interface" entry, which will never be set when using the extcap-base functions
or using code examples from extcap_example.py.

The help button works correct if putting the {help=} in the "interface" entry,
but this is not supported in the extcap-base framework.


Another bug is that the default help page points to this address which does not
exist:

  https://www.wireshark.org/docs/wsug_html_chunked/ChExtcapOptions.html

-- 
You are receiving this mail because:
You are watching all bug changes.
___
Sent via:Wireshark-bugs mailing list 
Archives:https://www.wireshark.org/lists/wireshark-bugs
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-bugs
 mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe

[Wireshark-bugs] [Bug 13212] Wireshark shows "MS Video Source Request" in a RTCP packet as "Malformed"

[bugzilla-daemon]

https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=13212

--- Comment #8 from Vitaly  ---
Change 19126 fixes the current bug. 
I've mentioned about "length" because there could be a bug then "length" of
MS-DSH and "length" of a RTPC packet aren't synchronized. But if a RTCP packet
is correct than all work fine.
Thanks.

-- 
You are receiving this mail because:
You are watching all bug changes.
___
Sent via:Wireshark-bugs mailing list 
Archives:https://www.wireshark.org/lists/wireshark-bugs
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-bugs
 mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe

[Wireshark-bugs] [Bug 13215] Buildbot crash output: fuzz-2016-12-07-6687.pcap

[bugzilla-daemon]

https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=13215

--- Comment #2 from Gerald Combs  ---
(In reply to Michael Mann from comment #1)

> However, the Change-Id listed for the commit is for the cherry-pick done to
> the master-2.2 and master-2.0 branches, but buildbot URLS, etc. claim this
> is from master branch.  Did something break and we don't distinguish master
> from 2.2 and 2.0 properly on the buildbot?

The recent Gerrit upgrade changed the event stream format slightly to include
full branch paths instead of plain branch names. It took me a couple of tries
to update the master Buildbot configuration correctly. As a result it was
building from all branches for a short time.

-- 
You are receiving this mail because:
You are watching all bug changes.
___
Sent via:Wireshark-bugs mailing list 
Archives:https://www.wireshark.org/lists/wireshark-bugs
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-bugs
 mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe

[Wireshark-bugs] [Bug 13213] RPC dissector doesn't match Replies to Calls with RPC-over-RDMA transports

[bugzilla-daemon]

https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=13213

--- Comment #5 from Chuck Lever  ---
The destination port for the client-to-server conversation does not match
either the source port or the destination port for the server-to-client
conversation. This defeats the RPC dissector's conversation-based XID matching
mechanism.

-- 
You are receiving this mail because:
You are watching all bug changes.
___
Sent via:Wireshark-bugs mailing list 
Archives:https://www.wireshark.org/lists/wireshark-bugs
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-bugs
 mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe

[Wireshark-bugs] [Bug 13213] RPC dissector doesn't match Replies to Calls with RPC-over-RDMA transports

[bugzilla-daemon]

https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=13213

--- Comment #4 from Chuck Lever  ---
Created attachment 15113
  --> https://bugs.wireshark.org/bugzilla/attachment.cgi?id=15113=edit
Possible fix for 13213

-- 
You are receiving this mail because:
You are watching all bug changes.
___
Sent via:Wireshark-bugs mailing list 
Archives:https://www.wireshark.org/lists/wireshark-bugs
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-bugs
 mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe

[Wireshark-bugs] [Bug 13202] RPC-over-RDMA dissector no longer identifies any valid rpc/rdma frames

[bugzilla-daemon]

https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=13202

--- Comment #12 from Chuck Lever  ---
(In reply to Parav Pandit from comment #11)
> (In reply to Chuck Lever from comment #8)
> > Just as a data point, I applied the packet-infiniband.c diff from change
> > 19107 on top of my tree with conversation logic removed from
> > packet-rpcrdma.c. It does not change the behavior of the RPC dissector.
> > 
> Sorry, I didn't follow. Do you see them as Infiniband frames or as
> RPC/PortMap/NFS frames after applying my patch?
> 
> With the pcap trace of bug 13213, with my change 19107 I am able to see them
> as NFS/RPC frames.

Before changing anything, only the raw InfiniBand traffic appeared.

After removing the find_or_create_conversation() call site from
packet-rpcrdma.c as 19107 does, RPC Calls were properly decoded as NFS
requests, but RPC Replies appeared as "RPC ### V0 proc-0 Reply". This means the
RPC dissector was not able to match the XID of each Reply to a previous Call
message.

Though this is still broken, this is the until-now normal behavior for
RPC-over-RDMA, up until the "remove duplicate conversations from
packet-infiniband.c" patch. In a capture of NFS on IPoIB or NFS on TCP, you
will see the proper expected way NFS Replies are supposed to appear.

After I applied the packet-infiniband.c hunk of 19107, nothing changed.

Thus my humble conclusion is that the packet-rpcrdma.c hunk of 19107 is the
part that fixes the regression introduced by "remove duplication conversations"
. The packet-infiniband.c hunk does not appear to change the behavior of either
the RPC or RPC-over-RDMA dissector.


> > I've filed bug 13213 to separately document the RPC reply dissection 
> > failure.

I'll attach my fix to 13213, and we can compare and discuss both approaches. I
see why fixing packet-infiniband.c might affect more ULP dissectors, and thus
it might be a more broad fix. Getting PT_IBQP and PT_TCP conversations to
behave more alike is probably a desirable long-term goal. But 19107 is either
not quite right, or somehow it is not enough for RPC. (Probably the latter).

It may be that the packet-infiniband.c hunk of 19107 is still appropriate to
apply. I just wanted to note, however, that change by itself does not appear to
address either 13202 or 13213 (unless I've done something wrong).

-- 
You are receiving this mail because:
You are watching all bug changes.
___
Sent via:Wireshark-bugs mailing list 
Archives:https://www.wireshark.org/lists/wireshark-bugs
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-bugs
 mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe

[Wireshark-bugs] [Bug 12904] File | File Set | List Files dialog is blank

[bugzilla-daemon]

https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=12904

Pascal Quantin  changed:

   What|Removed |Added

 CC||jyo...@gsu.edu

--- Comment #6 from Pascal Quantin  ---
*** Bug 12451 has been marked as a duplicate of this bug. ***

-- 
You are receiving this mail because:
You are watching all bug changes.
___
Sent via:Wireshark-bugs mailing list 
Archives:https://www.wireshark.org/lists/wireshark-bugs
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-bugs
 mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe

[Wireshark-bugs] [Bug 12451] Qt: "Files in Set" dialog erroneously reports "No files in set" and "No capture loaded"

[bugzilla-daemon]

https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=12451

Pascal Quantin  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||pascal.quan...@gmail.com
 Resolution|--- |DUPLICATE

--- Comment #4 from Pascal Quantin  ---


*** This bug has been marked as a duplicate of bug 12904 ***

-- 
You are receiving this mail because:
You are watching all bug changes.
___
Sent via:Wireshark-bugs mailing list 
Archives:https://www.wireshark.org/lists/wireshark-bugs
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-bugs
 mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe

[Wireshark-bugs] [Bug 12451] Qt: "Files in Set" dialog erroneously reports "No files in set" and "No capture loaded"

[bugzilla-daemon]

https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=12451

im7of7+wsbugtr...@gmail.com changed:

   What|Removed |Added

 CC||im7of7+wsbugtr...@gmail.com

--- Comment #3 from im7of7+wsbugtr...@gmail.com ---
I've seen this same behavior on Windows. 

Wireshark 2.2.0 (v2.2.0-0-g5368c50 from master-2.2)

Copyright 1998-2016 Gerald Combs  and contributors.
License GPLv2+: GNU GPL version 2 or later

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 Qt 5.3.2, with WinPcap (4_1_3), with GLib 2.42.0, with
zlib 1.2.8, with SMI 0.4.8, with c-ares 1.11.0, with Lua 5.2.4, with GnuTLS
3.2.15, with Gcrypt 1.6.2, with MIT Kerberos, with GeoIP, with QtMultimedia,
with AirPcap.

Running on 64-bit Windows 7 Service Pack 1, build 7601, with locale
English_United States.1252, with WinPcap version 4.1.3 (packet.dll version
4.1.0.2980), based on libpcap version 1.0 branch 1_0_rel0b (20091008), with
GnuTLS 3.2.15, with Gcrypt 1.6.2, without AirPcap.
Intel(R) Core(TM) i5-6300U CPU @ 2.40GHz (with SSE4.2), with 16260MB of
physical

memory.


Built using Microsoft Visual C++ 12.0 build 40629

-- 
You are receiving this mail because:
You are watching all bug changes.
___
Sent via:Wireshark-bugs mailing list 
Archives:https://www.wireshark.org/lists/wireshark-bugs
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-bugs
 mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe

[Wireshark-bugs] [Bug 13212] Wireshark shows "MS Video Source Request" in a RTCP packet as "Malformed"

[bugzilla-daemon]

https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=13212

Michael Mann  changed:

   What|Removed |Added

 CC||mman...@netscape.net

--- Comment #7 from Michael Mann  ---
(In reply to Vitaly from comment #6)
> Great.
> 
> A little question:
> 
> What about "length" reducing in the MS-DSH processing loop? It seams that
> the length should be reduced by 4 (the length of msi) on each step of the
> loop. It is reduced by 2 in the current code ( "length--" in the loop
> expression and "length--" in the loop statement).
>  
> Something like this ( starting epan/dissectors/packet-rtcp.c:1055):
>  
> while ( length >= 4 ... )
> {
> ...
> length -=4;
> }


I didn't realize how many bugs were being reported at the same time.  I didn't
see any malformed packets after the first patch, so I thought I got everything.
 Does the currently provided capture show this issue as well?

-- 
You are receiving this mail because:
You are watching all bug changes.
___
Sent via:Wireshark-bugs mailing list 
Archives:https://www.wireshark.org/lists/wireshark-bugs
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-bugs
 mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe

[Wireshark-bugs] [Bug 13202] RPC-over-RDMA dissector no longer identifies any valid rpc/rdma frames

[bugzilla-daemon]

https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=13202

--- Comment #11 from Parav Pandit  ---
(In reply to Chuck Lever from comment #8)
> Just as a data point, I applied the packet-infiniband.c diff from change
> 19107 on top of my tree with conversation logic removed from
> packet-rpcrdma.c. It does not change the behavior of the RPC dissector.
> 
Sorry, I didn't follow. Do you see them as Infiniband frames or as
RPC/PortMap/NFS frames after applying my patch?

With the pcap trace of bug 13213, with my change 19107 I am able to see them as
NFS/RPC frames.

> I've filed bug 13213 to separately document the RPC reply dissection failure.

-- 
You are receiving this mail because:
You are watching all bug changes.
___
Sent via:Wireshark-bugs mailing list 
Archives:https://www.wireshark.org/lists/wireshark-bugs
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-bugs
 mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe

[Wireshark-bugs] [Bug 13212] Wireshark shows "MS Video Source Request" in a RTCP packet as "Malformed"

[bugzilla-daemon]

https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=13212

--- Comment #6 from Vitaly  ---
Great.

A little question:

What about "length" reducing in the MS-DSH processing loop? It seams that the
length should be reduced by 4 (the length of msi) on each step of the loop. It
is reduced by 2 in the current code ( "length--" in the loop expression and
"length--" in the loop statement).

Something like this ( starting epan/dissectors/packet-rtcp.c:1055):

while ( length >= 4 ... )
{
...
length -=4;
}

-- 
You are receiving this mail because:
You are watching all bug changes.
___
Sent via:Wireshark-bugs mailing list 
Archives:https://www.wireshark.org/lists/wireshark-bugs
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-bugs
 mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe

[Wireshark-bugs] [Bug 13202] RPC-over-RDMA dissector no longer identifies any valid rpc/rdma frames

[bugzilla-daemon]

https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=13202

--- Comment #10 from Parav Pandit  ---
(In reply to Chuck Lever from comment #7)
> Parav:
> 
> I drew similar conclusions while trying to address a problem where the RPC
> dissector could not match Replies to Calls on RPC-over-RDMA. I had proposed
> change 19033 to the RPC dissector to ignore the source port when building
> conversations, but Michael suggested I abandon it in favor of your work. I
> will investigate change 19107 to see if that addresses this issue.
> 
> However, for other reasons, I want to remove the existing conversation
> infrastructure from packet-rpcrdma.c. See change 19032.
> 
> At some later point, some kind of conversation flow tracking will be needed
> in order to match RDMA Read/Write requests to RPC-over-RDMA transport
> headers. Perhaps you and I can work out a scheme to do this.

Yes. Its already in todo list once some of this basic things sorted out. So
current design is to to pass read/write context from infiniband.c to ulp
dissectors on read/write requests and responses. ULP will have ULP level IO
context in which they can match up the RDMA keys. RDMA key level context come
from infiniband.c so that any transport level errors that occurs transport can
flag.

-- 
You are receiving this mail because:
You are watching all bug changes.
___
Sent via:Wireshark-bugs mailing list 
Archives:https://www.wireshark.org/lists/wireshark-bugs
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-bugs
 mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe

[Wireshark-bugs] [Bug 13213] RPC dissector doesn't match Replies to Calls with RPC-over-RDMA transports

[bugzilla-daemon]

https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=13213

Parav Pandit  changed:

   What|Removed |Added

 CC||paravpan...@yahoo.com

--- Comment #3 from Parav Pandit  ---
Wouldn't this work once you create rpc level conversation based on pinfo
(saddr, daddr, sport, dport)?

Because my change 19107 does have all 4 of them in pinfo.

-- 
You are receiving this mail because:
You are watching all bug changes.
___
Sent via:Wireshark-bugs mailing list 
Archives:https://www.wireshark.org/lists/wireshark-bugs
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-bugs
 mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe

[Wireshark-bugs] [Bug 13216] New: Buildbot crash output: fuzz-2016-12-07-23859.pcap

[bugzilla-daemon]

https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=13216

Bug ID: 13216
   Summary: Buildbot crash output: fuzz-2016-12-07-23859.pcap
   Product: Wireshark
   Version: unspecified
  Hardware: x86-64
   URL: https://www.wireshark.org/download/automated/captures/
fuzz-2016-12-07-23859.pcap
OS: Ubuntu
Status: CONFIRMED
  Severity: Major
  Priority: High
 Component: Dissection engine (libwireshark)
  Assignee: bugzilla-ad...@wireshark.org
  Reporter: buildbot-do-not-re...@wireshark.org

Problems have been found with the following capture file:

https://www.wireshark.org/download/automated/captures/fuzz-2016-12-07-23859.pcap

stderr:
Input file: /home/wireshark/menagerie/menagerie/12802-iser_login.pcap

Build host information:
Linux wsbb04 4.4.0-47-generic #68-Ubuntu SMP Wed Oct 26 19:39:52 UTC 2016
x86_64 x86_64 x86_64 GNU/Linux
Distributor ID:Ubuntu
Description:Ubuntu 16.04.1 LTS
Release:16.04
Codename:xenial

Buildbot information:
BUILDBOT_REPOSITORY=ssh://wireshark-build...@code.wireshark.org:29418/wireshark
BUILDBOT_WORKERNAME=clang-code-analysis
BUILDBOT_BUILDNUMBER=3809
BUILDBOT_URL=http://buildbot.wireshark.org/wireshark-master/
BUILDBOT_BUILDERNAME=Clang Code Analysis
BUILDBOT_GOT_REVISION=29768d91ec60023cc68cb38edc492a6d2221f662

Return value:  0

Dissector bug:  0

Valgrind error count:  1



Git commit
commit 29768d91ec60023cc68cb38edc492a6d2221f662
Author: Michael Mann 
Date:   Tue Dec 6 21:19:01 2016 -0500

RTCP: Bugfix MS Video Source Request dissection

Bug: 13212
Change-Id: I249d38e843f737bbd0773828f24980d148fbaa00
Reviewed-on: https://code.wireshark.org/review/19126
Reviewed-by: Michael Mann 
Petri-Dish: Michael Mann 
Tested-by: Petri Dish Buildbot 
Reviewed-by: Anders Broman 


==23711== Memcheck, a memory error detector
==23711== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
==23711== Using Valgrind-3.11.0 and LibVEX; rerun with -h for copyright info
==23711== Command:
/home/wireshark/builders/wireshark-master-fuzz/clangcodeanalysis/install.plain/bin/tshark
-nr /fuzz/buildbot/clangcodeanalysis/valgrind-fuzz/fuzz-2016-12-07-23859.pcap
==23711== 
==23711== Invalid read of size 2
==23711==at 0x69977C1: ib_addr_to_str (address_types.c:451)
==23711==by 0x699FF8C: col_set_addr (column-utils.c:1913)
==23711==by 0x699FE77: col_fill_in (column-utils.c:2180)
==23711==by 0x416797: print_packet (tshark.c:3852)
==23711==by 0x416389: process_packet (tshark.c:3492)
==23711==by 0x4140D1: load_cap_file (tshark.c:3234)
==23711==by 0x4140D1: main (tshark.c:1934)
==23711==  Address 0xffefff5f0 is on thread 1's stack
==23711==  2336 bytes below stack pointer
==23711== 
==23711== 
==23711== HEAP SUMMARY:
==23711== in use at exit: 6,083,167 bytes in 9,742 blocks
==23711==   total heap usage: 293,400 allocs, 283,658 frees, 38,057,158 bytes
allocated
==23711== 
==23711== LEAK SUMMARY:
==23711==definitely lost: 360 bytes in 87 blocks
==23711==indirectly lost: 0 bytes in 0 blocks
==23711==  possibly lost: 0 bytes in 0 blocks
==23711==still reachable: 6,082,807 bytes in 9,655 blocks
==23711== suppressed: 0 bytes in 0 blocks
==23711== Rerun with --leak-check=full to see details of leaked memory
==23711== 
==23711== For counts of detected and suppressed errors, rerun with: -v
==23711== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)

[ no debug trace ]

-- 
You are receiving this mail because:
You are watching all bug changes.
___
Sent via:Wireshark-bugs mailing list 
Archives:https://www.wireshark.org/lists/wireshark-bugs
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-bugs
 mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe

[Wireshark-bugs] [Bug 12882] TCP packets sometimes are incorrectly parsed as TDS (or other corruptions)

[bugzilla-daemon]

https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=12882

--- Comment #12 from Michael Mann  ---
(In reply to Guy Harris from comment #11)
> (If you mean "how often does an arbitrary packet in a TCP connection contain
> the end of a multi-segment PDU and the beginning of the next PDU", the
> answer is "often enough that it's a good thing that, given the general way
> tcp_dissect_pdus() works, we happen to handle that case as long as
> reassembly is being done and we managed to dissect the beginning of the
> first of those PDUs".)

I would agree with this, which is why I thought converting the dissector to use
tcp_dissect_pdus negated most of the usefulness of conversation_set_dissector
and why I thought it could be removed as a tradeoff.

> I'd say that any protocol that 1) is a popular protocol and 2) doesn't have
> a fixed port assigned to it should have a heuristic dissector if possible;
> if the heuristic is really weak (such as the RTP heuristic), it should
> probably not be enabled *by default*, but we shouldn't require the user to
> use "Decode As..." for protocols such as ONC RPC-based protocols (to give an
> example of a heuristic that works pretty well and that is pretty useful).

This is where the definition of "heuristic" gets blurred to me.  Many protocols
don't have a strong heuristic, so they're stuck with registering on a port and
using that as the main heuristic.  And for ones that don't have an IANA port,
I'm okay with a dissector "claiming" that port and just resolving the rare case
when then overlap just so all users using/expecting that protocol don't need
the extra step of Decode As.  I think executing that heuristic is much faster
than creating a heuristic function handler that checks for that same port. 
It's also easier to override with Decode As.

> 
> What might be useful here would be
> 
>   1) a way of saying "frames XXX through YYY of this conversation should be
> decode as protocol PPP" (which might also be useful for protocols that can
> switch to TLS in the middle of a session, for example)

This seems like a lot of work.  Yes, I think I'll take shopping instead.

> 
> and
> 
>   2) having tcp_dissect_pdus() (and other wrappers that handle reassembly
> over byte-stream protocols, such as the text-based request-response protocol
> code) on the first pass *automatically* mark the conversation as "all frames
> from the current frame through the end of the capture should be decoded as
> protocol PPP" if it decides that more data needs to be added as part of
> reassembly, so that, at minimum, the next segment in that flow gets handed
> to the dissector so that the reassembly can be one, and have it only close
> out that mark when it finds a PDU that ends at the end of the segment.

I've wondered for a long while why this wasn't implemented (because it seems
like a simple one line change).   I just figured there were people smarter than
me that knew the reason and typically "negatives" aren't documented (like
"here's why we don't call set_conversation_dissector here in the TCP
dissector")

> 
> At least that way, we wouldn't be marking the *entire* conversation as TDS
> in this capture.  If we don't want *any* conversations dissected as TDS,
> either we need to strengthen the heuristic in the TDS dissector, or the user
> has to disable the TDS heuristic.  Users doing a significant amount of MSSQL
> dissection would presumably want to leave that heuristic enabled, as it
> would probably get the right answer more often than it gets the wrong
> answer.)

Regarding "bug maintenance", should this bug be left open until such time as
the heuristic can be strengthened (seems unlikely given what fields are
available)?  Or should it just be marked as "WONTFIX" because users that run
into this should just disable TDS heuristic because they probably don't need
it.

-- 
You are receiving this mail because:
You are watching all bug changes.
___
Sent via:Wireshark-bugs mailing list 
Archives:https://www.wireshark.org/lists/wireshark-bugs
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-bugs
 mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe

[Wireshark-bugs] [Bug 13044] Buildbot crash output: fuzz-2016-10-25-19751.pcap

[bugzilla-daemon]

https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=13044

--- Comment #22 from Michael Mann  ---
*** Bug 13215 has been marked as a duplicate of this bug. ***

-- 
You are receiving this mail because:
You are watching all bug changes.
___
Sent via:Wireshark-bugs mailing list 
Archives:https://www.wireshark.org/lists/wireshark-bugs
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-bugs
 mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe

[Wireshark-bugs] [Bug 13215] Buildbot crash output: fuzz-2016-12-07-6687.pcap

[bugzilla-daemon]

https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=13215

Michael Mann  changed:

   What|Removed |Added

 Status|CONFIRMED   |RESOLVED
 CC||mman...@netscape.net
 Resolution|--- |DUPLICATE

--- Comment #1 from Michael Mann  ---
Some of the information here has to be wrong, and I'm not sure which it is.

The line referenced in packet-cops.c (1103) is #if 0ed out when the git commit
listed occurred (i.e. after Guy's changes to break big if statement up) on the
master branch.

However, the Change-Id listed for the commit is for the cherry-pick done to the
master-2.2 and master-2.0 branches, but buildbot URLS, etc. claim this is from
master branch.  Did something break and we don't distinguish master from 2.2
and 2.0 properly on the buildbot?

*** This bug has been marked as a duplicate of bug 13044 ***

-- 
You are receiving this mail because:
You are watching all bug changes.
___
Sent via:Wireshark-bugs mailing list 
Archives:https://www.wireshark.org/lists/wireshark-bugs
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-bugs
 mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe

[Wireshark-bugs] [Bug 12882] TCP packets sometimes are incorrectly parsed as TDS (or other corruptions)

[bugzilla-daemon]

https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=12882

--- Comment #11 from Guy Harris  ---
(In reply to Michael Mann from comment #10)
> (In reply to Guy Harris from comment #9)
> > If there are TCP dissectors that do reassembly, use a heuristic, and don't
> > use conversation_set_dissector(), there can be cases where the reassembly
> > will fail, so those dissectors are buggy.
> 
> Are you talking TCP reassembly or reassembly of layer above the protocol
> running over TCP? (TDS certainly qualifies trying to reassemble NETLIB)

TCP reassembly.

> I think I've been lulled into believing that heuristics are used for the
> start of a packet and most TCP dissectors use them just because they don't
> have the "determinism" of a reserved IANA port.  How often are you really
> presented with the start of a TCP PDU in the middle of a TCP packet?

If you mean "how often does *the first captured packet of a TCP connection*
contain the end of a multi-segment PDU and the beginning of the next PDU", the
answer is "probably not too often", but which dissectors handle that cases?

(If you mean "how often does an arbitrary packet in a TCP connection contain
the end of a multi-segment PDU and the beginning of the next PDU", the answer
is "often enough that it's a good thing that, given the general way
tcp_dissect_pdus() works, we happen to handle that case as long as reassembly
is being done and we managed to dissect the beginning of the first of those
PDUs".)

> Maybe
> the first PDU at the start of a capture, and I guess I can usually live with
> that (not being dissected), because it would end up being way too expensive
> (performance) to ensure Wireshark "guessed right".  I also sometimes have a
> hard time distinguishing "need" (for heuristics) from overzealous developer
> trying to put as many entrances to his protocol as possible (especially with
> older dissectors).

I'd say that any protocol that 1) is a popular protocol and 2) doesn't have a
fixed port assigned to it should have a heuristic dissector if possible; if the
heuristic is really weak (such as the RTP heuristic), it should probably not be
enabled *by default*, but we shouldn't require the user to use "Decode As..."
for protocols such as ONC RPC-based protocols (to give an example of a
heuristic that works pretty well and that is pretty useful).

> I still think switching to TDS to use tcp_dissect_pdus is worthwhile, but
> without removing conversation_set_dissector(), this capture is still stuck
> thinking it's TDS.  I can see the merits of keeping the
> conversation_set_dissector, I'm just not sure how practical it is and I
> would be okay removing the heuristic dissector altogether (in favor of using
> preferences/Decode As) rather than disabling the heuristic for being too
> weak.

I wouldn't be okay with it, given that SQL Server is, as far as I know, a
fairly popular database server, so there's probably a significant amount of TDS
traffic out there.  If you have the heuristic, you can disable it; if you
*don't* have the heuristic, you can't enable it

What might be useful here would be

  1) a way of saying "frames XXX through YYY of this conversation should be
decode as protocol PPP" (which might also be useful for protocols that can
switch to TLS in the middle of a session, for example)

and

  2) having tcp_dissect_pdus() (and other wrappers that handle reassembly over
byte-stream protocols, such as the text-based request-response protocol code)
on the first pass *automatically* mark the conversation as "all frames from the
current frame through the end of the capture should be decoded as protocol PPP"
if it decides that more data needs to be added as part of reassembly, so that,
at minimum, the next segment in that flow gets handed to the dissector so that
the reassembly can be one, and have it only close out that mark when it finds a
PDU that ends at the end of the segment.

At least that way, we wouldn't be marking the *entire* conversation as TDS in
this capture.  If we don't want *any* conversations dissected as TDS, either we
need to strengthen the heuristic in the TDS dissector, or the user has to
disable the TDS heuristic.  Users doing a significant amount of MSSQL
dissection would presumably want to leave that heuristic enabled, as it would
probably get the right answer more often than it gets the wrong answer.)

(Actually, that needs to use both frame numbers *and* offsets within the
segment, in case the protocol changes in the middle of the segment.  Dissecting
protocols running over protocols offering a byte-stream service is hard, let's
go shopping!)

-- 
You are receiving this mail because:
You are watching all bug changes.
___
Sent via:Wireshark-bugs mailing list 
Archives:https://www.wireshark.org/lists/wireshark-bugs
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-bugs
   

[Wireshark-bugs] [Bug 13215] New: Buildbot crash output: fuzz-2016-12-07-6687.pcap

[bugzilla-daemon]

https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=13215

Bug ID: 13215
   Summary: Buildbot crash output: fuzz-2016-12-07-6687.pcap
   Product: Wireshark
   Version: unspecified
  Hardware: x86-64
   URL: https://www.wireshark.org/download/automated/captures/
fuzz-2016-12-07-6687.pcap
OS: Ubuntu
Status: CONFIRMED
  Severity: Major
  Priority: High
 Component: Dissection engine (libwireshark)
  Assignee: bugzilla-ad...@wireshark.org
  Reporter: buildbot-do-not-re...@wireshark.org

Problems have been found with the following capture file:

https://www.wireshark.org/download/automated/captures/fuzz-2016-12-07-6687.pcap

stderr:
Input file: /home/wireshark/menagerie/menagerie/11275-cops-fuzz-test.pcap

Build host information:
Linux wsbb04 4.4.0-47-generic #68-Ubuntu SMP Wed Oct 26 19:39:52 UTC 2016
x86_64 x86_64 x86_64 GNU/Linux
Distributor ID:Ubuntu
Description:Ubuntu 16.04.1 LTS
Release:16.04
Codename:xenial

Buildbot information:
BUILDBOT_REPOSITORY=ssh://wireshark-build...@code.wireshark.org:29418/wireshark
BUILDBOT_WORKERNAME=clang-code-analysis
BUILDBOT_BUILDNUMBER=3808
BUILDBOT_URL=http://buildbot.wireshark.org/wireshark-master/
BUILDBOT_BUILDERNAME=Clang Code Analysis
BUILDBOT_GOT_REVISION=199756b43db99217f37629611a511ec48caf49a3

Return value:  0

Dissector bug:  0

Valgrind error count:  1



Git commit
commit 199756b43db99217f37629611a511ec48caf49a3
Author: Michael Mann 
Date:   Mon Dec 5 07:39:06 2016 -0500

SMB: Limit Export object files to 32 bits.

Most of the file offset fields are 32-bit, but the algorithms use gsize
variables, which can vary between 32 and 64 bit builds.  The 64-bit
builds are the ones with the problem with "garbage" data comes from
(effectively) invalid 32-bit offsets.

Bug: 11133
Change-Id: Icb5d31ae732f9177f3a117dfae39bf1cc983d603
Reviewed-on: https://code.wireshark.org/review/19091
Petri-Dish: Michael Mann 
Reviewed-by: Michael Mann 


Command and args: ./tools/valgrind-wireshark.sh 

==25217== Memcheck, a memory error detector
==25217== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
==25217== Using Valgrind-3.11.0 and LibVEX; rerun with -h for copyright info
==25217== Command:
/home/wireshark/builders/wireshark-master-fuzz/clangcodeanalysis/install.plain/bin/tshark
-nr /fuzz/buildbot/clangcodeanalysis/valgrind-fuzz/fuzz-2016-12-07-6687.pcap
==25217== 
==25217== Conditional jump or move depends on uninitialised value(s)
==25217==at 0x69FC604: dissect_cops_pdu (packet-cops.c:1103)
==25217==by 0x6F7AA5D: tcp_dissect_pdus (packet-tcp.c:2750)
==25217==by 0x69FAFB1: dissect_cops (packet-cops.c:1135)
==25217==by 0x682BF38: call_dissector_through_handle (packet.c:618)
==25217==by 0x682BF38: call_dissector_work (packet.c:706)
==25217==by 0x682BDFE: dissector_try_uint_new (packet.c:1163)
==25217==by 0x6F7AD55: decode_tcp_ports (packet-tcp.c:4629)
==25217==by 0x6F7BE60: process_tcp_payload (packet-tcp.c:4682)
==25217==by 0x6F7B32A: desegment_tcp (packet-tcp.c:2270)
==25217==by 0x6F7B32A: dissect_tcp_payload (packet-tcp.c:4749)
==25217==by 0x6F7FBA6: dissect_tcp (packet-tcp.c:5656)
==25217==by 0x682BF69: call_dissector_through_handle (packet.c:620)
==25217==by 0x682BF69: call_dissector_work (packet.c:706)
==25217==by 0x682BDFE: dissector_try_uint_new (packet.c:1163)
==25217==by 0x6C1397F: ip_try_dissect (packet-ip.c:2000)
==25217== 
==25217== 
==25217== HEAP SUMMARY:
==25217== in use at exit: 1,034,856 bytes in 28,346 blocks
==25217==   total heap usage: 243,815 allocs, 215,469 frees, 31,539,004 bytes
allocated
==25217== 
==25217== LEAK SUMMARY:
==25217==definitely lost: 2,972 bytes in 127 blocks
==25217==indirectly lost: 36,704 bytes in 50 blocks
==25217==  possibly lost: 0 bytes in 0 blocks
==25217==still reachable: 995,180 bytes in 28,169 blocks
==25217== suppressed: 0 bytes in 0 blocks
==25217== Rerun with --leak-check=full to see details of leaked memory
==25217== 
==25217== For counts of detected and suppressed errors, rerun with: -v
==25217== Use --track-origins=yes to see where uninitialised values come from
==25217== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)

[ no debug trace ]

-- 
You are receiving this mail because:
You are watching all bug changes.
___
Sent via:Wireshark-bugs mailing list 
Archives:https://www.wireshark.org/lists/wireshark-bugs
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-bugs
 mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe