[Wireshark-bugs] [Bug 12862] New: Buildbot crash output: randpkt-2016-09-10-1188.pcap

[bugzilla-daemon]

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

Bug ID: 12862
   Summary: Buildbot crash output: randpkt-2016-09-10-1188.pcap
   Product: Wireshark
   Version: unspecified
  Hardware: x86-64
   URL: https://www.wireshark.org/download/automated/captures/
randpkt-2016-09-10-1188.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/randpkt-2016-09-10-1188.pcap

stderr:
Input file: 

Build host information:
Linux wsbb04 4.4.0-34-generic #53-Ubuntu SMP Wed Jul 27 16:06:39 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=3672
BUILDBOT_URL=http://buildbot.wireshark.org/wireshark-master/
BUILDBOT_BUILDERNAME=Clang Code Analysis
BUILDBOT_GOT_REVISION=d1cacbb146350381637314310a0824d9f3fe

Return value:  134

Dissector bug:  0

Valgrind error count: 




Command and args: ./tshark -nVxr

==1197==ERROR: AddressSanitizer failed to allocate 0x1000 (268435456) bytes
at address 7fff7000 (errno: 12)
==1197==ReserveShadowMemoryRange failed while trying to map 0x1000 bytes.
Perhaps you're using ulimit -v

[ 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://wireshark.org/mailman/options/wireshark-bugs
 mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe

[Wireshark-bugs] [Bug 12861] New: Buildbot crash output: randpkt-2016-09-10-29402.pcap

[bugzilla-daemon]

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

Bug ID: 12861
   Summary: Buildbot crash output: randpkt-2016-09-10-29402.pcap
   Product: Wireshark
   Version: unspecified
  Hardware: x86-64
   URL: https://www.wireshark.org/download/automated/captures/
randpkt-2016-09-10-29402.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/randpkt-2016-09-10-29402.pcap

stderr:
Input file: 

Build host information:
Linux wsbb04 4.4.0-34-generic #53-Ubuntu SMP Wed Jul 27 16:06:39 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=3671
BUILDBOT_URL=http://buildbot.wireshark.org/wireshark-master/
BUILDBOT_BUILDERNAME=Clang Code Analysis
BUILDBOT_GOT_REVISION=559bb375c1542f6556b4afc260345eb6a988025b

Return value:  134

Dissector bug:  0

Valgrind error count: 




Command and args: ./tshark -nVxr

==29411==ERROR: AddressSanitizer failed to allocate 0x1000 (268435456)
bytes at address 7fff7000 (errno: 12)
==29411==ReserveShadowMemoryRange failed while trying to map 0x1000 bytes.
Perhaps you're using ulimit -v

[ 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://wireshark.org/mailman/options/wireshark-bugs
 mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe

[Wireshark-bugs] [Bug 12752] Stack overflow in Catapult DCT2000 dissector

[bugzilla-daemon]

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

Gerald Combs  changed:

   What|Removed |Added

   See Also||http://cve.mitre.org/cgi-bi
   ||n/cvename.cgi?name=CVE-2016
   ||-7179

-- 
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://wireshark.org/mailman/options/wireshark-bugs
 mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe

[Wireshark-bugs] [Bug 12751] Invalid memory access in UMTS-FP dissector

[bugzilla-daemon]

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

Gerald Combs  changed:

   What|Removed |Added

   See Also||http://cve.mitre.org/cgi-bi
   ||n/cvename.cgi?name=CVE-2016
   ||-7178

-- 
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://wireshark.org/mailman/options/wireshark-bugs
 mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe

[Wireshark-bugs] [Bug 12750] Buffer overflow in Catapult DCT2000 dissector

[bugzilla-daemon]

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

Gerald Combs  changed:

   What|Removed |Added

   See Also||http://cve.mitre.org/cgi-bi
   ||n/cvename.cgi?name=CVE-2016
   ||-7177

-- 
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://wireshark.org/mailman/options/wireshark-bugs
 mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe

[Wireshark-bugs] [Bug 12700] Buildbot crash output: fuzz-2016-08-02-16422.pcap

[bugzilla-daemon]

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

Gerald Combs  changed:

   What|Removed |Added

   See Also||http://cve.mitre.org/cgi-bi
   ||n/cvename.cgi?name=CVE-2016
   ||-7176

-- 
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://wireshark.org/mailman/options/wireshark-bugs
 mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe

[Wireshark-bugs] [Bug 11850] Buildbot crash output: fuzz-2015-12-03-17013.pcap

[bugzilla-daemon]

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

Gerald Combs  changed:

   What|Removed |Added

   See Also||http://cve.mitre.org/cgi-bi
   ||n/cvename.cgi?name=CVE-2016
   ||-7175

-- 
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://wireshark.org/mailman/options/wireshark-bugs
 mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe

[Wireshark-bugs] [Bug 12837] Qt: Gigantic format list when open capture file

[bugzilla-daemon]

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

--- Comment #6 from Guy Harris  ---
The dialog box shown in

   
https://msdn.microsoft.com/en-us/library/windows/desktop/dn742498(v=vs.85).aspx

shows "All Picture Files" without any list of extensions, so it appears that
Microsoft, at least, doesn't insist on showing a list of extensions for that
type of selection.

-- 
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://wireshark.org/mailman/options/wireshark-bugs
 mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe

[Wireshark-bugs] [Bug 12763] tshark print 'TCP flags' with non-ascci chars on some console

[bugzilla-daemon]

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

--- Comment #7 from Gerald Combs  ---
Can you try

tshark ... | iconv -f UTF-8 -t ASCII//TRANSLIT | less

It's a bit clunky but it translates arrows and middle dots to their ASCII
equivalents 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://wireshark.org/mailman/options/wireshark-bugs
 mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe

[Wireshark-bugs] [Bug 12860] New: Buildbot crash output: randpkt-2016-09-09-24105.pcap

[bugzilla-daemon]

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

Bug ID: 12860
   Summary: Buildbot crash output: randpkt-2016-09-09-24105.pcap
   Product: Wireshark
   Version: unspecified
  Hardware: x86-64
   URL: https://www.wireshark.org/download/automated/captures/
randpkt-2016-09-09-24105.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/randpkt-2016-09-09-24105.pcap

stderr:
Input file: 

Build host information:
Linux wsbb04 4.4.0-34-generic #53-Ubuntu SMP Wed Jul 27 16:06:39 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=3670
BUILDBOT_URL=http://buildbot.wireshark.org/wireshark-master/
BUILDBOT_BUILDERNAME=Clang Code Analysis
BUILDBOT_GOT_REVISION=ecd82d08a1479849cb6d4ebb93422b0f96470704

Return value:  134

Dissector bug:  0

Valgrind error count: 




Command and args: ./tshark -nVxr

==24114==ERROR: AddressSanitizer failed to allocate 0x1000 (268435456)
bytes at address 7fff7000 (errno: 12)
==24114==ReserveShadowMemoryRange failed while trying to map 0x1000 bytes.
Perhaps you're using ulimit -v

[ 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://wireshark.org/mailman/options/wireshark-bugs
 mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe

[Wireshark-bugs] [Bug 12826] usage http-tcp dissector from lua dissector lead to Segmentation fault

[bugzilla-daemon]

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

--- Comment #11 from Guy Harris  ---
(In reply to Peter Wu from comment #8)
> Comment 5 uses an approach that seems quite common for Lua dissectors (I
> think it is also documented in an example Lua dissector): obtain old handle,
> override dissectors, call old dissector and act on it.
> 
> I think that https://code.wireshark.org/review/16176 is sufficient for
> correctness (i.e. not crash on missing data), but unfortunately loses the
> possibility to propagate the end-of-stream flag from the TCP layer to HTTP.
> 
> In C dissectors, we rely on code review and conventions to avoid illegal
> "data" parameters (though we do have type confusion problems at times).
> 
> We cannot rely on the Lua dissector not to pass garbage. Currently it always
> passes a NULL data parameter which is handled gracefully by at least:
> modbus (mbtcp), ethertype, wlan (ieee80211). (Searched for
> call_dissector_with_data and looked at a random sample).
> 
> Maybe we should drop this data parameter and use p_add_proto_data:

...which is a mechanism for persistent data attached to packets; I'd prefer not
to use it for data that can be generated by the calling dissector on the fly.

-- 
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://wireshark.org/mailman/options/wireshark-bugs
 mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe

[Wireshark-bugs] [Bug 12826] usage http-tcp dissector from lua dissector lead to Segmentation fault

[bugzilla-daemon]

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

--- Comment #10 from Peter Wu  ---
(In reply to Michael Mann from comment #9)
> (In reply to Peter Wu from comment #8)
> > Maybe we should drop this data parameter and use p_add_proto_data:
> 
> I would rather rewrite the dissector function signature (to have "data
> pointer + type") than use p_add_proto_data.  It makes code flow MUCH harder
> to follow (and easier to create bugs as a result).  It was one of the
> reasons I tried to rid dissectors of using pinfo->private_data (and other
> members than have since been removed).

If a dissector documents what data it provides or requires, then how would it
be harder to follow the code flow? The data is per-packet and you are supposed
to set the field before invoking the subdissector.

> For this particular bug, I would prefer that http have 2 function signatures
> - one that expects TCP data and one that doesn't.  Then both functions would
> call a "common" function where necessary TCP data would be passed in
> (defaulted in function with NULL data)

HTTP has already multiple signatures (http-over-tls, http-over-sctp,
http-over-tcp and just "http"). IIRC only the "http-over-tcp" uses the data
parameter at the moment. Alternative functions will not solve the problem of
Lua being able to obtain a dissector handle and then invoking that with a NULL
data parameter.

For this case where the "tcp" dissector always provides the data, we could add
this special case in the Lua dissector:

 If the original dissector table matches the one of the subdissector, pass the
data parameter. E.g. the original http dissector is registered on "tcp.port",
the new dissector function is likely registered to this as well, so propagate
the tcp_info. If the new dissector function was registered through
"usb.product" (for example), then just pass NULL.

This does not help though in cases like the modbus (mbtcp) dissector since that
is not registered through a dissector table. The current APIs unfortunately do
not have the information on the expected type.

-- 
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://wireshark.org/mailman/options/wireshark-bugs
 mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe

[Wireshark-bugs] [Bug 12853] "File does not exist" error when capturing from a pipe

[bugzilla-daemon]

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

Guy Harris  changed:

   What|Removed |Added

Summary|File does not exist |"File does not exist" error
   ||when capturing from a pipe

-- 
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://wireshark.org/mailman/options/wireshark-bugs
 mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe

[Wireshark-bugs] [Bug 12853] File does not exist

[bugzilla-daemon]

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

--- Comment #1 from Guy Harris  ---
That's an appropriate file name when capturing from the standard input; perhaps
there's a race condition where the "here's the capture file" message arrives in
Wireshark before the file is created, or perhaps the file somehow got removed.

-- 
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://wireshark.org/mailman/options/wireshark-bugs
 mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe

[Wireshark-bugs] [Bug 12826] usage http-tcp dissector from lua dissector lead to Segmentation fault

[bugzilla-daemon]

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

--- Comment #9 from Michael Mann  ---
(In reply to Peter Wu from comment #8)
> Maybe we should drop this data parameter and use p_add_proto_data:

I would rather rewrite the dissector function signature (to have "data pointer
+ type") than use p_add_proto_data.  It makes code flow MUCH harder to follow
(and easier to create bugs as a result).  It was one of the reasons I tried to
rid dissectors of using pinfo->private_data (and other members than have since
been removed).

For this particular bug, I would prefer that http have 2 function signatures -
one that expects TCP data and one that doesn't.  Then both functions would call
a "common" function where necessary TCP data would be passed in (defaulted in
function with NULL data)

-- 
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://wireshark.org/mailman/options/wireshark-bugs
 mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe

[Wireshark-bugs] [Bug 12839] Buildbot crash output: randpkt-2016-09-08-27704.pcap

[bugzilla-daemon]

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

--- Comment #6 from Peter Wu  ---
*** Bug 12852 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://wireshark.org/mailman/options/wireshark-bugs
 mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe

[Wireshark-bugs] [Bug 12852] Buildbot crash output: randpkt-2016-09-09-30969.pcap

[bugzilla-daemon]

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

Peter Wu  changed:

   What|Removed |Added

 Status|CONFIRMED   |RESOLVED
 CC||pe...@lekensteyn.nl
 Resolution|--- |DUPLICATE

--- Comment #1 from Peter Wu  ---
randpkt-2016-09-09-30969.pcap

Stats: 101M malloced (30M for red zones) by 1155800 calls
Stats: 9M realloced by 15813 calls
Stats: 98M freed by 1143840 calls
Stats: 0M really freed by 0 calls
Stats: 152M (152M-0M) mmaped; 2134 maps, 0 unmaps
  mallocs by size class: 2:179478; 3:198755; 4:302063; 6:51991; 7:60282;
8:233003; 11:23667; 12:11501; 13:1532; 14:734; 15:68; 16:7; 17:56735; 18:30167;
19:9; 20:12; 21:1521; 22:160; 23:28; 24:4; 25:1938; 26:46; 27:28; 29:1512;
30:23; 31:7; 32:1; 33:234; 34:16; 36:1; 37:104; 38:9; 41:78; 42:5; 45:31; 46:4;
49:16; 50:2; 
Stats: malloc large: 28
Stats: StackDepot: 71137 ids; 9M allocated
Stats: SizeClassAllocator64: 133M mapped in 1158197 allocations; remains
1158197
...
Maximum resident set size (kbytes): 569568

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

-- 
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://wireshark.org/mailman/options/wireshark-bugs
 mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe

[Wireshark-bugs] [Bug 12849] Buildbot crash output: fuzz-2016-09-08-582.pcap

[bugzilla-daemon]

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

Peter Wu  changed:

   What|Removed |Added

 Status|CONFIRMED   |RESOLVED
 CC||pe...@lekensteyn.nl
 Resolution|--- |DUPLICATE

--- Comment #1 from Peter Wu  ---


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

-- 
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://wireshark.org/mailman/options/wireshark-bugs
 mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe

[Wireshark-bugs] [Bug 12839] Buildbot crash output: randpkt-2016-09-08-27704.pcap

[bugzilla-daemon]

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

--- Comment #5 from Peter Wu  ---
*** Bug 12850 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://wireshark.org/mailman/options/wireshark-bugs
 mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe

[Wireshark-bugs] [Bug 12850] Buildbot crash output: randpkt-2016-09-09-7566.pcap

[bugzilla-daemon]

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

Peter Wu  changed:

   What|Removed |Added

 Status|CONFIRMED   |RESOLVED
 CC||pe...@lekensteyn.nl
 Resolution|--- |DUPLICATE

--- Comment #1 from Peter Wu  ---
See duplicate. This is the output for this file.

Stats: 101M malloced (30M for red zones) by 1155139 calls
Stats: 9M realloced by 15821 calls
Stats: 98M freed by 1143179 calls
Stats: 0M really freed by 0 calls
Stats: 151M (151M-0M) mmaped; 2132 maps, 0 unmaps
  mallocs by size class: 2:179401; 3:198713; 4:301781; 6:52043; 7:60269;
8:232838; 11:23674; 12:11489; 13:1532; 14:734; 15:68; 16:7; 17:56611; 18:30167;
19:9; 20:12; 21:1581; 22:160; 23:28; 24:4; 25:1838; 26:46; 27:28; 29:1547;
30:23; 31:7; 32:1; 33:234; 34:16; 36:1; 37:104; 38:9; 41:78; 42:5; 45:31; 46:4;
49:16; 50:2; 
Stats: malloc large: 28
Stats: StackDepot: 71144 ids; 9M allocated
Stats: SizeClassAllocator64: 133M mapped in 1157582 allocations; remains
1157582
...
Maximum resident set size (kbytes): 571464

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

-- 
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://wireshark.org/mailman/options/wireshark-bugs
 mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe

[Wireshark-bugs] [Bug 12848] Buildbot crash output: randpkt-2016-09-09-20651.pcap

[bugzilla-daemon]

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

Peter Wu  changed:

   What|Removed |Added

 Status|CONFIRMED   |RESOLVED
 CC||pe...@lekensteyn.nl
 Resolution|--- |DUPLICATE

--- Comment #1 from Peter Wu  ---
See linked duplicates.

Stats: 101M malloced (30M for red zones) by 1156966 calls
Stats: 9M realloced by 15814 calls
Stats: 98M freed by 1145006 calls
Stats: 0M really freed by 0 calls
Stats: 152M (152M-0M) mmaped; 2134 maps, 0 unmaps
  mallocs by size class: 2:179452; 3:198890; 4:302537; 6:52155; 7:60315;
8:233278; 11:23666; 12:11528; 13:1532; 14:734; 15:68; 16:7; 17:56830; 18:30167;
19:9; 20:12; 21:1603; 22:160; 23:28; 24:4; 25:1878; 26:46; 27:28; 29:1480;
30:23; 31:7; 32:1; 33:234; 34:16; 36:1; 37:104; 38:9; 41:78; 42:5; 45:31; 46:4;
49:16; 50:2; 
Stats: malloc large: 28
Stats: StackDepot: 71140 ids; 9M allocated
Stats: SizeClassAllocator64: 133M mapped in 1159375 allocations; remains
1159375
...
Maximum resident set size (kbytes): 573276

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

-- 
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://wireshark.org/mailman/options/wireshark-bugs
 mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe

[Wireshark-bugs] [Bug 12839] Buildbot crash output: randpkt-2016-09-08-27704.pcap

[bugzilla-daemon]

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

--- Comment #4 from Peter Wu  ---
*** Bug 12848 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://wireshark.org/mailman/options/wireshark-bugs
 mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe

[Wireshark-bugs] [Bug 12839] Buildbot crash output: randpkt-2016-09-08-27704.pcap

[bugzilla-daemon]

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

--- Comment #3 from Peter Wu  ---
*** Bug 12844 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://wireshark.org/mailman/options/wireshark-bugs
 mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe

[Wireshark-bugs] [Bug 12844] Buildbot crash output: randpkt-2016-09-08-5112.pcap

[bugzilla-daemon]

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

Peter Wu  changed:

   What|Removed |Added

 Status|CONFIRMED   |RESOLVED
 CC||pe...@lekensteyn.nl
 Resolution|--- |DUPLICATE

--- Comment #1 from Peter Wu  ---
Similar as bug 12839 (command for both outputs include the '-V' option btw):

Stats: 101M malloced (30M for red zones) by 1154758 calls
Stats: 9M realloced by 15817 calls
Stats: 98M freed by 1142798 calls
Stats: 0M really freed by 0 calls
Stats: 151M (151M-0M) mmaped; 2131 maps, 0 unmaps
  mallocs by size class: 2:179415; 3:198689; 4:301643; 6:51883; 7:60231;
8:232735; 11:23670; 12:11574; 13:1532; 14:734; 15:68; 16:7; 17:56646; 18:30167;
19:9; 20:12; 21:1539; 22:160; 23:28; 24:4; 25:1865; 26:46; 27:28; 29:1514;
30:23; 31:7; 32:1; 33:234; 34:16; 36:1; 37:104; 38:9; 41:78; 42:5; 45:31; 46:4;
49:16; 50:2; 
Stats: malloc large: 28
Stats: StackDepot: 71145 ids; 9M allocated
Stats: SizeClassAllocator64: 133M mapped in 1157344 allocations; remains
1157344
...
Maximum resident set size (kbytes): 571008

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

-- 
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://wireshark.org/mailman/options/wireshark-bugs
 mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe

[Wireshark-bugs] [Bug 12839] Buildbot crash output: randpkt-2016-09-08-27704.pcap

[bugzilla-daemon]

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

--- Comment #2 from Peter Wu  ---
oops, picked the wrong file. Corrected output:
randpkt-2016-09-08-27704.pcap
Stats: 101M malloced (30M for red zones) by 1156816 calls
Stats: 9M realloced by 15816 calls
Stats: 98M freed by 1144856 calls
...
Stats: SizeClassAllocator64: 133M mapped in 1159425 allocations; remains
1159425
...
Maximum resident set size (kbytes): 568456

For empty:
...
Stats: SizeClassAllocator64: 28M mapped in 261925 allocations; remains 261925
...

Input file was about 5MB. Don't think we can do a lot 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://wireshark.org/mailman/options/wireshark-bugs
 mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe

[Wireshark-bugs] [Bug 12839] Buildbot crash output: randpkt-2016-09-08-27704.pcap

[bugzilla-daemon]

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

Peter Wu  changed:

   What|Removed |Added

 Status|CONFIRMED   |RESOLVED
 CC||pe...@lekensteyn.nl
 Resolution|--- |WORKSFORME

--- Comment #1 from Peter Wu  ---
Memory usage is not excessive for me on v2.3.0rc0-617-gae7c4ad

WIRESHARK_DEBUG_SP_NO_CHUNKS=1 WIRESHARK_DEBUG_EP_NO_CHUNKS=1
WIRESHARK_DEBUG_WMEM_OVERRIDE=simple G_SLICE=always-malloc HOME=$PWD/wshome
ASAN_OPTIONS=print_stats=1:atexit=1 \time -v
tshark -r fuzz-2016-08-26-17937.pcap

Stats: 37M malloced (6M for red zones) by 295762 calls
Stats: 10M realloced by 7144 calls
Stats: 34M freed by 283799 calls
...
Maximum resident set size (kbytes): 455416

with an empty pcap:
Stats: 33M malloced (6M for red zones) by 260383 calls
Stats: 8M realloced by 5831 calls
Stats: 30M freed by 248436 calls
...
Maximum resident set size (kbytes): 449332

Closing, the buildbot possibly had a bad day.

-- 
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://wireshark.org/mailman/options/wireshark-bugs
 mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe

[Wireshark-bugs] [Bug 12826] usage http-tcp dissector from lua dissector lead to Segmentation fault

[bugzilla-daemon]

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

Peter Wu  changed:

   What|Removed |Added

 CC||g...@alum.mit.edu,
   ||hadri...@yahoo.com,
   ||pe...@lekensteyn.nl

--- Comment #8 from Peter Wu  ---
Comment 5 uses an approach that seems quite common for Lua dissectors (I think
it is also documented in an example Lua dissector): obtain old handle, override
dissectors, call old dissector and act on it.

I think that https://code.wireshark.org/review/16176 is sufficient for
correctness (i.e. not crash on missing data), but unfortunately loses the
possibility to propagate the end-of-stream flag from the TCP layer to HTTP.

In C dissectors, we rely on code review and conventions to avoid illegal "data"
parameters (though we do have type confusion problems at times).

We cannot rely on the Lua dissector not to pass garbage. Currently it always
passes a NULL data parameter which is handled gracefully by at least:
modbus (mbtcp), ethertype, wlan (ieee80211). (Searched for
call_dissector_with_data and looked at a random sample).

Maybe we should drop this data parameter and use p_add_proto_data:
 - as provider: the tcp dissector can provide "tcpinfo" to the interested
subdissectors.
 - as consumer: the mbtcp dissector requires a "packet_type" parameter from
"consumers" that invoke this dissector (cip, ecmp).

The type is more explicit in this case (defined by the protocol ID and the
protocol-specific key).

-- 
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://wireshark.org/mailman/options/wireshark-bugs
 mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe

[Wireshark-bugs] [Bug 12859] New: Display data rate fields for VHT rates invalid with BCC modulation

[bugzilla-daemon]

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

Bug ID: 12859
   Summary: Display data rate fields for VHT rates invalid with
BCC modulation
   Product: Wireshark
   Version: 2.2.0
  Hardware: All
OS: All
Status: UNCONFIRMED
  Severity: Major
  Priority: Low
 Component: Dissection engine (libwireshark)
  Assignee: bugzilla-ad...@wireshark.org
  Reporter: shukl...@gmail.com
CC: alexis.lagou...@gmail.com, thomas.baude...@gmail.com
Depends on: 12558

Created attachment 14897
  --> https://bugs.wireshark.org/bugzilla/attachment.cgi?id=14897=edit
1 stream mcs 9 vht ppdu

Build Information:
Wireshark 2.2.0 (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 4.8.7, with libpcap, without POSIX capabilities, with
GLib 2.48.2, with zlib 1.2.5, without SMI, with c-ares 1.11.0, without Lua,
without GnuTLS, with Gcrypt 1.7.3, with MIT Kerberos, with GeoIP, with
QtMultimedia, without AirPcap.

Running on Mac OS X 10.11.6, build 15G1004 (Darwin 15.6.0), with locale
en_US.UTF-8, with libpcap version 1.5.3 - Apple version 54, with Gcrypt 1.7.3,
with zlib 1.2.5.
Intel(R) Core(TM) i7-5557U CPU @ 3.10GHz (with SSE4.2)

Built using clang 4.2.1 Compatible Apple LLVM 7.3.0 (clang-703.0.31).

--
+++ This bug is related to Bug #12558 +++

I don't know the reason why data rate is not computed for 1/2 stream VHT PPDU
sent at e.g., MCS 9?

As per the spec, these data rates are invalid assuming BCC encoding however
pretty much most if not all chipset vendors support these MCSs when encoded
with LDPC.
If a system receives these PPDUs there is no reason for wireshark not to
compute the data rate when in fact it decodes other fields like MCS, encoding,
stream, etc.

There are two ways we could deal with this
1. ieee80211_vhtvalid[mcs].valid[bandwidth] check should take into account LDPC
or BCC being used, in former case should return True, or
2. eliminate ieee80211_vhtvalid[mcs].valid[bandwidth] entirely due to the fact
that wireshark is dissecting a valid received PPDU, which it would not have
been able to receive if BCC would have been used instead of LDPC on the
transmit side.
There will never be a pcap(ng) or a system, during live capture, can ever
receive a BCC encoded VHT PPDU with illegal MCSs like 1/2 stream MCS9: that
would be already dropped on transmit side, or undecoded by the receive MAC
firmware.

I prefer approach 2 above, being simple and makes more sense and the change
below at least meet my expectation [1]

It fills the gap when a valid good fcs PPDU is seen in wireshark but data rate
is not displayed (someone having a filter simply miss these)

[1] 
--- wireshark-2.2.0/epan/dissectors/packet-ieee80211-radiotap.c2016-09-07
09:59:03.0 -0700
+++ wireshark-2.2.0/epan/dissectors/packet-ieee80211-radiotap.c2016-09-09
10:54:40.0 -0700
@@ -1804,8 +1804,8 @@ dissect_radiotap(tvbuff_t * tvb, packet_
 }

 if (can_calculate_rate && mcs <= MAX_MCS_VHT_INDEX &&
-nss <= MAX_VHT_NSS &&
-ieee80211_vhtvalid[mcs].valid[bandwidth][nss]) {
+nss <= MAX_VHT_NSS /*&&
+ieee80211_vhtvalid[mcs].valid[bandwidth][nss]*/) {
 float rate =
ieee80211_vhtinfo[mcs].rates[bandwidth][gi_length] * nss;
 if (rate != 0.0f && user_tree) {
 rate_ti = proto_tree_add_float_format(user_tree,

-- 
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://wireshark.org/mailman/options/wireshark-bugs
 mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe

[Wireshark-bugs] [Bug 12558] Inconsistent VHT data rate

[bugzilla-daemon]

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

Ashish Shukla  changed:

   What|Removed |Added

 Blocks||12859

-- 
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://wireshark.org/mailman/options/wireshark-bugs
 mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe

[Wireshark-bugs] [Bug 12858] New: Buildbot crash output: randpkt-2016-09-09-12063.pcap

[bugzilla-daemon]

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

Bug ID: 12858
   Summary: Buildbot crash output: randpkt-2016-09-09-12063.pcap
   Product: Wireshark
   Version: unspecified
  Hardware: x86-64
   URL: https://www.wireshark.org/download/automated/captures/
randpkt-2016-09-09-12063.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/randpkt-2016-09-09-12063.pcap

stderr:
Input file: 

Build host information:
Linux wsbb04 4.4.0-34-generic #53-Ubuntu SMP Wed Jul 27 16:06:39 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=3669
BUILDBOT_URL=http://buildbot.wireshark.org/wireshark-master/
BUILDBOT_BUILDERNAME=Clang Code Analysis
BUILDBOT_GOT_REVISION=ae7c4ad3c0975887ee320409df78ad38ccad901a

Return value:  134

Dissector bug:  0

Valgrind error count: 




Command and args: ./tshark -nVxr

==12072==ERROR: AddressSanitizer failed to allocate 0x1000 (268435456)
bytes at address 7fff7000 (errno: 12)
==12072==ReserveShadowMemoryRange failed while trying to map 0x1000 bytes.
Perhaps you're using ulimit -v

[ 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://wireshark.org/mailman/options/wireshark-bugs
 mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe

[Wireshark-bugs] [Bug 12857] New: Wireshark becomes unresponsive while capturing packets.

[bugzilla-daemon]

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

Bug ID: 12857
   Summary: Wireshark becomes unresponsive while capturing
packets.
   Product: Wireshark
   Version: 2.2.0
  Hardware: x86
OS: Windows 10
Status: UNCONFIRMED
  Severity: Normal
  Priority: Low
 Component: Dissection engine (libwireshark)
  Assignee: bugzilla-ad...@wireshark.org
  Reporter: butlerrsc...@gmail.com

Created attachment 14896
  --> https://bugs.wireshark.org/bugzilla/attachment.cgi?id=14896=edit
Slow loading packet trace and .png of configuration

Build Information:
Version 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 10, build 10586, 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) i7-3770 CPU @ 3.40GHz (with SSE4.2), with 16338MB of
physical memory.


Built using Microsoft Visual C++ 12.0 build 40629

Wireshark is Open Source Software released under the GNU General Public
License.

Check the man page and http://www.wireshark.org for more information.
--
While attempting to trace browser access to 

http://journaldev.us8.list-manage1.com/track/click?u=612f3d966c86000f37699d8cf=9789c2e700=bc884fdbb6

wireshark becomes unresponsive.  It's not hung since if you wait long enough
(several minutes) you can get responses to clicks.  I saved a session (3758
packets) where this was happening.  When you try to load this saved session
back into wireshark, the load process takes 5-6 minutes.  I have no reason to
think that the particular URL I used is significant.

I've attached a zip file with the saved packets and a .png file that shows my
system configuration.  Let me know if there's more that I should send.


Thanks.

PS Ignore the "component" field in the report.  I have no idea where the
problem is.

-- 
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://wireshark.org/mailman/options/wireshark-bugs
 mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe

[Wireshark-bugs] [Bug 12856] New: Buildbot crash output: randpkt-2016-09-09-31157.pcap

[bugzilla-daemon]

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

Bug ID: 12856
   Summary: Buildbot crash output: randpkt-2016-09-09-31157.pcap
   Product: Wireshark
   Version: unspecified
  Hardware: x86-64
   URL: https://www.wireshark.org/download/automated/captures/
randpkt-2016-09-09-31157.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/randpkt-2016-09-09-31157.pcap

stderr:
Input file: 

Build host information:
Linux wsbb04 4.4.0-34-generic #53-Ubuntu SMP Wed Jul 27 16:06:39 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=3668
BUILDBOT_URL=http://buildbot.wireshark.org/wireshark-master/
BUILDBOT_BUILDERNAME=Clang Code Analysis
BUILDBOT_GOT_REVISION=82f1d14daea37bf46395dc3fdfb27662f31870d2

Return value:  134

Dissector bug:  0

Valgrind error count: 




Command and args: ./tshark -nVxr

==31186==ERROR: AddressSanitizer failed to allocate 0x1000 (268435456)
bytes at address 7fff7000 (errno: 12)
==31186==ReserveShadowMemoryRange failed while trying to map 0x1000 bytes.
Perhaps you're using ulimit -v

[ 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://wireshark.org/mailman/options/wireshark-bugs
 mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe

[Wireshark-bugs] [Bug 11755] Unrecognized text: CDATA in XML not parsed correctly

[bugzilla-daemon]

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

Thomas W.  changed:

   What|Removed |Added

 Status|RESOLVED|VERIFIED

--- Comment #8 from Thomas W.  ---
Thank you so much.
Works fine for me in v2.2.0-0-g5368c50 from master-2.2

-- 
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://wireshark.org/mailman/options/wireshark-bugs
 mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe

[Wireshark-bugs] [Bug 12845] First start with non-empty extcap folder after install or reboot hangs at "initializing tap listeners"

[bugzilla-daemon]

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

--- Comment #20 from Pavel Sindelka  ---
(In reply to Pavel Sindelka from comment #17)
> (In reply to Roland Knall from comment #13)
> > The number of interfaces should not be an issue, androiddump generates a lot
> > more.
> 
> As one of the guys at ask.wireshark.org declares he's located in Texas and
> he uses a pretty English-looking name, I doubt he uses any exotic character
> encoding on his Windows machine.

It seems even English-speaking Windows are not a guarantee that the names will
be pure ASCII. The other guy of the two has provided his --extcap-config output
(see the full dump below), and there are two items using non-ASCII characters,
one per each root hub:

value {arg=99}{value=1_7}{display=Jeppe SchoubyeÔÇÖs Mouse
#1}{enabled=false}{parent=1_3}
value {arg=99}{value=9_1}{display=Dell Wireless 5809e GobiÔäó 4G LTE Mobile
Broadband Card}{enabled=false}{parent=9}

The full dump follows.

c:\Program Files\Wireshark\extcap_x>USBPcapCMD.exe --extcap-config
--extcap-interface \.\USBPcap1

arg {number=0}{call=--snaplen}{display=Snapshot length}{tooltip=Snapshot
length}{type=integer}{range=0,65535}{default=65535}
arg {number=1}{call=--bufferlen}{display=Capture buffer length}{tooltip=USBPcap
kernel-mode capture buffer length in
bytes}{type=integer}{range=0,134217728}{default=1048576}
arg {number=2}{call=--capture-from-all-devices}{display=Capture from all
devices connected}{tooltip=Capture from all devices connected despite other
options}{type=boolflag}{default=true}
arg {number=3}{call=--capture-from-new-devices}{display=Capture from newly
connected devices}{tooltip=Automatically start capture on all newly connected
devices}{type=boolflag}{default=true}
arg {number=99}{call=--devices}{display=Attached USB Devices}{tooltip=Select
individual devices to capture from}{type=multicheck}
value {arg=99}{value=5}{display=[5] Generic USB Hub}{enabled=true}
value {arg=99}{value=1}{display=[1] Intel(R) Wireless
Bluetooth(R)}{enabled=true}{parent=5}
value {arg=99}{value=1_1}{display=Microsoft Bluetooth LE
Enumerator}{enabled=false}{parent=1}
value {arg=99}{value=1_2}{display=Bluetooth Device (RFCOMM Protocol
TDI)}{enabled=false}{parent=1}
value {arg=99}{value=1_3}{display=Microsoft Bluetooth
Enumerator}{enabled=false}{parent=1}
value {arg=99}{value=1_4}{display=Bluetooth HID
Device}{enabled=false}{parent=1_3}
value {arg=99}{value=1_5}{display=HID-compliant
mouse}{enabled=false}{parent=1_4}
value {arg=99}{value=1_6}{display=Device Identification
Service}{enabled=false}{parent=1_3}
value {arg=99}{value=1_7}{display=Jeppe SchoubyeÔÇÖs Mouse
#1}{enabled=false}{parent=1_3}
value {arg=99}{value=1_8}{display=Bluetooth Device (Personal Area
Network)}{enabled=false}{parent=1}
value {arg=99}{value=2}{display=[2] USB Composite
Device}{enabled=true}{parent=5}
value {arg=99}{value=2_1}{display=Integrated Webcam}{enabled=false}{parent=2}
value {arg=99}{value=3}{display=[3] USB Composite
Device}{enabled=true}{parent=5}
value {arg=99}{value=3_1}{display=Dell ControlVault w/ Fingerprint Swipe
Sensor}{enabled=false}{parent=3}
value {arg=99}{value=3_2}{display=Control Vault w/ Fingerprint Swipe
Sensor}{enabled=false}{parent=3_1}
value {arg=99}{value=3_3}{display=Broadcom Usbccid Smartcard Reader
(WUDF)}{enabled=false}{parent=3}
value {arg=99}{value=3_4}{display=Smart card filter
driver}{enabled=false}{parent=3_3}
value {arg=99}{value=3_5}{display=Broadcom Usbccid Smartcard Reader
(WUDF)}{enabled=false}{parent=3}
value {arg=99}{value=3_6}{display=Smart card filter
driver}{enabled=false}{parent=3_5}
value {arg=99}{value=3_7}{display=NFC USB Bus Driver}{enabled=false}{parent=3}
value {arg=99}{value=3_8}{display=NFC Proximity
Provider}{enabled=false}{parent=3_7}

c:\Program Files\Wireshark\extcap_x>USBPcapCMD.exe --extcap-config
--extcap-interface \.\USBPcap2

arg {number=0}{call=--snaplen}{display=Snapshot length}{tooltip=Snapshot
length}{type=integer}{range=0,65535}{default=65535}
arg {number=1}{call=--bufferlen}{display=Capture buffer length}{tooltip=USBPcap
kernel-mode capture buffer length in
bytes}{type=integer}{range=0,134217728}{default=1048576}
arg {number=2}{call=--capture-from-all-devices}{display=Capture from all
devices connected}{tooltip=Capture from all devices connected despite other
options}{type=boolflag}{default=true}
arg {number=3}{call=--capture-from-new-devices}{display=Capture from newly
connected devices}{tooltip=Automatically start capture on all newly connected
devices}{type=boolflag}{default=true}
arg {number=99}{call=--devices}{display=Attached USB Devices}{tooltip=Select
individual devices to capture from}{type=multicheck}
value {arg=99}{value=21}{display=[21] Generic USB Hub}{enabled=true}
value {arg=99}{value=24}{display=[24] USB Composite
Device}{enabled=true}{parent=21}
value {arg=99}{value=24_1}{display=USB Input Device}{enabled=false}{parent=24}
value {arg=99}{value=24_2}{display=HID Keyboard

[Wireshark-bugs] [Bug 12845] First start with non-empty extcap folder after install or reboot hangs at "initializing tap listeners"

[bugzilla-daemon]

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

--- Comment #19 from Pavel Sindelka  ---
(In reply to Roland Knall from comment #18)
> (In reply to Pavel Sindelka from comment #17)
> > (In reply to Roland Knall from comment #13)
> > > The number of interfaces should not be an issue, androiddump generates a 
> > > lot
> > > more.
> > 
> I've tested against that in the past, but I will try to look further into
> this issue during the weekend.

The nesting depth alone is not the issue.

The following chain (one level deeper than the real one) is handled without an
issue:

D:\Pracovni data\EoE-ISDN>extcaptest2.exe --extcap-config
arg {number=0}{call=--snaplen}{display=Snapshot length}{tooltip=Snapshot
length}{type=integer}{range=0,65535}{default=65535}
arg {number=1}{call=--filename}{display=Destination for audio
files}{tooltip=Select target directory}{type=fileselect}
arg {number=99}{call=--devices}{display=Attached USB Devices}{tooltip=Select
individual devices to capture from}{type=multicheck}
value {arg=99}{value=1}{display=[1] Generic USB Hub}{enabled=true}
value {arg=99}{value=2}{display=[2] Broadcom 20702 Bluetooth 4.0
Adapter}{enabled=true}{parent=1}
value {arg=99}{value=2_3}{display=Microsoft Bluetooth
Enumerator}{enabled=false}{parent=2}
value {arg=99}{value=2_25}{display=PLT_Legend Hands-Free Audio and Call Control
HID Enumerator}{enabled=false}{parent=2_3}
value {arg=99}{value=2_26}{display=PLT_Legend
Hands-Free}{enabled=false}{parent=2_25}
value {arg=99}{value=2_30}{display=PLT_Legend Hands-Free
Microphone}{enabled=false}{parent=2_26}

-- 
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://wireshark.org/mailman/options/wireshark-bugs
 mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe

[Wireshark-bugs] [Bug 12855] Follow TCP Stream shows duplicate stream data

[bugzilla-daemon]

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

--- Comment #1 from nobletr...@gmail.com ---
Created attachment 14895
  --> https://bugs.wireshark.org/bugzilla/attachment.cgi?id=14895=edit
screenshot of 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://wireshark.org/mailman/options/wireshark-bugs
 mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe

[Wireshark-bugs] [Bug 12855] New: Follow TCP Stream shows duplicate stream data

[bugzilla-daemon]

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

Bug ID: 12855
   Summary: Follow TCP Stream shows duplicate stream data
   Product: Wireshark
   Version: 2.3.x (Experimental)
  Hardware: x86
OS: Mac OS X 10.11
Status: UNCONFIRMED
  Severity: Normal
  Priority: Low
 Component: Qt UI
  Assignee: bugzilla-ad...@wireshark.org
  Reporter: nobletr...@gmail.com

Created attachment 14894
  --> https://bugs.wireshark.org/bugzilla/attachment.cgi?id=14894=edit
capture of slowloris attack

Build Information:
Version 2.3.0-616-g82f1d14 (v2.3.0rc0-616-g82f1d14 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.3.2, with libpcap, without POSIX capabilities, with
GLib 2.36.0, with zlib 1.2.5, with SMI 0.4.8, with c-ares 1.10.0, with Lua
5.2.4, with GnuTLS 2.12.19, with Gcrypt 1.5.0, with MIT Kerberos, with GeoIP,
with QtMultimedia, without AirPcap.

Running on Mac OS X 10.11.6, build 15G1004 (Darwin 15.6.0), with locale C, with
libpcap version 1.5.3 - Apple version 54, with GnuTLS 2.12.19, with Gcrypt
1.5.0, with zlib 1.2.5.
Intel(R) Core(TM) i7-4980HQ CPU @ 2.80GHz (with SSE4.2)

Built using llvm-gcc 4.2.1 (Based on Apple Inc. build 5658) (LLVM build
2336.9.00).

Wireshark is Open Source Software released under the GNU General Public
License.

Check the man page and http://www.wireshark.org for more information.
--
Take attached PCAP, right click, select "Follow TCP Stream". Observe that data
packets are printed twice in all views (ASCII, Raw, C Arrays, etc).

-- 
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://wireshark.org/mailman/options/wireshark-bugs
 mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe

[Wireshark-bugs] [Bug 12793] Expert Info ssl.resumed incorrect after TLS renegotiate

[bugzilla-daemon]

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

--- Comment #20 from Peter Wu  ---
(In reply to Andre Luyer from comment #18)

> Maybe there is another way: in case of a resumed session both ServerHello
> and ChangeCipherSpec will be in the same frame (so that frame is either
> filtered or not), otherwise it is not resumed. (In theory it could be spilt
> over two frames, but then the TLS is badly implemented on the server.)
> So that should work in case of a -R filter too -- as long as the capture is
> not snapped.

The TLS protocol does not require records to be merged into a single TCP
segment, so there might be a case where a false negative exists (resulting in
inability to resume using session tickets). I think that the current heuristics
should be good enough.

> And use ClientHello to reset the ssl state to handle the renegotiated
> session(s) correctly.

If you are unlucky, packets are re-ordered and the Client Hello comes just
after the Server Hello in the pcap. I don't know if this generally causes other
issues, but it was taken into consideration for the patch.

> See you at SharkFest16(?)!

See you at SharkFest Europe? :) https://sharkfesteurope.wireshark.org/

-- 
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://wireshark.org/mailman/options/wireshark-bugs
 mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe

[Wireshark-bugs] [Bug 12845] First start with non-empty extcap folder after install or reboot hangs at "initializing tap listeners"

[bugzilla-daemon]

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

--- Comment #18 from Roland Knall  ---
(In reply to Pavel Sindelka from comment #17)
> (In reply to Roland Knall from comment #13)
> > The number of interfaces should not be an issue, androiddump generates a lot
> > more.
> 
> As one of the guys at ask.wireshark.org declares he's located in Texas and
> he uses a pretty English-looking name, I doubt he uses any exotic character
> encoding on his Windows machine.
> 
> So could it be that the depth of item nesting is the cause? Look at the
> parent to value reference chain below:
> 
> value {arg=99}{value=1}{display=[1] Generic USB Hub}{enabled=true}
> 
>   value {arg=99}{value=2}{display=[2] Broadcom 20702 Bluetooth 4.0
> Adapter}{enabled=true}{parent=1}
> 
> value {arg=99}{value=2_3}{display=Microsoft Bluetooth
> Enumerator}{enabled=false}{parent=2}
> 
>   value {arg=99}{value=2_25}{display=PLT_Legend Hands-Free Audio and
> Call Control HID Enumerator}{enabled=false}{parent=2_3}
> 
>  value {arg=99}{value=2_26}{display=PLT_Legend
> Hands-Free}{enabled=false}{parent=2_25}


I've tested against that in the past, but I will try to look further into this
issue during the weekend.

-- 
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://wireshark.org/mailman/options/wireshark-bugs
 mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe

[Wireshark-bugs] [Bug 12854] New: Buildbot crash output: randpkt-2016-09-09-14931.pcap

[bugzilla-daemon]

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

Bug ID: 12854
   Summary: Buildbot crash output: randpkt-2016-09-09-14931.pcap
   Product: Wireshark
   Version: unspecified
  Hardware: x86-64
   URL: https://www.wireshark.org/download/automated/captures/
randpkt-2016-09-09-14931.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/randpkt-2016-09-09-14931.pcap

stderr:
Input file: 

Build host information:
Linux wsbb04 4.4.0-34-generic #53-Ubuntu SMP Wed Jul 27 16:06:39 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=3667
BUILDBOT_URL=http://buildbot.wireshark.org/wireshark-master/
BUILDBOT_BUILDERNAME=Clang Code Analysis
BUILDBOT_GOT_REVISION=faa04b13186fe22afef6f659e7a26ec0ef37b8a6

Return value:  134

Dissector bug:  0

Valgrind error count: 




Command and args: ./tshark -nVxr

==14954==ERROR: AddressSanitizer failed to allocate 0x1000 (268435456)
bytes at address 7fff7000 (errno: 12)
==14954==ReserveShadowMemoryRange failed while trying to map 0x1000 bytes.
Perhaps you're using ulimit -v

[ 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://wireshark.org/mailman/options/wireshark-bugs
 mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe

[Wireshark-bugs] [Bug 12845] First start with non-empty extcap folder after install or reboot hangs at "initializing tap listeners"

[bugzilla-daemon]

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

--- Comment #17 from Pavel Sindelka  ---
(In reply to Roland Knall from comment #13)
> The number of interfaces should not be an issue, androiddump generates a lot
> more.

As one of the guys at ask.wireshark.org declares he's located in Texas and he
uses a pretty English-looking name, I doubt he uses any exotic character
encoding on his Windows machine.

So could it be that the depth of item nesting is the cause? Look at the parent
to value reference chain below:

value {arg=99}{value=1}{display=[1] Generic USB Hub}{enabled=true}

  value {arg=99}{value=2}{display=[2] Broadcom 20702 Bluetooth 4.0
Adapter}{enabled=true}{parent=1}

value {arg=99}{value=2_3}{display=Microsoft Bluetooth
Enumerator}{enabled=false}{parent=2}

  value {arg=99}{value=2_25}{display=PLT_Legend Hands-Free Audio and Call
Control HID Enumerator}{enabled=false}{parent=2_3}

 value {arg=99}{value=2_26}{display=PLT_Legend
Hands-Free}{enabled=false}{parent=2_25}

-- 
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://wireshark.org/mailman/options/wireshark-bugs
 mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe

[Wireshark-bugs] [Bug 12853] New: File does not exist

[bugzilla-daemon]

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

Bug ID: 12853
   Summary: File does not exist
   Product: Wireshark
   Version: 2.2.0
  Hardware: x86
OS: Windows 7
Status: UNCONFIRMED
  Severity: Major
  Priority: Low
 Component: Capture file support (libwiretap)
  Assignee: bugzilla-ad...@wireshark.org
  Reporter: tukai...@gmail.com

Created attachment 14893
  --> https://bugs.wireshark.org/bugzilla/attachment.cgi?id=14893=edit
this is the error message

Build Information:
Paste the COMPLETE build information from "Help->About Wireshark", "wireshark
-v", or "tshark -v".
--
When I try to capture interface traffic in gns3 it some times gives error as
the file does not exist .Please check the attachment for the exact 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://wireshark.org/mailman/options/wireshark-bugs
 mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe

[Wireshark-bugs] [Bug 12845] First start with non-empty extcap folder after install or reboot hangs at "initializing tap listeners"

[bugzilla-daemon]

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

--- Comment #16 from Michal Labedzki  ---
Roland, I check text coding (add Polish letter like "ąąą", "łłł") in various
places like: interface display name, interface name, preference display name
(it saves parameters as expected) and it seems there is no issue (Linux, Qt4).

Does anyone know why my gdb cannot resolve symbols for extcap calls? For
example: search_cb(); "info locals" returns something strange (no local
variables in search_cb() - the same output for all extcap calls)

-- 
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://wireshark.org/mailman/options/wireshark-bugs
 mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe

[Wireshark-bugs] [Bug 12852] New: Buildbot crash output: randpkt-2016-09-09-30969.pcap

[bugzilla-daemon]

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

Bug ID: 12852
   Summary: Buildbot crash output: randpkt-2016-09-09-30969.pcap
   Product: Wireshark
   Version: unspecified
  Hardware: x86-64
   URL: https://www.wireshark.org/download/automated/captures/
randpkt-2016-09-09-30969.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/randpkt-2016-09-09-30969.pcap

stderr:
Input file: 

Build host information:
Linux wsbb04 4.4.0-34-generic #53-Ubuntu SMP Wed Jul 27 16:06:39 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=3666
BUILDBOT_URL=http://buildbot.wireshark.org/wireshark-master/
BUILDBOT_BUILDERNAME=Clang Code Analysis
BUILDBOT_GOT_REVISION=113c1ed24f21f4e3447b9374d109c7606e37d903

Return value:  134

Dissector bug:  0

Valgrind error count: 




Command and args: ./tshark -nVxr

==30978==ERROR: AddressSanitizer failed to allocate 0x1000 (268435456)
bytes at address 7fff7000 (errno: 12)
==30978==ReserveShadowMemoryRange failed while trying to map 0x1000 bytes.
Perhaps you're using ulimit -v

[ 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://wireshark.org/mailman/options/wireshark-bugs
 mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe

[Wireshark-bugs] [Bug 12845] First start with non-empty extcap folder after install or reboot hangs at "initializing tap listeners"

[bugzilla-daemon]

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

--- Comment #15 from Pavel Sindelka  ---
(In reply to Michal Labedzki from comment #14)

> Does usbpcap or your extcap has dynamic interfaces like androiddump?
> (interface that can show and gone all the time)

Nope. The extcaptest is just a Potemkin village which provides a constant
output all the time (I've given up further development as I've found that
capturing at several named pipes simultaneouslx fails as reported in some other
bug) and the USBPcapCMD provides a constant number of root hubs.

-- 
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://wireshark.org/mailman/options/wireshark-bugs
 mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe

[Wireshark-bugs] [Bug 12845] First start with non-empty extcap folder after install or reboot hangs at "initializing tap listeners"

[bugzilla-daemon]

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

--- Comment #14 from Michal Labedzki  ---
I can reproduce something else but it may be root cause. I have a crash when
new refresh interface list (sometimes Wireshark hangs).

Does usbpcap or your extcap has dynamic interfaces like androiddump? (interface
that can show and gone all the time)


Program received signal SIGSEGV, Segmentation fault.
0x7fffef364c36 in _IO_vfprintf_internal (s=,
format=, ap=) at vfprintf.c:1597
1597vfprintf.c: No such file or directory.
(gdb) bt
#0  0x7fffef364c36 in _IO_vfprintf_internal (s=,
format=, ap=) at vfprintf.c:1597
#1  0x7fffef4223d0 in ___vsnprintf_chk (s=0x58b050d0 "",
maxlen=, flags=1, slen=, format=0x55a541c4
"%s", 
args=0x7fffb558) at vsnprintf_chk.c:65
#2  0x769c7d92 in g_snprintf () from
/lib/x86_64-linux-gnu/libglib-2.0.so.0
#3  0x556f63b5 in search_cb ()
#4  0x556f5409 in extcap_foreach ()
#5  0x556f6512 in extcap_get_if_configuration ()
#6  0x556f6577 in extcap_has_configuration ()
#7  0x55905715 in InterfaceTree::display() () at
/home/labedmic/src/wireshark/ui/qt/interface_tree.cpp:217
#8  0x5590716c in InterfaceTree::interfaceListChanged() () at
/home/labedmic/src/wireshark/ui/qt/interface_tree.cpp:468



#0  0x7fffef364c36 in _IO_vfprintf_internal (s=,
format=, ap=) at vfprintf.c:1597
#1  0x7fffef4223d0 in ___vsnprintf_chk (s=0x589b5d70 "",
maxlen=, flags=1, slen=, format=0x55a541c4
"%s", 
args=0x7fffb558) at vsnprintf_chk.c:65
#2  0x769c7d92 in g_snprintf () from
/lib/x86_64-linux-gnu/libglib-2.0.so.0
#3  0x556f63b5 in search_cb ()
#4  0x556f5409 in extcap_foreach ()
#5  0x556f6512 in extcap_get_if_configuration ()
#6  0x556f6577 in extcap_has_configuration ()
#7  0x55905715 in InterfaceTree::display() () at
/home/labedmic/src/wireshark/ui/qt/interface_tree.cpp:217
#8  0x5590716c in InterfaceTree::interfaceListChanged() () at
/home/labedmic/src/wireshark/ui/qt/interface_tree.cpp:468

-- 
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://wireshark.org/mailman/options/wireshark-bugs
 mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe

[Wireshark-bugs] [Bug 12845] First start with non-empty extcap folder after install or reboot hangs at "initializing tap listeners"

[bugzilla-daemon]

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

Roland Knall  changed:

   What|Removed |Added

 CC||michal.labed...@tieto.com

--- Comment #13 from Roland Knall  ---
The number of interfaces should not be an issue, androiddump generates a lot
more. But the coding of the text could be. We did have issues in the past with
that. I'll copy Michal on the issue, maybe he can reproduce that, he had some
issues with androiddump

-- 
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://wireshark.org/mailman/options/wireshark-bugs
 mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe

[Wireshark-bugs] [Bug 12845] First start with non-empty extcap folder after install or reboot hangs at "initializing tap listeners"

[bugzilla-daemon]

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

--- Comment #12 from Pavel Sindelka  ---
Created attachment 14892
  --> https://bugs.wireshark.org/bugzilla/attachment.cgi?id=14892=edit
Process Monitor log illustrating the 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://wireshark.org/mailman/options/wireshark-bugs
 mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe

[Wireshark-bugs] [Bug 12845] First start with non-empty extcap folder after install or reboot hangs at "initializing tap listeners"

[bugzilla-daemon]

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

--- Comment #11 from Pavel Sindelka  ---
(In reply to Roland Knall from comment #10)
> (In reply to Pavel Sindelka from comment #9)
> > Repeating the question I've asked Pascal - will it move you further if I use
> > the Process Monitor and tell you what the command line parameters of the
> > zombie instance were?
> 
> It will certainly help, but my guess is, that it hangs with a call to
> "--extcap-interfaces". It will have something to do with gathering the list
> of interfaces or a specific feature for a specific interface.

So I hereby confirm that with the -3 version of USBPcap (uninstall -5, reboot,
manually remove USBPcapCMD.exe from ...\extcap, install -3, reboot, manually
copy USBPcapCMD.exe from ...\USBPcap to ...\extcap) , the behaviour is the
same.

As for the call with --exctap-interfaces, this returns normally (and did return
normally with -5 too) if called from the cmd window, same thing for
USBPcapCMD.exe --extcap-interface IFNAME --extcap-config or ...--extcap-dlts,
see below, and although I never get a prompt until I hit enter, the Task
Manager does not show the USBPcapCMD.exe to continue running after any of the
commands below prints the result.

However, Process Monitor shows that the first call by Wireshark, with
--extcap-interfaces finishes properly, the second one with --extcap-interface
\\.\USBPcap3 --extcap-config as well, but the third one with --extcap-interface
\\.\USBPcap2 --extcap-config is the last one in the log, so it is the one which
makes Wireshark hang. And if you look below at the list of devices it provides
when called from the command line, you'll see tons of items which are
individual Bluetooth services (as the embedded Bluetooth controller of the
laptop is USB based). So I'd guess that the buffer for the list of devices in
Wireshark/dumpcap is not big enough?

This would explain why none of the developers has ever run to that issue. Shall
we ask the two guys who have indicated the issue at ask.wireshark.org to
provide their output of these commands?

I'll attach the log from Process Monitor filtered using "Process Name contains
USBPcapCMD" in a while.

P.


c:\Program Files\USBPcap>USBPcapCMD.exe --extcap-interfaces

c:\Program Files\USBPcap>interface {value=\\.\USBPcap1}{display=USBPcap1}
interface {value=\\.\USBPcap2}{display=USBPcap2}
interface {value=\\.\USBPcap3}{display=USBPcap3}

c:\Program Files\USBPcap>USBPcapCMD.exe --extcap-interface \\.\USBPcap1
--extcap-config

c:\Program Files\USBPcap>arg {number=0}{call=--snaplen}{display=Snapshot
length}{tooltip=Snapshot length}{type=integer}{range=0,65535}{default=65535}
arg {number=1}{call=--bufferlen}{display=Capture buffer length}{tooltip=USBPcap
kernel-mode capture buffer length in
bytes}{type=integer}{range=0,134217728}{default=1048576}
arg {number=2}{call=--capture-from-all-devices}{display=Capture from all
devices connected}{tooltip=Capture from all devices connected despite other
options}{type=boolflag}{default=true}
arg {number=3}{call=--capture-from-new-devices}{display=Capture from newly
connected devices}{tooltip=Automatically start capture on all newly connected
devices}{type=boolflag}{default=true}
arg {number=99}{call=--devices}{display=Attached USB Devices}{tooltip=Select
individual devices to capture from}{type=multicheck}
value {arg=99}{value=1}{display=[1] Generic USB Hub}{enabled=true}
value {arg=99}{value=2}{display=[2] Validity Sensor
(VFS491)}{enabled=true}{parent=1}
value {arg=99}{value=3}{display=[3] Slo┼żen├ę za┼Ö├şzen├ş
USB}{enabled=true}{parent=1}
value {arg=99}{value=3_1}{display=HP HD Webcam
[Fixed]}{enabled=false}{parent=3}

c:\Program Files\USBPcap>USBPcapCMD.exe --extcap-interface \\.\USBPcap2
--extcap-config

c:\Program Files\USBPcap>arg {number=0}{call=--snaplen}{display=Snapshot
length}{tooltip=Snapshot length}{type=integer}{range=0,65535}{default=65535}
arg {number=1}{call=--bufferlen}{display=Capture buffer length}{tooltip=USBPcap
kernel-mode capture buffer length in
bytes}{type=integer}{range=0,134217728}{default=1048576}
arg {number=2}{call=--capture-from-all-devices}{display=Capture from all
devices connected}{tooltip=Capture from all devices connected despite other
options}{type=boolflag}{default=true}
arg {number=3}{call=--capture-from-new-devices}{display=Capture from newly
connected devices}{tooltip=Automatically start capture on all newly connected
devices}{type=boolflag}{default=true}
arg {number=99}{call=--devices}{display=Attached USB Devices}{tooltip=Select
individual devices to capture from}{type=multicheck}
value {arg=99}{value=1}{display=[1] Generic USB Hub}{enabled=true}
value {arg=99}{value=2}{display=[2] Broadcom 20702 Bluetooth 4.0
Adapter}{enabled=true}{parent=1}
value {arg=99}{value=2_1}{display=Microsoft Bluetooth LE
Enumerator}{enabled=false}{parent=2}
value {arg=99}{value=2_2}{display=Bluetooth Device (RFCOMM Protocol
TDI)}{enabled=false}{parent=2}
value 

[Wireshark-bugs] [Bug 12837] Qt: Gigantic format list when open capture file

[bugzilla-daemon]

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

--- Comment #5 from Gerrit Code Review  ---
Change 17605 had a related patch set uploaded by Dario Lombardo:
Qt: shorten the list for file selection.

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

-- 
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://wireshark.org/mailman/options/wireshark-bugs
 mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe

[Wireshark-bugs] [Bug 12845] First start with non-empty extcap folder after install or reboot hangs at "initializing tap listeners"

[bugzilla-daemon]

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

--- Comment #10 from Roland Knall  ---
(In reply to Pavel Sindelka from comment #9)
> Repeating the question I've asked Pascal - will it move you further if I use
> the Process Monitor and tell you what the command line parameters of the
> zombie instance were?

It will certainly help, but my guess is, that it hangs with a call to
"--extcap-interfaces". It will have something to do with gathering the list of
interfaces or a specific feature for a specific interface.

-- 
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://wireshark.org/mailman/options/wireshark-bugs
 mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe

[Wireshark-bugs] [Bug 12845] First start with non-empty extcap folder after install or reboot hangs at "initializing tap listeners"

[bugzilla-daemon]

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

--- Comment #9 from Pavel Sindelka  ---
> So, short question, if you have a hanging usbpcap and start wireshark a
> second time, can you actually capture on the shown usb devices? If so, the
> main issue is within USBPcap, although extcap should not hang.

A short answer is "yes, if I keep the zombie USBPcapCMD.exe running, start
Wireshark a second time, and start capturing on one of the USBPcapN
'interfaces', the capturing works".

The long answer is that in my case, there are three root hubs, so three
'interfaces', so the number of invocations at startup time differs.

> Could you run Wireshark through a debugger and break when it hangs, telling
> us the code-position where it is hanging? My guess would be either in
> extcap-spawn.c or in extcap.c in the code for the stderr handling.

I'm afraid the learning curve would be too lengthy as I've never done that.

Repeating the question I've asked Pascal - will it move you further if I use
the Process Monitor and tell you what the command line parameters of the zombie
instance were?

In the meantime until you answer, I'm going to install the previous USBPcap
package (...3), which requires all those reboots, and give you the feedback
whether the change from ...3 to ...5 is involved or not.

-- 
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://wireshark.org/mailman/options/wireshark-bugs
 mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe

[Wireshark-bugs] [Bug 12845] First start with non-empty extcap folder after install or reboot hangs at "initializing tap listeners"

[bugzilla-daemon]

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

--- Comment #8 from Roland Knall  ---
Just a thought. If USPPcap hangs the first time, it seems that it is trying to
gather information on some socket, and therefore cannot finish the extcap
detection process properly. It never closes the socket with closesocket, but
has started to send information to Wireshark. I can imagine, that this might
cause an issue with extcap, but I have to investigate this on Windows again.
Solution here would be at first to change the utility to only send information
on the last step before exiting (at least during initial bootup and discovery). 

The reason it boots up the second time, while the first usppcap is still
running could be, that the second instance tries to do the exact same thing,
but as the first instance has still locked the socket, the second gets a
failure and does continue with its normal operations. This would indicate, that
whatever keeps USPPcap hanging is not that important from the get-go.

So, short question, if you have a hanging usbpcap and start wireshark a second
time, can you actually capture on the shown usb devices? If so, the main issue
is within USBPcap, although extcap should not hang.

Could you run Wireshark through a debugger and break when it hangs, telling us
the code-position where it is hanging? My guess would be either in
extcap-spawn.c or in extcap.c in the code for the stderr handling.

-- 
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://wireshark.org/mailman/options/wireshark-bugs
 mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe

[Wireshark-bugs] [Bug 12845] First start with non-empty extcap folder after install or reboot hangs at "initializing tap listeners"

[bugzilla-daemon]

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

--- Comment #7 from Pascal Quantin  ---
I do not have the .pdb file: the program was built by Gerald.

One way to discriminate whether Wiresahrk or USBPcap is the culprit is to
deinstall the -5 version and reinstall the -3 one: as you run a Windows 10
10586 version it should work. Do not forget to reboot at each step.
The executable can be downloaded here:
https://anonsvn.wireshark.org/wireshark-win64-libs/tags/2016-06-15/packages/USBPcapSetup-1.1.0.0-g794bf26-3.exe

-- 
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://wireshark.org/mailman/options/wireshark-bugs
 mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe

[Wireshark-bugs] [Bug 12851] New: Buildbot crash output: fuzz-2016-09-09-25074.pcap

[bugzilla-daemon]

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

Bug ID: 12851
   Summary: Buildbot crash output: fuzz-2016-09-09-25074.pcap
   Product: Wireshark
   Version: unspecified
  Hardware: x86-64
   URL: https://www.wireshark.org/download/automated/captures/
fuzz-2016-09-09-25074.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-09-09-25074.pcap

stderr:
Input file:
/home/wireshark/menagerie/menagerie/14512-IEPBLink_MultiDeviceTest.pcap

Build host information:
Linux wsbb04 4.4.0-34-generic #53-Ubuntu SMP Wed Jul 27 16:06:39 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=
BUILDBOT_WORKERNAME=fuzz-test
BUILDBOT_BUILDNUMBER=79
BUILDBOT_URL=http://buildbot.wireshark.org/wireshark-2.2/
BUILDBOT_BUILDERNAME=Fuzz Test
BUILDBOT_GOT_REVISION=dadebff34874137671c381d6bfe8f32fbf3ca874

Return value:  152

Dissector bug:  0

Valgrind error count:  0



Git commit
commit dadebff34874137671c381d6bfe8f32fbf3ca874
Author: Alexis La Goutte 
Date:   Wed Sep 7 22:56:39 2016 +0200

NBT: fix  Bad description for NBSS error code 0x81

Issue reported by Pavel Kankovsky
https://tools.ietf.org/html/rfc1002#section-4.3.4

Bug:12835
Change-Id: Iac7e58b9fd61f1f0dfd86960ef4f306ac6ed5a9c
Reviewed-on: https://code.wireshark.org/review/17565
Reviewed-by: Anders Broman 
(cherry picked from commit 03e4307cb2daf1f208d3653b04f64580ee6d0c38)
Reviewed-on: https://code.wireshark.org/review/17571
Petri-Dish: Alexis La Goutte 
Reviewed-by: Michael Mann 



[ 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://wireshark.org/mailman/options/wireshark-bugs
 mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe

[Wireshark-bugs] [Bug 12845] First start with non-empty extcap folder after install or reboot hangs at "initializing tap listeners"

[bugzilla-daemon]

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

--- Comment #6 from Graham Bloice  ---
If there are pdb files available for USBPCapCMD, then a dump of the process can
be examined to determine where it's stuck.

-- 
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://wireshark.org/mailman/options/wireshark-bugs
 mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe

[Wireshark-bugs] [Bug 12846] Live capture from USBPcap fails immediately

[bugzilla-daemon]

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

Alexis La Goutte  changed:

   What|Removed |Added

 CC||alexis.lagou...@gmail.com,
   ||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://wireshark.org/mailman/options/wireshark-bugs
 mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe

[Wireshark-bugs] [Bug 12845] First start with non-empty extcap folder after install or reboot hangs at "initializing tap listeners"

[bugzilla-daemon]

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

Pascal Quantin  changed:

   What|Removed |Added

 CC||rkn...@gmail.com

--- Comment #5 from Pascal Quantin  ---
(In reply to Pavel Sindelka from comment #4)
> Well, with 2.0.5, the last digit of USBPcap package ID was 3, now with 2.2.0
> it is 5, I have no idea what the actual difference is but definitely it is
> not "the same USBPcap version". BTW, who maintains USBPcap as Tomasz seems
> to be busy dealing with other things? I mean, there is the CPU resources
> issue I've filed at github which makes live capture with USBPcap a bit
> adrenaline even without the currently discovered issues, and it still exists
> even in the 5 version.

Wireshark 2.0.6 provides the -5 version also. It is the same code as the
previous version, with simply the Microsoft cross check signature added to the
EV certificate of the driver so as to properly start on Windows 10 anniversary
update.
As you noticed the USBPcap development is stalled. The increment of the last
digit simply denote changes in the packaging of the program. 

> 
> > I never faced such issue on my side :(
> 
> How can I help further? Will it help you if I install the Process Manager
> and check what is the command line of the zombie USBPcapCMD.exe which stays
> running after Wireshark freezes?

That would be a minimum to provide the full Process Monitor log. And it would
be better if a developer could reproduce the issue also. 
I'm adding Roland in the loop as he is our extcap expert and did some major
changes in 2.2.

-- 
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://wireshark.org/mailman/options/wireshark-bugs
 mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe

[Wireshark-bugs] [Bug 12845] First start with non-empty extcap folder after install or reboot hangs at "initializing tap listeners"

[bugzilla-daemon]

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

--- Comment #4 from Pavel Sindelka  ---
(In reply to Pascal Quantin from comment #2)
> Is it solely happening with USBPcapCMD.exe, or does your extcaptest.exe
> alone program also trigger the issue?

It is happening solely with USBPcapCMD.exe, but you have to know that my
extcaptest.exe does not actually capture, it just logs the command line
parameters it receives into a file (because I didn't know the Process
Explorer), and responds to --extcap-interfaces, --extcap-config, and
--extcap-dlts, which was the necessary minimum to satisfy dumpcap's initial
queries.

The calls to extcaptest.exe at Wireshark startup look as follows:

--extcap-interfaces 
--extcap-config --extcap-interface \\.\EoE2isdn1 
--extcap-config --extcap-interface \\.\EoE2isdn2 
--extcap-interfaces 
--extcap-dlts --extcap-interface \\.\EoE2isdn1 
--extcap-dlts --extcap-interface \\.\EoE2isdn2 
--extcap-config --extcap-interface \\.\EoE2isdn1 
--extcap-config --extcap-interface \\.\EoE2isdn2 

The responses configured are:

  if ($value eq "^--extcap-interfaces")  {
print "interface {value=.\\EoE2isdn1}{display=EoE2isdn D-channel 1}\n";
print "interface {value=.\\EoE2isdn2}{display=EoE2isdn D-channel 2}\n";
  }

  if ($value =~ /^--extcap-config/ ) {
print "arg {number=0}{call=--snaplen}{display=Snapshot
length}{tooltip=Snapshot
length}{type=integer}{range=0,65535}{default=65535}\n";
print "arg {number=99}{call=--filename}{display=Destination for audio
files}{tooltip=Select target directory}{type=fileselect}\n";
  }

  if ($value =~ /^--extcap-dlts/ ) {
print "dlt {number=249}{name=USBPCAP}{display=USBPcap}\n";
  }

> As we package the same USBPcap
> version between 2.0.X and 2.2, I presume this should not be the culprit.

Well, with 2.0.5, the last digit of USBPcap package ID was 3, now with 2.2.0 it
is 5, I have no idea what the actual difference is but definitely it is not
"the same USBPcap version". BTW, who maintains USBPcap as Tomasz seems to be
busy dealing with other things? I mean, there is the CPU resources issue I've
filed at github which makes live capture with USBPcap a bit adrenaline even
without the currently discovered issues, and it still exists even in the 5
version.

> I never faced such issue on my side :(

How can I help further? Will it help you if I install the Process Manager and
check what is the command line of the zombie USBPcapCMD.exe which stays running
after Wireshark freezes?

-- 
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://wireshark.org/mailman/options/wireshark-bugs
 mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe

[Wireshark-bugs] [Bug 12846] Live capture from USBPcap fails immediately

[bugzilla-daemon]

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

--- Comment #5 from Pascal Quantin  ---
(In reply to Pavel Sindelka from comment #4)
> > Simply click on the wheel icon, which is on the left of the USBPcap
> > interface name
> Grrr... I was clicking the text all the time :-)
> 
> > Not exactly: it's not a check box, but a tree when you can select one or
> > several elements by clicking on them (you will see it when clicking on the
> > icon). I'm almost sure that previously Wireshark was not sending the
> > --devices parameter if nothing was selected
> 
> Maybe previously USBPcapCMD was simply not returning the --devices option in
> the answer to --extcap-config? I understand the purpose of this option,
> together with --capture-from-all-devices and --capture-from-new-devices, as
> a substitution of a capture filter

Multicheck was created for USBPcap so you can be sure its behavior did not
change. 

> 
> As for the tree display and handling: the description on the man page says
> 
> > multicheck (display a textbox for selecting multiple options, values as 
> > strings)
> 
> The list of tree items in my case is, on one root hub:
> arg {number=99}{call=--devices}{display=Attached USB Devices}{tooltip=Select
> individual devices to capture from}{type=multicheck}
> value {arg=99}{value=1}{display=[1] Generic USB Hub}{enabled=true}
> value {arg=99}{value=2}{display=[2] Validity Sensor
> (VFS491)}{enabled=true}{parent=1}
> value {arg=99}{value=3}{display=[3] Složené zařízení
> USB}{enabled=true}{parent=1}
> value {arg=99}{value=3_1}{display=HP HD Webcam
> [Fixed]}{enabled=false}{parent=3}
> 
> On another root hub, it is:
> arg {number=99}{call=--devices}{display=Attached USB Devices}{tooltip=Select
> individual devices to capture from}{type=multicheck}
> value {arg=99}{value=1}{display=[1] Velkokapacitní paměťové zařízení
> USB}{enabled=true}
> value {arg=99}{value=1_1}{display=General USB Flash Disk USB
> Device}{enabled=false}{parent=1}
> 
> What is weird is that I cannot select the leaves in the trees (i.e. the "HP
> HD Webcam [Fixed]" and the "General USB Flash Disk USB Device".

You can select the the sub element of a root USB (or at least it used to work). 

> 
> 
> How do you visualize the command line parameters with which dumpcap invokes
> the USBPcapCMD.exe?

I use a program name Process Explorer that (amongst things) can show you all
system calls.

-- 
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://wireshark.org/mailman/options/wireshark-bugs
 mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe

[Wireshark-bugs] [Bug 12845] First start with non-empty extcap folder after install or reboot hangs at "initializing tap listeners"

[bugzilla-daemon]

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

Graham Bloice  changed:

   What|Removed |Added

 CC||graham.blo...@trihedral.com

--- Comment #3 from Graham Bloice  ---
(Bonus question: how would I copy the build information as required above if
Wireshark would eventually not start at all?)

You could try from the command line: path\to\wireshark.exe -v

I also see you're running an older version of npcap: "with Npcap version 0.07",
although I don't think that's causing 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://wireshark.org/mailman/options/wireshark-bugs
 mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe

[Wireshark-bugs] [Bug 12846] Live capture from USBPcap fails immediately

[bugzilla-daemon]

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

--- Comment #4 from Pavel Sindelka  ---
> Simply click on the wheel icon, which is on the left of the USBPcap
> interface name
Grrr... I was clicking the text all the time :-)

> Not exactly: it's not a check box, but a tree when you can select one or
> several elements by clicking on them (you will see it when clicking on the
> icon). I'm almost sure that previously Wireshark was not sending the
> --devices parameter if nothing was selected

Maybe previously USBPcapCMD was simply not returning the --devices option in
the answer to --extcap-config? I understand the purpose of this option,
together with --capture-from-all-devices and --capture-from-new-devices, as a
substitution of a capture filter.

As for the tree display and handling: the description on the man page says

> multicheck (display a textbox for selecting multiple options, values as 
> strings)

The list of tree items in my case is, on one root hub:
arg {number=99}{call=--devices}{display=Attached USB Devices}{tooltip=Select
individual devices to capture from}{type=multicheck}
value {arg=99}{value=1}{display=[1] Generic USB Hub}{enabled=true}
value {arg=99}{value=2}{display=[2] Validity Sensor
(VFS491)}{enabled=true}{parent=1}
value {arg=99}{value=3}{display=[3] Složené zařízení
USB}{enabled=true}{parent=1}
value {arg=99}{value=3_1}{display=HP HD Webcam
[Fixed]}{enabled=false}{parent=3}

On another root hub, it is:
arg {number=99}{call=--devices}{display=Attached USB Devices}{tooltip=Select
individual devices to capture from}{type=multicheck}
value {arg=99}{value=1}{display=[1] Velkokapacitní paměťové zařízení
USB}{enabled=true}
value {arg=99}{value=1_1}{display=General USB Flash Disk USB
Device}{enabled=false}{parent=1}

What is weird is that I cannot select the leaves in the trees (i.e. the "HP HD
Webcam [Fixed]" and the "General USB Flash Disk USB Device".


How do you visualize the command line parameters with which dumpcap invokes the
USBPcapCMD.exe?

-- 
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://wireshark.org/mailman/options/wireshark-bugs
 mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe

[Wireshark-bugs] [Bug 12845] First start with non-empty extcap folder after install or reboot hangs at "initializing tap listeners"

[bugzilla-daemon]

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

Pascal Quantin  changed:

   What|Removed |Added

 CC||pascal.quan...@gmail.com

--- Comment #2 from Pascal Quantin  ---
Is it solely happening with USBPcapCMD.exe, or does your extcaptest.exe alone
program also triggers the issue? AS we package the same USBPcap version between
2.0;X and 2.2, I presume this should not be the culprit.
I never faced such issue on my side :(

-- 
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://wireshark.org/mailman/options/wireshark-bugs
 mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe

[Wireshark-bugs] [Bug 12850] New: Buildbot crash output: randpkt-2016-09-09-7566.pcap

[bugzilla-daemon]

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

Bug ID: 12850
   Summary: Buildbot crash output: randpkt-2016-09-09-7566.pcap
   Product: Wireshark
   Version: unspecified
  Hardware: x86-64
   URL: https://www.wireshark.org/download/automated/captures/
randpkt-2016-09-09-7566.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/randpkt-2016-09-09-7566.pcap

stderr:
Input file: 

Build host information:
Linux wsbb04 4.4.0-34-generic #53-Ubuntu SMP Wed Jul 27 16:06:39 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=3665
BUILDBOT_URL=http://buildbot.wireshark.org/wireshark-master/
BUILDBOT_BUILDERNAME=Clang Code Analysis
BUILDBOT_GOT_REVISION=1948f7bd7553f215dc2519a35dcd62e29e35a614

Return value:  134

Dissector bug:  0

Valgrind error count: 




Command and args: ./tshark -nVxr

==7597==ERROR: AddressSanitizer failed to allocate 0x1000 (268435456) bytes
at address 7fff7000 (errno: 12)
==7597==ReserveShadowMemoryRange failed while trying to map 0x1000 bytes.
Perhaps you're using ulimit -v

[ 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://wireshark.org/mailman/options/wireshark-bugs
 mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe