[Wireshark-bugs] [Bug 14574] DNS Response to NS query shows as malformed packet

[bugzilla-daemon]

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

--- Comment #5 from Gerrit Code Review  ---
Change 26695 merged by Anders Broman:
dns: check if name is root before any other check.

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

-- 
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 14573] error received from dissect_wccp2_hash_assignment_info()

[bugzilla-daemon]

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

--- Comment #6 from Gerrit Code Review  ---
Change 26661 merged by Anders Broman:
WCCP: use proto_tree_add_ipv4_format() if ipv4 used

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

-- 
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 13932] HTTP2/GRPC/ProtoBuf: Add new GRPC and ProtoBuf dissectors, and make little change on http2 dissector for providing some information to grpc dissection.

[bugzilla-daemon]

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

Alexander Petrossian (PAF)  changed:

   What|Removed |Added

 CC||p...@yandex.ru

--- Comment #19 from Alexander Petrossian (PAF)  ---
Michael, friends.
Is this anywhere near releasing?

Judging from comments most (all?) work is already done.

-- 
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 14587] New: Incorrect parsing of USB CDC packets.

[bugzilla-daemon]

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

Bug ID: 14587
   Summary: Incorrect parsing of USB CDC packets.
   Product: Wireshark
   Version: 2.4.4
  Hardware: x86
OS: Linux
Status: UNCONFIRMED
  Severity: Normal
  Priority: Low
 Component: Dissection engine (libwireshark)
  Assignee: bugzilla-ad...@wireshark.org
  Reporter: 3ld3rm4l4...@gmail.com
  Target Milestone: ---

Created attachment 16249
  --> https://bugs.wireshark.org/bugzilla/attachment.cgi?id=16249=edit
Capture with malformed and correct packets

Build Information:
Wireshark 2.4.4 (Git v2.4.4 packaged as 2.4.4-1~16.04.0)

Copyright 1998-2018 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.5.1, with libpcap, with POSIX capabilities (Linux),
with libnl 3, with GLib 2.48.2, with zlib 1.2.8, with SMI 0.4.8, with c-ares
1.10.0, with Lua 5.2.4, with GnuTLS 3.4.10, with Gcrypt 1.6.5, with MIT
Kerberos, with GeoIP, with nghttp2 1.7.1, with LZ4, with Snappy, with libxml2
2.9.3, with QtMultimedia, without AirPcap, with SBC, with SpanDSP.

Running on Linux 4.4.0-116-generic, with Intel(R) Core(TM) i7-6820HQ CPU @
2.70GHz (with SSE4.2), with 31853 MB of physical memory, with locale
en_US.UTF-8, with libpcap version 1.7.4, with GnuTLS 3.4.10, with Gcrypt 1.6.5,
with zlib 1.2.8.

Built using gcc 5.4.0 20160609.

--
I'm experiencing something confusing. I'm getting Malformed Packets on the log
window but they are perfectly fine. These supposedly malformed packets reach
the device just fine and the device responds fine as well, so there is nothing
wrong with the packets. I'm sniffing a very simple CDC device and I'm sending a
0x32, 0x31, 0x0a from the host terminal.

For these tests, you need to filter as "usb.device_address == 112"

I'm getting the malformed packets if I start a session and the plug my device.
But if the device is already plugged in and I restart the session I no longer
get the malformed packets. Everything seems to work just fine.

The file "malformedPackets112.pcapng" contains the malformed captures and the
file "normalPackets112.pcapng" contains the correct packet parsing.

I noticed some discrepancies on how Wireshark report the packets on both
scenarios. When the packet is reported as malformed, I noticed that the
Protocols in frame field contains:

[Protocols in frame: usb:usb:com:eth]


But when it works fine then this same field contains:

[Protocols in frame: usb]


Additionally, I noticed that further down the field bInterfaceClass field
contain the following when the packet is supposedly malformed:

[bInterfaceClass: CDC-Data (0x0a)]


And contains the following when the packets are reported fine:

[bInterfaceClass: Unknown (0x)]


Here is strange because it seems that the correct contents of this field, when
the packet is not reported as malformed, should be CDC-Data, but I guess that
is part of the problem.

If I compare the bytes in the packet window I can see that everything matches
perfectly, (with exception of URB id, URB sec, and URB usec obviously) and even
the 0x32, 0x31, 0x0a sent from the host are there in both cases.

Finally, the response from my device is correct but wireshark parse it wrong.
The response from the device is: 0x0a, 0x3a, 0x56, 0x32, 0x2e, 0x34, 0x2e,
0x31, 0x30, 0x35, 0x0a (ASCII <0x06>:V2.1.4.105<0x06>) and I can see those
bytes in the packet but the wireshark capture window shows that the source is
2e:34:2e:31:30:35 wich coincides with the last part of the correct payload but
it is not the source address.

On the correct capture file you can see that it contains "Leftover Capture
Data: 063a56322e312e342e3130350a" which is correct.

-- 
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 14587] Incorrect parsing of USB CDC packets.

[bugzilla-daemon]

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

Manuel Malagon <3ld3rm4l4...@gmail.com> changed:

   What|Removed |Added

  Attachment #16249|Capture with malformed and  |Captures with malformed and
description|correct packets |correct packets

-- 
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 14532] extcap: InterfaceToolbar control pipe broken

[bugzilla-daemon]

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

--- Comment #2 from Gerald Combs  ---
(In reply to Stig Bjørlykke from comment #0)
> 
> Turning on and off the "Verify" checkbox shall give a statusbar message,
> pressing the "Turn on"/"Turn off" button shall give a warning popup on next
> received packet, and the  Log shall be populated during capture.

This works for me here in the current master (5a9d0caa11) on macOS. I did the
following:

Copied doc/extcap_example.py to /run/Wireshark.app/Contents/MacOS/extcap/

Chmodded 755 /run/Wireshark.app/Contents/MacOS/extcap/extcap_example.py

Started Wireshark

Enabled "View -> Interface Toolbars -> Example extcap interface"

Double-clicked on the "Example interface 1 for extcap: example1" interface. A
dialog popped up with a red "Message" field. 

Entered "A message" in the "Message" field.

Pressed "Start". Packets started showing up with "if1|0009A message|True" in
the payload.

Changed the "Message" field to "A message test" and applied. Packets started
showing up with "if1|000EA message test|True" in the payload.

Unchecked and checked "Verify". "Verify changed" showed up each time in the
status bar.

Clicked "Turn on". A dialog popped up with the message "Turn action finished."

-- 
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 14587] Incorrect parsing of USB CDC packets.

[bugzilla-daemon]

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

Manuel Malagon <3ld3rm4l4...@gmail.com> changed:

   What|Removed |Added

 CC||3ld3rm4l4...@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 14532] extcap: InterfaceToolbar control pipe broken

[bugzilla-daemon]

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

--- Comment #3 from Stig Bjørlykke  ---
(In reply to Gerald Combs from comment #2)
> This works for me here in the current master (5a9d0caa11) on macOS.

Yes it works on both macOS and Linux, this bug report is for Windows.

-- 
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 14551] SIP Response-time not being well calculated

[bugzilla-daemon]

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

Uli Heilmeier  changed:

   What|Removed |Added

 CC||u...@heilmeier.eu
 OS|Windows 10  |All
 Status|UNCONFIRMED |IN_PROGRESS
 Ever confirmed|0   |1
   Hardware|x86 |All

--- Comment #1 from Uli Heilmeier  ---
Issue with the sample capture is that we don't set request_time for frame 10 as
command sequence (cseq) is 1 and hasn't increased. This results to
request_time.secs = 0 for frame 10 and therefore the high response time in
frame 11.

Not sure if this is a bug: According to my understanding of RFC 3261 [1] cseq
should be incremented for each new request. In the sample capture this is not
the case.

However for sip.response-request we don't use cseq.

[1]: https://tools.ietf.org/html/rfc3261#section-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 14574] DNS Response to NS query shows as malformed packet

[bugzilla-daemon]

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

--- Comment #6 from Jaap Keuter  ---
Does this still work with the capture of bug 13289 ??

-- 
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 14539] OID name resolution, various problems

[bugzilla-daemon]

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

--- Comment #7 from Jaap Keuter  ---
(In reply to Guy Harris from comment #1)

> Now, if I run a recent Wireshark build from the master branch, pop up the
> About dialog, and select Folders, I see the folders in question.  If I then
> close the dialog and enable OID name resolution, I get an *immediate* crash
> with:
> [STACK TRACE]

Is this problem averted now?

-- 
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 14587] Incorrect parsing of USB CDC packets.

[bugzilla-daemon]

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

Pascal Quantin  changed:

   What|Removed |Added

 CC||pascal.quan...@gmail.com
 Ever confirmed|0   |1
 Status|UNCONFIRMED |CONFIRMED

--- Comment #1 from Pascal Quantin  ---
USB COM dissector defaults the payload dissection to CDC ECM if the Data
Interface Class Protocol is not 1 or 2. Obviously this is a wrong choice here.
THe problem is that both ECM and ACM seems to use CDC-Data with Data Interface
Class Protocol set to 0, so I do not know how to differentiate them.

-- 
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 14574] DNS Response to NS query shows as malformed packet

[bugzilla-daemon]

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

--- Comment #7 from Dario Lombardo  ---
(In reply to Jaap Keuter from comment #6)
> Does this still work with the capture of bug 13289 ??

It should. The new check includes the old. Are you experiencing any issue?

-- 
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 14587] Incorrect parsing of USB CDC packets.

[bugzilla-daemon]

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

--- Comment #2 from Manuel Malagon <3ld3rm4l4...@gmail.com> ---
(In reply to Pascal Quantin from comment #1)
> USB COM dissector defaults the payload dissection to CDC ECM if the Data
> Interface Class Protocol is not 1 or 2. Obviously this is a wrong choice
> here.
> THe problem is that both ECM and ACM seems to use CDC-Data with Data
> Interface Class Protocol set to 0, so I do not know how to differentiate
> them.

Why is the USB COM dissector deciding based on the Interface Class Protocol?
Indeed this parameter can be 0 for both ACM and ECM.

You can use the Communication Class Interface descriptor communications class
subclass (bInterfaceSubClass) to differentiate, don't you?

-- 
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 14587] Incorrect parsing of USB CDC packets.

