[Wireshark-bugs] [Bug 15625] TLS decryption fails with Extension: Extended Master Secret present

[bugzilla-daemon]

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

--- Comment #15 from Gerrit Code Review  ---
Change 32919 had a related patch set uploaded by Peter Wu:
packet: ensure pinfo->curr_layer_num does not depend on tree

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

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

[Wireshark-bugs] [Bug 15625] TLS decryption fails with Extension: Extended Master Secret present

[bugzilla-daemon]

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

--- Comment #14 from Peter Wu  ---
More details on why the issue occurs:

Frame 25 contains two TLS layers due to TCP reassembly:

- The start of the TCP segment completes reassembly of a previous TLS record.
- The remaining part is also a full TLS record.

Hence the two TLS layers,
one for the first TLS record (containing a Server Hello, Certificate and a
partial Certificate Request message),
another for the second TLS record (completing the Certificate Request message
and more).

This means that the dissect_ssl function was called twice by TCP. It expects
"pinfo->curr_layer_num" to remain stable between the first and second pass. On
the first pass, the reassembly/decryption state is stored using this value. On
the second pass, these are looked up, again using "pinfo->curr_layer_num".

When processing the first TLS layer, everything is still working. Once it
dissects the Certificate message, things go downhill. Due to the issue
mentioned in comment 13, "pinfo->curr_layer_num" would not be decremented on
the first pass unlike the second pass.

After that, processing the second TLS layer fails on the second pass due to the
"pinfo->curr_layer_num" difference.

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

[Wireshark-bugs] [Bug 15496] Incorrect position for [Not decoded yet] field for H264 payload type

[bugzilla-daemon]

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

Peter Wu  changed:

   What|Removed |Added

 Status|UNCONFIRMED |CONFIRMED
 Ever confirmed|0   |1
 CC||pe...@lekensteyn.nl

--- Comment #7 from Peter Wu  ---
Can reproduce the output with v3.1.0rc0-565-g2ec76df4ca with this command:

 tshark -r frame_206.pcap -dudp.port==19836,rtp -oh264.dynamic.payload.type:97
-Tpdml

The trace leading up to this:

(gdb) bt
#0  proto_tree_add_expert (tree=0x60400026d7d0, pinfo=0x61400458,
expindex=0x7130f000 , tvb=0x606000152f00, start=0,
length=-1) at epan/expert.c:654
#1  0x7fffec88ca22 in dissect_h264_slice_data_partition_c_layer_rbsp
(tree=0x60400026d7d0, tvb=0x606000152f00, pinfo=0x61400458, offset=0) at
epan/dissectors/packet-h264.c:1320
#2  0x7fffec88ffb6 in dissect_h264 (tvb=0x607ec570,
pinfo=0x61400458, tree=0x60400026c350, data=0x0) at
epan/dissectors/packet-h264.c:2476
...
(gdb) p *tree.finfo 
$5 = {hfinfo = 0x75fc5280 , start = 54, length = 1, ...

This "tree" item is the "h246_nal_tree" which is displayed as "NAL unit header
or first byte of the payload" in the output. Start position 54 (0x36) seems
accurate.

We have this code in epan/dissectors/packet-h264.c (with comments stripped):

 static void
 dissect_h264_slice_data_partition_c_layer_rbsp(proto_tree *tree, tvbuff_t
*tvb, packet_info *pinfo _U_, gint offset)
 {
gint bit_offset = offset << 3;
dissect_h264_exp_golomb_code(tree, hf_h264_slice_id, tvb, &bit_offset,
H264_UE_V);
proto_tree_add_expert(tree, pinfo, &ei_h264_undecoded, tvb, bit_offset>>3,
-1);
 }

"proto_tree_add_expert" uses the region selected by "tree" which is the
h264_nal_tree item I mentioned above. It appears that
"dissect_h264_exp_golomb_code" performs some additional dissection, but its
tree items are not available to the subsequeny proto_tree_add_expert call.

I am not familiar with this protocol, but hopefully this explains why the
behavior is as observed and helps with writing patches. Patches are welcome.

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

[Wireshark-bugs] [Bug 15625] TLS decryption fails with Extension: Extended Master Secret present

[bugzilla-daemon]

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

--- Comment #13 from Peter Wu  ---
Found the culprit for the difference in pinfo->curr_layer_num. Commit
v2.5.0rc0-1206-gcd90f732a1 tried to cleanup the frame.protocols field by
removing items when the dissector did not add any item.

The problem occurs in this trace:

 call_dissector_work () at epan/packet.c:800
 dissector_try_string_new () at epan/packet.c:1682
 dissector_try_string () at epan/packet.c:1707
 call_ber_oid_callback () at epan/dissectors/packet-ber.c:1105
 dissect_x509af_T_parameters () at ./asn1/x509af/x509af.cnf:90
 dissect_ber_sequence () at epan/dissectors/packet-ber.c:2425
 dissect_x509af_AlgorithmIdentifier () at ./asn1/x509af/x509af.cnf:106
 dissect_ber_sequence () at epan/dissectors/packet-ber.c:2425
 dissect_x509af_T_signedCertificate () at ./asn1/x509af/x509af.cnf:199
 dissect_ber_sequence () at epan/dissectors/packet-ber.c:2425
 dissect_x509af_Certificate () at ./asn1/x509af/x509af.cnf:226
 ssl_dissect_hnd_cert () at epan/dissectors/packet-tls-utils.c:8057

The handle that was called there is dissect_ber_oid_NULL_callback. That
function does not add anything to the tree. So normally, this condition will be
triggered:

 if ( /* ... */ &&
(tree && saved_tree_count == tree->tree_data->count))) {
 /* ... */
 pinfo->curr_layer_num--;
 /* ...*/
 }

In a two-pass dissection however, this is initially called with tree = NULL, so
no layer is removed (hence the higher layer number in the previous comment). On
the next pass, tree is non-NULL so the layer number is smaller. However that
does mean that anything that relies on a stable layer number breaks.

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

[Wireshark-bugs] [Bug 15713] Static build fails to find glib2 dependencies

[bugzilla-daemon]

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

--- Comment #9 from Peter Wu  ---
(In reply to Guy Harris from comment #8)
> > Wireshark does not use DBus directly, but it is used indirectly through Qt.
> > Not all Linux distributions enable DBus support though.
> 
> "Enable DBus" in Qt, or "enable DBus" in libpcap?

They do not enable DBus in libpcap (possibly due to the lack of dbus headers
when building libpcap). Qt can be built without DBus (-no-dbus), but that seems
more for embedded folks than Linux distributions. Many Linux distributions use
systemd which depends on DBus.

> The trick here isn't finding the *libpcap* libraries and headers, the trick
> is finding the libraries that libpcap uses.
> 
> That's relatively easy for dynamically-linked libraries on UN*X; [..]
> It's not so easy for statically-linked libraries;

Right, finding the transitive libraries for static linking is more difficult.

> I don't know whether Windows dynamically-linked libraries have the same
> transitive dependencies.

Not sure, but I think they do not. An image that uses symbols from a library
has to explicitly specify the symbols to import and the DLL to load it from.

> > If detection fails for whatever reason, the user can manually set
> > PCAP_LIBRARIES and PCAP_INCLUDE_DIRS, and report a bug for us to look at.
> 
> ...and we may end up fixing it by using pcap-compile (which is what the
> libpcap maintainers provide to find out what libraries you need in addition
> to libpcap when doing a static build).

(I assume that you meant pcap-config, pcap_compile(3pcap) seems something
else.)
For Fabrice purposes (buildroot), pkgconf (new version of pkg-config) seems
available, so maybe we can try to rely on that is a standard interface. I would
not really be opposed though if you go through the trouble of adding a call to
pcap-config on UN*X (do not try it on Windows).

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

[Wireshark-bugs] [Bug 15713] Static build fails to find glib2 dependencies

[bugzilla-daemon]

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

--- Comment #8 from Guy Harris  ---
> It looks like all of dumpcap, tshark and wireshark link to caputils which
> links to various netlink libraries. Hopefully that should be sufficient then
> for libpcap.

And if it isn't, we may have to use pcap-config.

> Wireshark does not use DBus directly, but it is used indirectly through Qt.
> Not all Linux distributions enable DBus support though.

"Enable DBus" in Qt, or "enable DBus" in libpcap?

In either case, for dynamic linking, that shouldn't be an issue, at least not
on UN*X (see below), but for *static* linking, you'd have to find out what
libraries the static libraries with which you're linking require, and link with
them.  Fortunately, it should be OK to statically link with DBus libraries
twice, if static Qt and static libpcap both require them.

> > If pkg_search_module() doesn't try using pcap-config if it doesn't find a
> > .pc file, it's insufficient for handling libpcap; libpcap only recently
> > added .pc files. (Remember, not every UN*X has pkg-config!  That may
> > happen eventually, given, among other things, the BSD-licensed
> > pkg-config developed by the OpenBSD people, but it's not the case *now*.)
> 
> So far we have survived without calling pcap-config, the libpcap maintainers
> do not make it especially hard to find libraries and headers :)

The trick here isn't finding the *libpcap* libraries and headers, the trick is
finding the libraries that libpcap uses.

That's relatively easy for dynamically-linked libraries on UN*X; for most UN*X
dynamically-linked library mechanisms, if, when you build a dynamically-linked
library, you link it with another dynamically-linked library, then, if, when yo
build an executable, you link it with the dynamically-linked library you built,
it will, when run, automatically pick up whatever additional dynamically-linked
libraries the dynamically-linked library in question requires, even if that set
is different from the set required by the version you built it with.  (That's
one reason *why* they do that - libXXX can be changed to use libYYY without a
requirement for new libraries to be loaded disrupting programs built with
libXXX.)

It's not so easy for statically-linked libraries; I don't know whether Windows
dynamically-linked libraries have the same transitive dependencies.

> If detection fails for whatever reason, the user can manually set
> PCAP_LIBRARIES and PCAP_INCLUDE_DIRS, and report a bug for us to look at.

...and we may end up fixing it by using pcap-compile (which is what the libpcap
maintainers provide to find out what libraries you need in addition to libpcap
when doing a static build).

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

[Wireshark-bugs] [Bug 15713] Static build fails to find glib2 dependencies

[bugzilla-daemon]

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

--- Comment #7 from João Valverde  ---
(In reply to fontaine.fabrice from comment #2)
> Your proposal fixes the issue with glib2, thanks.
> As soon as it's committed upstream, I'll use it in buildroot instead of my
> proposal.
> 
> However, I have two more patches to completely fixes static build.
> These patches fix:
>  - rpath:
> https://git.buildroot.net/buildroot/tree/package/wireshark/0002-CMakeLists.
> txt-disable-rpath-in-static-build.patch
>  - pcap dependencies:
> https://git.buildroot.net/buildroot/tree/package/wireshark/0003-FindPCAP.
> cmake-fix-static-build.patch
> 
> How should we proceed, should we discuss it here, should I open a new bug,
> or send new PRs?

I think it should be discussed here. The topic can be amended later. The RPATH
patch is fine with me.

As noted the scope of ENABLE_STATIC is more limited than an all-static build,
which is what I think you assumed, but changing it to link with static
libraries only is fine with me. There used to be a CMake TODO for this too.

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

[Wireshark-bugs] [Bug 15713] Static build fails to find glib2 dependencies

[bugzilla-daemon]

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

--- Comment #6 from Peter Wu  ---
(In reply to Guy Harris from comment #4)
> Is that "build only static libraries" or "build shared *and* static
> libraries"?

It is "build static libraries only, without dynamic libraries". If both have to
be built at the same time by CMake, typically an object library is created
first which is then linked into a dynamic and static library. (Dynamic libs
require position-independent code as well.)

> >  "build static libraries, link with static libraries only"
> 
> I.e., "build statically-linked executables".

Correct.

> > For me, libpcap 1.9.0 on Arch Linux is built with:
> > $ pkgconf --static --libs libpcap
> > -lpcap -lnl-genl-3 -lnl-3 -ldbus-1 
> > 
> > libnl and related is an optional feature, needed for wireless extensions.
> 
> libpcap may, or may not, require libnl and related, for its own wireless
> operations.
> 
> Wireshark *also* may use them for *its* wireless operations.

It looks like all of dumpcap, tshark and wireshark link to caputils which links
to various netlink libraries. Hopefully that should be sufficient then for
libpcap.

> > dbus is an optional feature, needed for dbus-monitor captures.
> 
> Does *Wireshark* directly make calls to libdbus for anything, or is it only
> used by non-Wireshark libraries that Wireshark uses, possibly including, but
> not necessarily limited to, libpcap?  (Perhaps Qt on UN*X+{X11,Wayland,...}
> platforms also uses it for freedesktop.org stuff.)

Wireshark does not use DBus directly, but it is used indirectly through Qt. Not
all Linux distributions enable DBus support though. On Arch Linux it is
(possibly because it is automatically detected by configure, not because it is
explicitly requested:
https://git.archlinux.org/svntogit/packages.git/tree/trunk/PKGBUILD?h=packages/libpcap),
but on Ubuntu it is not used.

> If pkg_search_module() doesn't try using pcap-config if it doesn't find a
> .pc file, it's insufficient for handling libpcap; libpcap only recently
> added .pc files. (Remember, not every UN*X has pkg-config!  That may
> happen eventually, given, among other things, the BSD-licensed
> pkg-config developed by the OpenBSD people, but it's not the case *now*.)

So far we have survived without calling pcap-config, the libpcap maintainers do
not make it especially hard to find libraries and headers :)
If detection fails for whatever reason, the user can manually set
PCAP_LIBRARIES and PCAP_INCLUDE_DIRS, and report a bug for us to look at.

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

[Wireshark-bugs] [Bug 15713] Static build fails to find glib2 dependencies

[bugzilla-daemon]

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

--- Comment #5 from João Valverde  ---
(In reply to Peter Wu from comment #3)
> (In reply to João Valverde from comment #1)
> > pkg-config is being correctly used to provide hints to the search procedure.
> > The ENABLE_STATIC CMake option currently just disables building shared
> > libraries.
> > 
> > I wouldn't object to this patch, if it helps. Seems to be what you want?
> > (untested).
> > 
> > diff --git a/CMakeLists.txt b/CMakeLists.txt
> > index d182d43017..2402d3d92f 100644
> > --- a/CMakeLists.txt
> > +++ b/CMakeLists.txt
> > @@ -730,6 +730,9 @@ include(CheckCXXCompilerFlag)
> >  
> >  if(ENABLE_STATIC)
> > set(BUILD_SHARED_LIBS 0)
> > +   if (UNIX)
> > +   set(CMAKE_FIND_LIBRARY_SUFFIXES ".a")
> > +   endif()
> >  else()
> > set(BUILD_SHARED_LIBS 1)
> >  endif()
> 
> This is not the appropriate location for a fix, it changes "ENABLE_STATIC"
> from
> 
>  "build static libraries, link to any shared/static library"
> 
> to
> 
>  "build static libraries, link with static libraries only"

That's obvious. As I said, I don't object to changing ENABLE_STATIC.

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

[Wireshark-bugs] [Bug 15713] Static build fails to find glib2 dependencies

[bugzilla-daemon]

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

--- Comment #4 from Guy Harris  ---
(In reply to Peter Wu from comment #3)
> 
> This is not the appropriate location for a fix, it changes "ENABLE_STATIC"
> from
> 
>  "build static libraries, link to any shared/static library"

Is that "build only static libraries" or "build shared *and* static libraries"?

> to
> 
>  "build static libraries, link with static libraries only"

I.e., "build statically-linked executables".

> For me, libpcap 1.9.0 on Arch Linux is built with:
> $ pkgconf --static --libs libpcap
> -lpcap -lnl-genl-3 -lnl-3 -ldbus-1 
> 
> libnl and related is an optional feature, needed for wireless extensions.

libpcap may, or may not, require libnl and related, for its own wireless
operations.

Wireshark *also* may use them for *its* wireless operations.

> dbus is an optional feature, needed for dbus-monitor captures.

Does *Wireshark* directly make calls to libdbus for anything, or is it only
used by non-Wireshark libraries that Wireshark uses, possibly including, but
not necessarily limited to, libpcap?  (Perhaps Qt on UN*X+{X11,Wayland,...}
platforms also uses it for freedesktop.org stuff.)

> Given that these are optional, I would prefer not to add them to
> FindPCAP.cmake

It is not our business to independently determine what libraries libpcap (or
any other libraries) requires, except for libraries that don't provide a way to
query them for that information.  libpcap currently offers pcap-config, which
does let you query it for that information:

$ pcap-config --libs
-L/usr/local/lib  -lpcap
$ pcap-config --static --libs
-L/usr/local/lib -lpcap 

(admittedly boring, given that this is macOS; if done on Linux, for example,
there may be other dependencies).

Prior to libpcap 1.1, pcap-config didn't support --static, so you couldn't ask
it which libraries are required if you link with a *static* libpcap (if you
link with a dynamic libpcap, it's already been linked with its dependencies, so
it should cause those dependencies to be linked with at startup time).

>  # Include transitive dependencies for static linking.
>  if(UNIX AND CMAKE_FIND_LIBRARY_SUFFIXES STREQUAL ".a")
>find_package(PkgConfig)
>pkg_search_module(PC_LIBPCAP libpcap)
>list(APPEND PCAP_LIBRARIES ${PC_LIBCAP_LIBRARIES})
>  endif()

If pkg_search_module() doesn't try using pcap-config if it doesn't find a .pc
file, it's insufficient for handling libpcap; libpcap only recently added .pc
files.  (Remember, not every UN*X has pkg-config!  That may happen eventually,
given, among other things, the BSD-licensed pkg-config developed by the OpenBSD
people, but it's not the case *now*.)

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

[Wireshark-bugs] [Bug 15713] Static build fails to find glib2 dependencies

[bugzilla-daemon]

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

Peter Wu  changed:

   What|Removed |Added

 Status|UNCONFIRMED |CONFIRMED
 CC||pe...@lekensteyn.nl
 Ever confirmed|0   |1

--- Comment #3 from Peter Wu  ---
(In reply to João Valverde from comment #1)
> pkg-config is being correctly used to provide hints to the search procedure.
> The ENABLE_STATIC CMake option currently just disables building shared
> libraries.
> 
> I wouldn't object to this patch, if it helps. Seems to be what you want?
> (untested).
> 
> diff --git a/CMakeLists.txt b/CMakeLists.txt
> index d182d43017..2402d3d92f 100644
> --- a/CMakeLists.txt
> +++ b/CMakeLists.txt
> @@ -730,6 +730,9 @@ include(CheckCXXCompilerFlag)
>  
>  if(ENABLE_STATIC)
> set(BUILD_SHARED_LIBS 0)
> +   if (UNIX)
> +   set(CMAKE_FIND_LIBRARY_SUFFIXES ".a")
> +   endif()
>  else()
> set(BUILD_SHARED_LIBS 1)
>  endif()

This is not the appropriate location for a fix, it changes "ENABLE_STATIC" from

 "build static libraries, link to any shared/static library"

to

 "build static libraries, link with static libraries only"


Perhaps we should add a new "USE_STATIC_LIBS" option that assumes all system
libraries to be static. This is already needed by oss-fuzz for which we have a
special case on line 328:

if(OSS_FUZZ)
if(ENABLE_FUZZER)
# In oss-fuzz mode, the fuzzing engine can be afl or libFuzzer.
message(FATAL_ERROR "Cannot force libFuzzer when using
oss-fuzz")
endif()
# Must not depend on external dependencies so statically link all libs.
set(CMAKE_FIND_LIBRARY_SUFFIXES ".a")
endif()


As for the RPATH change, that could go together with the USE_STATIC_LIBS
option.

For me, libpcap 1.9.0 on Arch Linux is built with:
$ pkgconf --static --libs libpcap
-lpcap -lnl-genl-3 -lnl-3 -ldbus-1 

libnl and related is an optional feature, needed for wireless extensions.
dbus is an optional feature, needed for dbus-monitor captures.

Given that these are optional, I would prefer not to add them to FindPCAP.cmake
as is done with pcre in FindGLIB2.cmake. However as building static libraries
is a rare thing, I think using pkg-config information to augment the library
list would be reasonable. Maybe something like (look at other files for
inspiration):

 # Include transitive dependencies for static linking.
 if(UNIX AND CMAKE_FIND_LIBRARY_SUFFIXES STREQUAL ".a")
   find_package(PkgConfig)
   pkg_search_module(PC_LIBPCAP libpcap)
   list(APPEND PCAP_LIBRARIES ${PC_LIBCAP_LIBRARIES})
 endif()

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

[Wireshark-bugs] [Bug 15714] Support for the PROXY (v1) protocol (HAPROXY) over TCP

[bugzilla-daemon]

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

--- Comment #4 from Gerrit Code Review  ---
Change 32916 had a related patch set uploaded by Peter Wu:
PROXY: add HAPROXY PROXY (v1) support

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

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

[Wireshark-bugs] [Bug 15714] Support for the PROXY (v1) protocol (HAPROXY) over TCP

[bugzilla-daemon]

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

--- Comment #3 from Peter Wu  ---
Created attachment 17079
  --> https://bugs.wireshark.org/bugzilla/attachment.cgi?id=17079&action=edit
PROXY (v1) capture with fragmented HTTP

The DNS dissector does not support reassembly, so here is another capture using
the same nginx server configuration and HTTP.

I have a patch that implements PROXY support now, unfortunately it is currently
broken in a two-pass dissection. Whenever the PROXY header is coalesced with
any part of the HTTP request, then the HTTP dissector will try to own up all of
the data due to calling conversation_set_dissector_from_frame_number. That does
not take into account the fact that only a later part of the TCP payload is
HTTP.

Reproduction steps:

proxy='PROXY TCP4 127.0.0.1 192.0.2.10 56432 80\r\n'
l1='GET / HTTP/1.1\r\n'
l2='Host: localhost\r\n'
l3='Connection: close\r\n\r\n'
# all-in-one
printf "$proxy$l1$l2$l3" | nc 127.0.0.2 8080
# proxy, part1, others
(printf "$proxy"; sleep 1; printf "$l1"; sleep 1; printf "$l2$l3") | nc
127.0.0.2 8080
# proxy + part1, others
(printf "$proxy$l1"; sleep 1; printf "$l2$l3") | nc 127.0.0.2 8080
# proxy + part1, part2, part3
(printf "$proxy$l1"; sleep 1; printf "$l2"; sleep 1; printf "$l3") | nc
127.0.0.2 8080

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

[Wireshark-bugs] [Bug 15709] ISAKMP: Segmentation fault with non-hex string for IKEv1 Decryption Table Initiator Cookie

[bugzilla-daemon]

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

--- Comment #2 from Uli Heilmeier  ---
Not reproducible on Linux with master => here we get the error string "Length
of Initiator's COOKIE must be %d octets (%d hex characters)" of function
ikev1_uat_data_update_cb.
=> On MacOS it seems that ikev1_uat_data_update_cb is not called when clicking
OK.

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

[Wireshark-bugs] [Bug 15709] ISAKMP: Segmentation fault with non-hex string for IKEv1 Decryption Table Initiator Cookie

[bugzilla-daemon]

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

--- Comment #1 from Uli Heilmeier  ---
To reproduce with MacOS on master-3.0 and master:
Open ISAKMP protocol preferences -> IKEv2 Decryption Table ->
Initiator Cookie: paste "e6bf72f165d03ce1n" -> Tab to Encryption key -> type in
"adfadf" -> click "OK"

Issue in isakmp_init_protocol(void) with "memcpy(ic_key,
ikev1_uat_data[i].icookie, COOKIE_SIZE);"

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

[Wireshark-bugs] [Bug 15693] ISAKMP: not able to decode multiple RFC 6407 payloads(i.e. SA kEK, SAT, key download etc.)

[bugzilla-daemon]

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

--- Comment #6 from Gerrit Code Review  ---
Change 32915 had a related patch set uploaded by Uli Heilmeier:
ISAKMP: Adding some payload types (RFC6407)

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

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

[Wireshark-bugs] [Bug 15718] New: RTMPT does not handle extended timestamp with Chunk Type 3

[bugzilla-daemon]

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

Bug ID: 15718
   Summary: RTMPT does not handle extended timestamp with Chunk
Type 3
   Product: Wireshark
   Version: 3.0.1
  Hardware: x86
OS: Mac OS X 10.4
Status: UNCONFIRMED
  Severity: Minor
  Priority: Low
 Component: Dissection engine (libwireshark)
  Assignee: bugzilla-ad...@wireshark.org
  Reporter: bill@disneystreaming.com
  Target Milestone: ---

Created attachment 17078
  --> https://bugs.wireshark.org/bugzilla/attachment.cgi?id=17078&action=edit
packet capture referenced above.

Build Information:
Version 3.0.1 (v3.0.1-0-gea351cd8) 
Copyright 1998-2019 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.12.1, with libpcap, without POSIX capabilities,
with GLib 2.37.6, with zlib 1.2.8, with SMI 0.4.8, with c-ares 1.15.0, with Lua
5.2.4, with GnuTLS 3.4.17, with Gcrypt 1.7.7, with MIT Kerberos, with MaxMind
DB resolver, with nghttp2 1.21.0, with LZ4, with Snappy, with libxml2 2.9.9,
with QtMultimedia, with SBC, with SpanDSP, with bcg729. 
Running on Mac OS X 10.13.6, build 17G2307 (Darwin 17.7.0), with Intel(R)
Core(TM) i5-8259U CPU @ 2.30GHz (with SSE4.2), with 16384 MB of physical
memory, with locale C, with libpcap version 1.8.1 -- Apple version 79.20.1,
with GnuTLS 3.4.17, with Gcrypt 1.7.7, with zlib 1.2.11, binary plugins
supported (14 loaded). Built using clang 4.2.1 Compatible Apple LLVM 10.0.0
(clang-1000.11.45.5). 
Wireshark is Open Source Software released under the GNU General Public
License. 
Check the man page and http://www.wireshark.org for more information. 
--
In looking at an RTMPT trace, there are several packets that do not dissect
correctly.  In looking at the specification (Adobe’s Real Time Messaging
Protocol
, 12/21/2012, Section 5.3.1.3 Extended Timestamp), it says:
   This field is present in Type 3 chunks when the most recent Type 0,
   1, or 2 chunk for the same chunk stream ID indicated the presence of
   an extended timestamp field.

The code doesn't seem to handle this correctly.  In dissect_rtmpt_common, the
code for dealing with the extended header looks like:

if ((header_type < 3) && (remain >=
(basic_hlen+3))) {
if (tvb_get_ntoh24(tvb,
offset+basic_hlen) == 0xff) {
message_hlen += 4;
}
}

(ie: doesn't seem to register that there is an extended timestamp in the
previous Type 0 chunk).

You can see this in packet 115 of the enclosed capture.  From there, the
dissection goes wrong for a while.

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

[Wireshark-bugs] [Bug 15718] RTMPT does not handle extended timestamp with Chunk Type 3

[bugzilla-daemon]

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

Bill May  changed:

   What|Removed |Added

 CC||bill@disneystreaming.co
   ||m

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

[Wireshark-bugs] [Bug 15707] Wireshark fails on piped/streamed pcapng packet capture data with mixed BE/LE SHBs, but reads mixed BE/LE files correctly

[bugzilla-daemon]

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

--- Comment #4 from Tomasz Mon  ---
Could you please provide some mixed-endian pcapng file that contains some
actual data packets?

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

[Wireshark-bugs] [Bug 15714] Support for the PROXY (v1) protocol (HAPROXY) over TCP

[bugzilla-daemon]

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

--- Comment #2 from Peter Wu  ---
Created attachment 17077
  --> https://bugs.wireshark.org/bugzilla/attachment.cgi?id=17077&action=edit
PROXY (v1) capture using nginx

Attached capture is a sample capture created using nginx 1.14.2 on Arch Linux.

Example nginx configuration and Bash commands for testing:

cat > nginx.conf 

[Wireshark-bugs] [Bug 15717] New: Allow UDP/TCP port-specific protocol dissector to be disabled to allow extracting the protocol payload

[bugzilla-daemon]

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

Bug ID: 15717
   Summary: Allow UDP/TCP port-specific protocol dissector to be
disabled to allow extracting the protocol payload
   Product: Wireshark
   Version: Git
  Hardware: All
OS: All
Status: CONFIRMED
  Severity: Enhancement
  Priority: Low
 Component: Dissection engine (libwireshark)
  Assignee: bugzilla-ad...@wireshark.org
  Reporter: pe...@lekensteyn.nl
  Target Milestone: ---

Build Information:
TShark (Wireshark) 3.1.0 (v3.1.0rc0-577-g82d24d90)

Copyright 1998-2019 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 libpcap, with POSIX capabilities (Linux), with libnl 3,
with GLib 2.60.0, with zlib 1.2.11, without SMI, with c-ares 1.15.0, with Lua
5.2.4, with GnuTLS 3.6.7 and PKCS #11 support, with Gcrypt 1.8.4, with MIT
Kerberos, with MaxMind DB resolver, with nghttp2 1.36.0, with LZ4, with Snappy,
with libxml2 2.9.9.

Running on Linux 4.20.12-arch1-1-ARCH, with Intel(R) Core(TM) i7-6700HQ CPU @
2.60GHz (with SSE4.2), with 31984 MB of physical memory, with locale
en_GB.UTF-8, with libpcap version 1.9.0-PRE-GIT (with TPACKET_V3), with GnuTLS
3.6.7, with Gcrypt 1.8.4, with zlib 1.2.11, binary plugins supported (0
loaded).

Built using clang 4.2.1 Compatible Clang 8.0.0 (tags/RELEASE_800/final).

--
I would like to dump the UDP payload that consists of a DNS message. Disabling
the DNS protocol with "--disable-protocol dns" works in this particular case.
However a more generic approach would be desirable, one that does not rely on
the user knowing the protocol in use (and one that is not affected by
heuristics subdissectors).

Maybe the "Decode As" functionality could be extended to any protocol to
specially recognize the "data" dissector? That would enable:

tshark -r some.pcap -d udp.port==53,data -T fields -e data

Other use cases that can be enabled by this:

- Display decrypted TLS application data as plain bytes without further
interpretation.
- When analyzing L4 (UDP/TCP) behavior, disable all subdissectors.
  This could be done by specifying a port range 1-65535 -> data.

I am not sure, but perhaps this might not work if "Try heuristics subdissectors
first" is enabled.

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

[Wireshark-bugs] [Bug 15136] Change value of raw_sip metafield from a string constant to actual packet data, fix handling of sip.msg_hdr and sip.msg_body

[bugzilla-daemon]

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

Peter Wu  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 CC||pe...@lekensteyn.nl
 Status|UNCONFIRMED |CONFIRMED

--- Comment #1 from Peter Wu  ---
tshark always uses "1" for fields that do not contain a value (FT_NONE) to
signify presence of these fields.

For protocols (FT_PROTOCOL) it always prints the protocol name (or whatever
label was assigned manually to the field).

I too would like an option to force the bytes to be presented instead. Maybe a
new "-E" option could be added to force these fields to be displayed as bytes.
Or more generically, add a special notation to force extraction of the
underlying buffer, for example:

tshark -r some.pcap -Tfields -e 'bytes(raw_sip)'

Though there might be an ambiguity with some dissectors. For some protocol
items, the underlying buffer might not match the represented value or even be
empty. For example, a dissector could mark three bytes, but expand it to five
bytes based on some protocol-specific details. Which of the two should be
returned if the function is literally called 'bytes'? Maybe 'buffer' would be a
better name.

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

[Wireshark-bugs] [Bug 15716] New: Backslash escape rules for values in display filters are not properly documented

[bugzilla-daemon]

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

Bug ID: 15716
   Summary: Backslash escape rules for values in display filters
are not properly documented
   Product: Wireshark
   Version: 3.0.1
  Hardware: All
OS: All
Status: CONFIRMED
  Severity: Normal
  Priority: Low
 Component: Documentation
  Assignee: bugzilla-ad...@wireshark.org
  Reporter: pe...@lekensteyn.nl
  Target Milestone: ---

Build Information:
TShark (Wireshark) 3.1.0 (v3.1.0rc0-577-g82d24d90)

Copyright 1998-2019 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 libpcap, with POSIX capabilities (Linux), with libnl 3,
with GLib 2.60.0, with zlib 1.2.11, without SMI, with c-ares 1.15.0, with Lua
5.2.4, with GnuTLS 3.6.7 and PKCS #11 support, with Gcrypt 1.8.4, with MIT
Kerberos, with MaxMind DB resolver, with nghttp2 1.36.0, with LZ4, with Snappy,
with libxml2 2.9.9.

Running on Linux 4.20.12-arch1-1-ARCH, with Intel(R) Core(TM) i7-6700HQ CPU @
2.60GHz (with SSE4.2), with 31984 MB of physical memory, with locale
en_GB.UTF-8, with libpcap version 1.9.0-PRE-GIT (with TPACKET_V3), with GnuTLS
3.6.7, with Gcrypt 1.8.4, with zlib 1.2.11, binary plugins supported (0
loaded).

Built using clang 4.2.1 Compatible Clang 8.0.0 (tags/RELEASE_800/final).

--
The Wireshark User's Guide[1] and display-filter manual[2] should explain more
clearly how values are processed. This should help understanding the following
filters:

data == 28
data == "28"
data == "\x28"
data == "\\x28"
data == "\\\x28"
data matches "\x28"
data matches "\\x28"
data matches "\\\x28"

This should help users avoiding confusion as happened in bug 10161.

 [1]: https://www.wireshark.org/docs/man-pages/wireshark-filter.html
 [2]:
https://www.wireshark.org/docs/wsug_html_chunked/ChWorkBuildDisplayFilterSection.html

Shortcomings:
- While the wireshark-filter manual mentions quoting and gives some examples of
hexadecimal escapes, the User's Guide does not mention this at all.
- Both: the matches operator should mention escaping special regex characters
  such as '(' (see bug 10161).
- The User's Guide suggests filters with improperly escaped dots, these will
  act as wildcard since the display filter parser will strip the backslash:

http.host matches "acme\.(org|com|net)"
string(ip.dst) matches "^172\.(1[6-9]|2[0-9]|3[0-1])\..{1,3}\.255"

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

[Wireshark-bugs] [Bug 13951] DisplayFilterEdit not handling keyboard "accept" for autocomplete in delegate classes

[bugzilla-daemon]

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

Peter Wu  changed:

   What|Removed |Added

   See Also||https://bugs.wireshark.org/
   ||bugzilla/show_bug.cgi?id=14
   ||668

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

[Wireshark-bugs] [Bug 14668] Hitting Enter on autocompletion suggestions stops editing instead of accepting the suggestion

[bugzilla-daemon]

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

Peter Wu  changed:

   What|Removed |Added

   See Also||https://bugs.wireshark.org/
   ||bugzilla/show_bug.cgi?id=13
   ||951

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

[Wireshark-bugs] [Bug 14668] Hitting Enter on autocompletion suggestions stops editing instead of accepting the suggestion

[bugzilla-daemon]

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

Peter Wu  changed:

   What|Removed |Added

   Severity|Enhancement |Normal
 CC||pe...@lekensteyn.nl
Summary|auto complete filter work   |Hitting Enter on
   |on display filter but not   |autocompletion suggestions
   |on color filter |stops editing instead of
   ||accepting the suggestion

--- Comment #1 from Peter Wu  ---
Hi Brian,

Is this still an issue for you? I was not able to reproduce it on Arch Linux
(KDE Plasma) with the current versions (v3.1.0rc0-577-g82d24d907a and
v3.0.2rc0-18-ga090b584c6).

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

[Wireshark-bugs] [Bug 10161] seems like hex matches are broken completely for frame and data

[bugzilla-daemon]

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

Peter Wu  changed:

   What|Removed |Added

 CC||pe...@lekensteyn.nl
 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |NOTABUG

--- Comment #1 from Peter Wu  ---
The matches operator accepts a regular expression, the filter "\x29" is treated
as ")":

$ dftest 'data.data matches "\x29"'
Filter: "data.data matches "\x29""
dftest: Error while compiling regular expression ) at char 0: ) without opening
(
$ dftest 'data.data matches ")"'
Filter: "data.data matches ")""
dftest: Error while compiling regular expression ) at char 0: ) without opening
(

To literally match the ")" character in a regular expression, you need to
escape it with a backslash:

\)

However since the display filter language itself also performs escaping, you
would have to add another level of escapes:

\\)
\\\x25

If you are not interested in regular expressions, use the contains operator
instead. For example, to match four bytes "\x29\x40\x42\xff", use:


data.data contains 29:40:42:ff

See also https://www.wireshark.org/docs/man-pages/wireshark-filter.html

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

[Wireshark-bugs] [Bug 15662] Building only libraries on windows fails due to CLEAN_C_FILES empty

[bugzilla-daemon]

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

Peter Wu  changed:

   What|Removed |Added

 Status|IN_PROGRESS |RESOLVED
 Resolution|--- |FIXED

--- Comment #7 from Peter Wu  ---
Fixed in
v3.1.0rc0-573-g7950811438
v3.0.2rc0-18-ga090b584c6

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

[Wireshark-bugs] [Bug 15662] Building only libraries on windows fails due to CLEAN_C_FILES empty

[bugzilla-daemon]

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

--- Comment #6 from Gerrit Code Review  ---
Change 32910 merged by Peter Wu:
CMake: fix Windows build when all binaries are disabled

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

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

[Wireshark-bugs] [Bug 15662] Building only libraries on windows fails due to CLEAN_C_FILES empty

[bugzilla-daemon]

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

--- Comment #5 from Gerrit Code Review  ---
Change 32910 had a related patch set uploaded by Peter Wu:
CMake: fix Windows build when all binaries are disabled

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

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

[Wireshark-bugs] [Bug 15715] New: ctest suite_clopts fails on non-English Windows 10

[bugzilla-daemon]

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

Bug ID: 15715
   Summary: ctest suite_clopts fails on non-English Windows 10
   Product: Wireshark
   Version: Git
  Hardware: x86
OS: Windows 10
Status: UNCONFIRMED
  Severity: Major
  Priority: Low
 Component: Build process
  Assignee: bugzilla-ad...@wireshark.org
  Reporter: deso...@gmail.com
  Target Milestone: ---

Created attachment 17074
  --> https://bugs.wireshark.org/bugzilla/attachment.cgi?id=17074&action=edit
ctest log Windows 10 x64 Pro - English (United States)

Build Information:
Paste the COMPLETE build information from "Help->About Wireshark", "wireshark
-v", or "tshark -v".
--
In Windows 10 x64 Pro it is possible to install multiple languages and
individually assign language to each profile. The languages can be modified in
PC settings -> Time and Lanaguge -> Language. The language change is active
after user logs off and then logs back in.

The Wireshark test suite fails when run on non-English Windows 10 x64. I have
tried with: English (United States), Polish and Finnish.

The ctest command I have used is: ctest -C RelWithDebInfo
--force-new-ctest-process --verbose

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

[Wireshark-bugs] [Bug 15715] ctest suite_clopts fails on non-English Windows 10

[bugzilla-daemon]

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

--- Comment #2 from Tomasz Mon  ---
Created attachment 17076
  --> https://bugs.wireshark.org/bugzilla/attachment.cgi?id=17076&action=edit
ctest log Windows 10 x64 Pro - Finnish

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

[Wireshark-bugs] [Bug 15715] ctest suite_clopts fails on non-English Windows 10

[bugzilla-daemon]

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

--- Comment #1 from Tomasz Mon  ---
Created attachment 17075
  --> https://bugs.wireshark.org/bugzilla/attachment.cgi?id=17075&action=edit
ctest log Windows 10 x64 Pro - Polish

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

[Wireshark-bugs] [Bug 15713] Static build fails to find glib2 dependencies

[bugzilla-daemon]

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

--- Comment #2 from fontaine.fabr...@gmail.com ---
Your proposal fixes the issue with glib2, thanks.
As soon as it's committed upstream, I'll use it in buildroot instead of my
proposal.

However, I have two more patches to completely fixes static build.
These patches fix:
 - rpath:
https://git.buildroot.net/buildroot/tree/package/wireshark/0002-CMakeLists.txt-disable-rpath-in-static-build.patch
 - pcap dependencies:
https://git.buildroot.net/buildroot/tree/package/wireshark/0003-FindPCAP.cmake-fix-static-build.patch

How should we proceed, should we discuss it here, should I open a new bug, or
send new PRs?

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

[Wireshark-bugs] [Bug 15695] Extcap closing capture packet pipe not detected by Wireshark on Windows

[bugzilla-daemon]

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

--- Comment #6 from Gerrit Code Review  ---
Change 32907 had a related patch set uploaded by Tomasz Moń:
dumpcap: Fix pipe read deadlock on Windows

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

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

[Wireshark-bugs] [Bug 15695] Extcap closing capture packet pipe not detected by Wireshark on Windows

[bugzilla-daemon]

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

Tomasz Mon  changed:

   What|Removed |Added

 Status|UNCONFIRMED |CONFIRMED
  Component|Extras  |Dumpcap
 Ever confirmed|0   |1

--- Comment #5 from Tomasz Mon  ---
This bug is due to a deadlock that happens in dumpcap. I can reproduce it on
Windows 10 x64 using the attached modified extcap example.

The win32 code where the deadlock occurs is:
>g_thread_new("cap_pipe_open_live", &cap_thread_read, pcap_src);
>
>pcap_src->cap_pipe_buf = (char *) &magic;
>pcap_src->cap_pipe_bytes_read = 0;
>pcap_src->cap_pipe_bytes_to_read = sizeof(magic);
>/* We don't have to worry about cap_pipe_read_mtx here */
>g_async_queue_push(pcap_src->cap_pipe_pending_q, 
> pcap_src->cap_pipe_buf);
>g_async_queue_pop(pcap_src->cap_pipe_done_q);
>/* jump messaging, if extcap had an error, stderr will provide the 
> correct message */
>if (pcap_src->cap_pipe_bytes_read <= 0 && extcap_pipe)
>goto error;

The g_async_queue_pop(pcap_src->cap_pipe_done_q); waits for message, however
the cap_thread_read() exits without posting anything to the queue.

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

[Wireshark-bugs] [Bug 15261] Deadlock in extcap toolbar creation

[bugzilla-daemon]

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

--- Comment #9 from Gerrit Code Review  ---
Change 32898 merged by Anders Broman:
Qt: Fix deadlock in extcap toolbar creation

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

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