[bugzilla-daemon]

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

--- Comment #3 from Pascal Quantin  ---
For CDC Data, subclass is set to 0 in both cases (it is set to ACM or ECM in
the Communications and CDC Control class only).

-- 
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 14586] New: Buildbot crash output: fuzz-2018-04-04-16225.pcap

[bugzilla-daemon]

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

Bug ID: 14586
   Summary: Buildbot crash output: fuzz-2018-04-04-16225.pcap
   Product: Wireshark
   Version: unspecified
  Hardware: x86-64
OS: Ubuntu
Status: CONFIRMED
  Severity: Major
  Priority: High
 Component: Dissection engine (libwireshark)
  Assignee: bugzilla-ad...@wireshark.org
  Reporter: buildbot-do-not-re...@wireshark.org
  Target Milestone: ---

Problems have been found with the following capture file:

https://www.wireshark.org/download/automated/captures/fuzz-2018-04-04-16225.pcap

stderr:
Input file: /home/wireshark/menagerie/menagerie/.cap

Build host information:
Linux wsbb04 4.4.0-116-generic #140-Ubuntu SMP Mon Feb 12 21:23:04 UTC 2018
x86_64 x86_64 x86_64 GNU/Linux
Distributor ID: Ubuntu
Description:Ubuntu 16.04.4 LTS
Release:16.04
Codename:   xenial

Buildbot information:
BUILDBOT_REPOSITORY=ssh://wireshark-build...@code.wireshark.org:29418/wireshark
BUILDBOT_WORKERNAME=fuzz-test
BUILDBOT_BUILDNUMBER=2
BUILDBOT_URL=http://buildbot.wireshark.org/wireshark-2.6/
BUILDBOT_BUILDERNAME=Fuzz Test
BUILDBOT_GOT_REVISION=cf4a195ceff36472ab594115e618208185b6227f

Return value:  0

Dissector bug:  0

Valgrind error count:  1



Git commit
commit cf4a195ceff36472ab594115e618208185b6227f
Author: Guy Harris 
Date:   Mon Apr 2 18:03:30 2018 -0700

If we're reading from a string, don't fclose yyin.

yyin is initialized to stdin.  When we're reading from files, we set it
so that it points to the FILE from which we're reading, but when we're
reading from a string, we don't set it, leaving it to point to stdin.

This means that, just as the "read from the input" routine has to be set
differently when reading from a file or a string, the "close the current
input" routine has to be set differently as well.

Bug: 14577
Change-Id: Ie05880775612867e9037ace2de0cd0a0dd2fabb5
Reviewed-on: https://code.wireshark.org/review/26719
Reviewed-by: Guy Harris 
(cherry picked from commit 9d87f607ee2ecefaff71f2ab3f2dc3d2dc185399)
Reviewed-on: https://code.wireshark.org/review/26720


==16404== Memcheck, a memory error detector
==16404== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
==16404== Using Valgrind-3.11.0 and LibVEX; rerun with -h for copyright info
==16404== Command:
/home/wireshark/builders/wireshark-2.6-fuzz/fuzztest/install/bin/tshark -nr
/fuzz/buildbot/fuzztest/valgrind-fuzz-2.6/fuzz-2018-04-04-16225.pcap
==16404== 
tshark: Couldn't load plugin 'l16mono.so':
/home/wireshark/builders/wireshark-2.6-fuzz/fuzztest/install/lib/wireshark/plugins/2.6/wiretap/l16mono.so:
undefined symbol: register_codec
==16404== Thread 2:
==16404== Conditional jump or move depends on uninitialised value(s)
==16404==at 0xA5C7FB6: ws_mempbrk_sse42_compile (ws_mempbrk_sse42.c:58)
==16404==by 0x6AFF1A0: register_all_protocols_worker (register.c:37)
==16404==by 0xAA4DBB4: ??? (in
/lib/x86_64-linux-gnu/libglib-2.0.so.0.4800.2)
==16404==by 0xB45A6B9: start_thread (pthread_create.c:333)
==16404==by 0xB77741C: clone (clone.S:109)
==16404== 
==16404== 
==16404== HEAP SUMMARY:
==16404== in use at exit: 107,627 bytes in 144 blocks
==16404==   total heap usage: 333,960 allocs, 333,816 frees, 38,472,724 bytes
allocated
==16404== 
==16404== LEAK SUMMARY:
==16404==definitely lost: 0 bytes in 0 blocks
==16404==indirectly lost: 0 bytes in 0 blocks
==16404==  possibly lost: 0 bytes in 0 blocks
==16404==still reachable: 13,304 bytes in 115 blocks
==16404== suppressed: 94,323 bytes in 29 blocks
==16404== Rerun with --leak-check=full to see details of leaked memory
==16404== 
==16404== For counts of detected and suppressed errors, rerun with: -v
==16404== Use --track-origins=yes to see where uninitialised values come from
==16404== 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