[Wireshark-bugs] [Bug 15711] Wireshark initializes c-ares library without calling WSAStartup()

[bugzilla-daemon]

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

--- Comment #2 from Tomasz Mon  ---
(In reply to Jaap Keuter from comment #1)
> Could that tool show what path is taken to get to host_name_lookup_init()
> before WSAStartup() is called?

No, however I placed at breakpoint in ui/qt/main.cpp and the WSAStartup() was
indeed called.

Initially I suspected that we initialize different version than needed, but I
tried with 1.0, 1.1, 2.0, 2.1, 2.2 and it didn't have any effect.

The stacktrace is as follows:
vrfcore.dll!VerifierStopMessageEx()
vfnet.dll!NetTrackStartup::StopIfNotInitialized(void *)
vfnet.dll!VfHookgethostname(char *,int)
cares.dll!init_by_defaults(ares_channeldata * channel)
cares.dll!ares_init_options(ares_channeldata * * channelptr, ares_options *
options, int optmask)
libwireshark.dll!host_name_lookup_init()
libwireshark.dll!addr_resolv_init()
libwireshark.dll!epan_init(void(*)(register_action_e, const char *, void *) cb,
void * client_data, int load_plugins)
Wireshark.exe!main(int argc, char * * qt_argv)
Wireshark.exe!WinMain(HINSTANCE__ * __formal, HINSTANCE__ * __formal, char *
__formal, int __formal)

-- 
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

João Valverde  changed:

   What|Removed |Added

 CC||joao.valverde@tecnico.ulisb
   ||oa.pt

--- Comment #1 from João Valverde  ---
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()

-- 
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 14657] Wireshark Hangs on startup initializing external capture plugins

[bugzilla-daemon]

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

Michael Mann  changed:

   What|Removed |Added

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

-- 
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 #1 from Peter Wu  ---
Example stunnel configuration for testing:

cat >> test.conf 

[Wireshark-bugs] [Bug 15704] Python asn2wrs script exeption with Python 2.7.15rc1

[bugzilla-daemon]

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

Michael Mann  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

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

[Wireshark-bugs] [Bug 14506] PROXY protocol (v2) support (HAproxy) for TCP: skip and maybe implement a full dissector

[bugzilla-daemon]

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

Peter Wu  changed:

   What|Removed |Added

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

-- 
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] New: Support for the PROXY (v1) protocol (HAPROXY) over TCP

[bugzilla-daemon]

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

Bug ID: 15714
   Summary: Support for the PROXY (v1) protocol (HAPROXY) over TCP
   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
CC: alexis.lagou...@gmail.com
  Target Milestone: ---

Build Information:
v3.1.0rc0-568-g0974b68f5c

--
Bug 14506 added support for the binary PROXY (v2) protocol as defined by
HAPROXY. The referenced document from 1.8 is still current as of 2.0:
https://www.haproxy.org/download/1.8/doc/proxy-protocol.txt

HAPROXY itself is a TCP service, so even though the specification mentions UDP
as transport, consider it out-of-scope for now. Not sure how that is supposed
to work since UDP is connectionless, ordering is not guaranteed. (But that
seems irrelevant anyway for v1 which only supports TCP.)

Address families for v1:
- "TCP4" - TCP over IPv4
- "TCP6" - TCP over IPv6
- "UNKNOWN" - sender can omit following data, receiver must ignore the
remainder
   of the line. So effectively it can contain garbage that is not checked by
the
   receiver? The spec does include an example with IPv6 addresses though.

To generate test captures, some available implementations include:
- nginx: supports TCP4/TCP6 only (both as client/server).
  https://nginx.org/en/docs/stream/ngx_stream_proxy_module.html
  https://docs.nginx.com/nginx/admin-guide/load-balancer/using-proxy-protocol/
- stunnel - supports TCP4/TCP6 as client only. In theory also UNIX domain
  sockets, but "getnameinfo: Unknown error" is printed before it sends data.

Now TCP is a stream-oriented protocol. Possible cases:
- PROXY header is split. Do not support this.
- PROXY header fits exactly. Dissect and done.
- PROXY header is followed by data. Dissect and call next dissector?

The line can be at most 107 (including CRLF) according to the spec.

-- 
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 15508] Dissection of DCOM's IProvideClassInfo

[bugzilla-daemon]

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

Michael Mann  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

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

[Wireshark-bugs] [Bug 15326] Feature request: Color blind users need syntax feedback other then color

[bugzilla-daemon]

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

Michael Mann  changed:

   What|Removed |Added

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

-- 
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 15592] Help file doesn't display for extcap interfaces

[bugzilla-daemon]

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

Michael Mann  changed:

   What|Removed |Added

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

-- 
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 15703] Enhance ETSI ITS support (latest ETSI TS 103 301 and ETSI TS 103 097)

[bugzilla-daemon]

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

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

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

[Wireshark-bugs] [Bug 15701] Enhance ETSI ITS support (latest ETSI TS 103 301 and ETSI TS 103 097)

[bugzilla-daemon]

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

Michael Mann  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #2 from Michael Mann  ---


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

-- 
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 15454] Dissection of CAN packets based on a DBC specification

[bugzilla-daemon]

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

--- Comment #10 from Guy Harris  ---
(In reply to Maksim Salau from comment #9)
> I tried byacc and it works fine with valid input. But if I induce errors I
> get memory leaks, since byacc shipped with Fedora doesn't have support for
> btyacc extensions and thus I'm not allowed to use %destructor directive to
> get rid of memory allocated data.
> 
> So here is the question: does Wireshark require btyacc extensions to be
> enabled?

Our one and only Bison/BYACC parser (wiretap/ascend.y) doesn't require them.

The primary reason for BYACC support is for systems that ship with BYACC but
not Bison, as I think might be the case for some *BSD systems.  The version of
BYACC that ships with a Linux distribution is less relevant than the version
that ships with various *BSDs, as Linux distributions will almost certainly
ship Bison as well.

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

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

[bugzilla-daemon]

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

Bug ID: 15713
   Summary: Static build fails to find glib2 dependencies
   Product: Wireshark
   Version: 3.0.1
  Hardware: x86
OS: Linux
Status: UNCONFIRMED
  Severity: Major
  Priority: Low
 Component: Build process
  Assignee: bugzilla-ad...@wireshark.org
  Reporter: fontaine.fabr...@gmail.com
  Target Milestone: ---

Created attachment 17073
  --> https://bugs.wireshark.org/bugzilla/attachment.cgi?id=17073=edit
logfile of build failure

Build Information:
3.0.1
--
When upgrading wireshark to version in 3.0.1 in buildroot (a tool to create
embedded linux systems), I found an issue in the way pkg-config was handled to
find glib2 dependencies.

I made a patch that worked on wireshark 3.0.1 but I was advised to create a bug
report (https://code.wireshark.org/review/#/c/32869/). So here it is.

So the way to reproduce is to have a toolchain with static build support only
and run the following command:

(mkdir -p /home/fabrice/br-test-pkg/br-arm-full-static/build/wireshark-3.0.1/
&& cd /home/fabrice/br-test-pkg/br-arm-full-static/build/wireshark-3.0.1/ && rm
-f CMakeCache.txt &&
PATH="/home/fabrice/br-test-pkg/br-arm-full-static/host/bin:/home/fabrice/br-test-pkg/br-arm-full-static/host/sbin:/usr/local/sbin:/usr/sbin:/sbin:/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games"
 /usr/bin/cmake
/home/fabrice/br-test-pkg/br-arm-full-static/build/wireshark-3.0.1/
-DCMAKE_TOOLCHAIN_FILE="/home/fabrice/br-test-pkg/br-arm-full-static/host/share/buildroot/toolchainfile.cmake"
-DCMAKE_INSTALL_PREFIX="/usr" -DCMAKE_COLOR_MAKEFILE=OFF -DBUILD_DOC=OFF
-DBUILD_DOCS=OFF -DBUILD_EXAMPLE=OFF -DBUILD_EXAMPLES=OFF -DBUILD_TEST=OFF
-DBUILD_TESTS=OFF -DBUILD_TESTING=OFF -DBUILD_SHARED_LIBS=OFF  -DENABLE_PCAP=ON
-DENABLE_SMI=OFF -DBUILD_wireshark=OFF -DENABLE_BCG729=OFF -DENABLE_CARES=OFF
-DENABLE_GNUTLS=OFF -DENABLE_KERBEROS=OFF -DBUILD_mmdbresolve=OFF
-DENABLE_NETLINK=OFF -DENABLE_LIBSSH=OFF -DENABLE_LIBXML2=OFF -DENABLE_LUA=OFF
-DENABLE_LZ4=OFF -DENABLE_NGHTTP2=OFF -DENABLE_SBC=OFF -DENABLE_SNAPPY=OFF
-DENABLE_SPANDSP=OFF -DBUILD_sdjournal=OFF -DENABLE_PLUGINS=OFF
-DENABLE_STATIC=ON

Build fails on:

/home/fabrice/br-test-pkg/br-arm-full-static/host/arm-buildroot-linux-uclibcgnueabi/sysroot/usr/lib/libglib-2.0.a(libglib_2_0_la-gregex.o):
In function `get_matched_substring_number':
gregex.c:(.text+0x1e4): undefined reference to `pcre_get_stringnumber'
gregex.c:(.text+0x1f8): undefined reference to `pcre_get_stringtable_entries'
/home/fabrice/br-test-pkg/br-arm-full-static/host/arm-buildroot-linux-uclibcgnueabi/sysroot/usr/lib/libglib-2.0.a(libglib_2_0_la-gregex.o):
In function `g_match_info_next':
gregex.c:(.text+0x8ec): undefined reference to `pcre_exec'
/home/fabrice/br-test-pkg/br-arm-full-static/host/arm-buildroot-linux-uclibcgnueabi/sysroot/usr/lib/libglib-2.0.a(libglib_2_0_la-gregex.o):
In function `regex_compile':
gregex.c:(.text+0x10dc): undefined reference to `pcre_compile2'
gregex.c:(.text+0x14fc): undefined reference to `pcre_fullinfo'
gregex.c:(.text+0x1534): undefined reference to `pcre_fullinfo'
/home/fabrice/br-test-pkg/br-arm-full-static/host/arm-buildroot-linux-uclibcgnueabi/sysroot/usr/lib/libglib-2.0.a(libglib_2_0_la-gregex.o):
In function `match_info_new':
gregex.c:(.text+0x1754): undefined reference to `pcre_fullinfo'
/home/fabrice/br-test-pkg/br-arm-full-static/host/arm-buildroot-linux-uclibcgnueabi/sysroot/usr/lib/libglib-2.0.a(libglib_2_0_la-gregex.o):
In function `g_regex_unref':
gregex.c:(.text+0x17e0): undefined reference to `pcre_free'
/home/fabrice/br-test-pkg/br-arm-full-static/host/arm-buildroot-linux-uclibcgnueabi/sysroot/usr/lib/libglib-2.0.a(libglib_2_0_la-gregex.o):
In function `g_regex_new':
gregex.c:(.text+0x1900): undefined reference to `pcre_config'
gregex.c:(.text+0x1930): undefined reference to `pcre_config'
gregex.c:(.text+0x1a20): undefined reference to `pcre_study'
/home/fabrice/br-test-pkg/br-arm-full-static/host/arm-buildroot-linux-uclibcgnueabi/sysroot/usr/lib/libglib-2.0.a(libglib_2_0_la-gregex.o):
In function `g_regex_get_max_backref':
gregex.c:(.text+0x1afc): undefined reference to `pcre_fullinfo'
/home/fabrice/br-test-pkg/br-arm-full-static/host/arm-buildroot-linux-uclibcgnueabi/sysroot/usr/lib/libglib-2.0.a(libglib_2_0_la-gregex.o):
In function `g_regex_get_capture_count':
gregex.c:(.text+0x1b20): undefined reference to `pcre_fullinfo'
/home/fabrice/br-test-pkg/br-arm-full-static/host/arm-buildroot-linux-uclibcgnueabi/sysroot/usr/lib/libglib-2.0.a(libglib_2_0_la-gregex.o):
In function `g_regex_get_has_cr_or_lf':
gregex.c:(.text+0x1b44): undefined reference to `pcre_fullinfo'
/home/fabrice/br-test-pkg/br-arm-full-static/host/arm-buildroot-linux-uclibcgnueabi/sysroot/usr/lib/libglib-2.0.a(libglib_2_0_la-gregex.o):
In function `g_regex_get_max_lookbehind':
gregex.c:(.text+0x1b70): undefined reference to 

[Wireshark-bugs] [Bug 15712] Wireshark hides length and does not fully display UDP/Ethernet packets if packet is > 1415 bytes.

[bugzilla-daemon]

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

--- Comment #3 from Guy Harris  ---
(In reply to Brian Cowan from comment #2)
> Resolved as user error. If a UDP packet gets fragmented, a port-specific
> filter will not capture all the packets since only the first contains the
> port number. UDP != TCP where packet headers are concerned.

If you happen to have TCP segments too big to fit in a single link-layer frame,
so that the segment is put into multiple IP fragments, the same thing will
happen as with fragmented UDP packets.

The only difference is that TCP has its own segmentation/reassembly mechanism,
so if you want to send a 4KB message over TCP, and not all the hosts in the
path support 4K+{TCP header}+{IP header} packets, you don't have to send it as
a single TCP segment and have it fragmented at the IP layer, you can send it as
multiple TCP segments, each of which fits in a link-layer packet on all hops of
the route (especially if path MTU discovery is used, so you know what the
smallest MTU is), whereas UDP doesn't have a segmentation/ressembly mechanism,
so you *have* to rely on IP fragmentation if your message won't fit in a single
link-layer packet.

-- 
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 15712] Wireshark hides length and does not fully display UDP/Ethernet packets if packet is > 1415 bytes.

[bugzilla-daemon]

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

Brian Cowan  changed:

   What|Removed |Added

 Resolution|--- |NOTABUG
 Status|UNCONFIRMED |RESOLVED

-- 
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 15712] Wireshark hides length and does not fully display UDP/Ethernet packets if packet is > 1415 bytes.

[bugzilla-daemon]

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

--- Comment #2 from Brian Cowan  ---
Resolved as user error. If a UDP packet gets fragmented, a port-specific filter
will not capture all the packets since only the first contains the port number.
UDP != TCP where packet headers are concerned.

-- 
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 15710] extcap: Python scripts are not executed on Windows

[bugzilla-daemon]

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

--- Comment #3 from Gerrit Code Review  ---
Change 32901 had a related patch set uploaded by Peter Wu:
Add direct support for running Python extcap programs on Windows

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

-- 
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 15706] Build issue in Wireshark - 3.0.1 on RHEL6

[bugzilla-daemon]

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

Peter Wu  changed:

   What|Removed |Added

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

--- Comment #7 from Peter Wu  ---
Fixed the CMake issue that accidentally accepted an old GLib version in
v3.1.0rc0-566-g8c26217548
v3.0.2rc0-17-g86db127280

Note for others looking here:
RHEL 6 does not build with Wireshark 3.0 by default. You can of course manually
build newer versions of Libgcrypt and others though, but switching to RHEL 7 is
recommended if possible.

-- 
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 15711] Wireshark initializes c-ares library without calling WSAStartup()

[bugzilla-daemon]

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

--- Comment #1 from Jaap Keuter  ---
The paths to host_name_lookup_init() I could find were from ui/qt/main.cpp,
which all came _after_
#ifdef _WIN32
/* Start windows sockets */
result = WSAStartup( MAKEWORD( 1, 1 ),  );
if (result != 0)
{
ret_val = INIT_FAILED;
goto clean_exit;
}
#endif  /* _WIN32 */

Could that tool show what path is taken to get to host_name_lookup_init()
before WSAStartup() is called?

-- 
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 15706] Build issue in Wireshark - 3.0.1 on RHEL6

[bugzilla-daemon]

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

--- Comment #5 from Gerrit Code Review  ---
Change 32899 had a related patch set uploaded by Peter Wu:
CMake: bail out if minimum GLib version is not satisfied

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

-- 
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 15706] Build issue in Wireshark - 3.0.1 on RHEL6

[bugzilla-daemon]

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

--- Comment #6 from Gerrit Code Review  ---
Change 32899 merged by Peter Wu:
CMake: bail out if minimum GLib version is not satisfied

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

-- 
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 15706] Build issue in Wireshark - 3.0.1 on RHEL6

[bugzilla-daemon]

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

--- Comment #4 from Gerrit Code Review  ---
Change 32894 merged by Peter Wu:
CMake: bail out if minimum GLib version is not satisfied

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

-- 
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 15712] Wireshark hides length and does not fully display UDP/Ethernet packets if packet is > 1415 bytes.

[bugzilla-daemon]

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

--- Comment #1 from Jaap Keuter  ---
When looking at the capture I've come to a different conclusion. 
In the provided capture file frame #4 is the offending frame. Let's take a
closer look at that. 

Using tcpdump it says on frame #4:
15:23:49.581476 ... : UDP, bad length 4372 > 1472
So, the IP protocol interpreter sees (the start of) an IP payload with protocol
ID 17 (==UDP) and lets the UDP protocol interpreter interpret the header.
Indeed there the UDP length is 4380, which minus 8 octets for the UDP header is
4372 for the UDP payload.

Using Wireshark to load the file shows something different for frame #4. It
says:
4 0.001953 ... IPv4 1514 Fragmented IP protocol (proto=UDP 17, off=0, ID=02f7)
So, the IP protocol dissector sees the start of an IP payload with protocol ID
17 (==UDP) but keeps it to itself because the 'More fragments' flag is raised.
Another IP payload for that same ID (=027f) has to be found first to complete
the payload to be handed of to the UDP dissector. 

Can Wireshark be set to show the same as tcpdump does? Yes, by going into the
IP dissector preferences and reset the 'Reassemble fragmented IPv4 datagrams'
option. Now it shows the UDP header, with the length field of 4380, which goes
to a 4372 octet payload. 

Why is this not an error in Wireshark? Since the IP dissector is explicitly
told not to reassemble fragmented IPv4 datagrams, it would be a bit annoying to
have the UDP dissector whine about its length being too long for the underlying
IP datagram. That would be true for every first fragment of a fragmented IP
datagram (with protocol ID 17).

So why does tcpdump complain about it then? The answer is in the manual page:
BUGS
   Some attempt should be made to reassemble IP fragments or, at least to
compute the right length for the higher level protocol.

So, what else is there? The most important part of this capture, being frame #4
shows it. There's the first part of the fragmented datagram, but where's the
rest? Where are the other IP datagrams which make up the complete UDP packet?
Why are these not in the capture? How and where was this capture made? Do they
appear on other interfaces along the path between the endpoints? What
intervening components are there blocking the fragments?

-- 
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 15710] extcap: Python scripts are not executed on Windows

[bugzilla-daemon]

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

--- Comment #2 from Peter Wu  ---
Good point about PATHEXT, let's assume if an extension is present, the
interpreter should be correctly installed.

Here I found "ftype" and "assoc" commands which can be helpful:
https://stackoverflow.com/questions/1934675/how-to-execute-python-scripts-in-windows

Documentation in MSDN is a bit sad, the ASSOCF type points to the wrong page.
The shlwapi.h header does have the definitions though. AssocQueryString docs:
https://docs.microsoft.com/en-us/windows/desktop/api/shlwapi/nf-shlwapi-assocquerystringw

There are two potentially useful types, ASSOCSTR_COMMAND and
ASSOCSTR_EXECUTABLE. For ".py", these expand to respectively:

"C:\Windows\py.exe" "%L" %*
C:\Windows.py.exe

When used with unknown extensions and ASSOCF_NONE, it would expand to
respectively:

C:\Windows\system32\rundll32.exe
C:\Windows\System32\shell32.dll,OpenAs_RunDLL %1
C:\Windows\system32\shell32.dll

Use of ASSOCF_INIT_IGNOREUNKNOWN will make the function fail instead.

When used with .com, .exe, .bat, or .cmd, it will be:

"%1" $*
%1

>From what I have read, the Command string is interpreted by Internet Explorer,
but I have not found canonical documentation from MS. The executable value
seems good enough, it would work for .js, .pl, .py, .pyw, 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://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

Tomasz Mon  changed:

   What|Removed |Added

 CC||deso...@gmail.com

--- Comment #3 from Tomasz Mon  ---
I have tried following commands on Windows 10 x64:

cat le-shb.pcapng | Wireshark -k -i -

cat be-shb.pcapng | Wireshark -k -i -

cat bele-shbs.pcapng | Wireshark -k -i -

and noticed that le-shb.pcapng works fine ("No packets captured" information
box appears), while the be-shb.pcapnp and bele-shbs.pcapng result in
"Unrecognized pcapng format or not pcapng data."

After reading the issue description I got an impression that both le-shb.pcapnp
and be-shb.pcapng should work just fine. Did I misunderstand it? Or does the
cat into Wireshark stdin give different result than when extcap streams that
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://www.wireshark.org/mailman/options/wireshark-bugs
 mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe

[Wireshark-bugs] [Bug 15712] New: Wireshark hides length and does not fully display UDP/Ethernet packets if packet is > 1415 bytes.

[bugzilla-daemon]

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

Bug ID: 15712
   Summary: Wireshark hides length and does not fully display
UDP/Ethernet packets if packet is > 1415 bytes.
   Product: Wireshark
   Version: 3.0.1
  Hardware: x86
OS: Windows 10
Status: UNCONFIRMED
  Severity: Normal
  Priority: Low
 Component: Dissection engine (libwireshark)
  Assignee: bugzilla-ad...@wireshark.org
  Reporter: brco...@gmail.com
  Target Milestone: ---

Created attachment 17072
  --> https://bugs.wireshark.org/bugzilla/attachment.cgi?id=17072=edit
TCPDUMP ethernet tcapture of "cleartool lsview"

Build Information:
Wireshark 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 WinPcap SDK (WpdPack) 4.1.2, with GLib
2.52.2, with zlib 1.2.11, with SMI 0.4.8, with c-ares 1.14.0, with Lua 5.2.4,
with GnuTLS 3.6.3 and PKCS #11 support, with Gcrypt 1.8.3, with MIT Kerberos,
with MaxMind DB resolver, with nghttp2 1.14.0, with LZ4, with Snappy, with
libxml2 2.9.9, with QtMultimedia, with AirPcap, with SBC, with SpanDSP, with
bcg729.

Running on 64-bit Windows 10 (1809), build 17763, with Intel(R) Core(TM)
i7-6820HQ CPU @ 2.70GHz (with SSE4.2), with 32555 MB of physical memory, with
locale English_United States.1252, with libpcap version 1.9.0 (packet.dll
version 0.992), with GnuTLS 3.6.3, with Gcrypt 1.8.3, without AirPcap, binary
plugins supported (0 loaded).

Built using Microsoft Visual Studio 2017 (VC++ 14.12, build 25835).

--
In the attached network trace, I am using a VM to capture a trace of UDP
packets for ClearCase registry lookups. The default buffer size CC uses for a
call/response is 4KB. When I look at the packet trace in wireshark, it only
shows the first 1514 bytes of the packet. 

When I look at the same trace using tcpdump -r, it shows me that the packet
size is odd by printing this:
09:15:01.295139 IP 10.134.57.194.50323 > 10.134.49.78.clearcase: UDP, length
136
09:15:01.295866 IP 10.134.49.78.clearcase > 10.134.57.194.50323: UDP, bad
length 4288 > 1472
09:15:01.352985 IP 10.134.57.194.50323 > 10.134.49.78.clearcase: UDP, length
136
09:15:01.353809 IP 10.134.49.78.clearcase > 10.134.57.194.50323: UDP, bad
length 4052 > 1472

The data is all present, as a "strings" output shows all the expected text data
in the list.

tshark traces of the same test also report this when opened with TCPDUMP,
however, tshark ALSO hides the packet size mismatch when displaying packets. 

This issue was discovered during an investigation to determine why the data was
not reaching a client host and led us to incorrectly blame the server sending
the 4KB replies.

Wireshark and tshark should at the very least report the size mismatch. I
expect that this may also be an issue with Jumbo packets on Ethernet for both
tcpdump and npcap as neither seems to "notice" the size mismatch during the
capture. Both, however DO capture the entire data stream, so there is that.

-- 
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 15710] extcap: Python scripts are not executed on Windows

[bugzilla-daemon]

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

--- Comment #1 from Tomasz Mon  ---
(In reply to Peter Wu from comment #0)
> Use of AssocQueryString to lookup the program associated with an extension
> could work, but I am worried that on systems without Python installed (or a
> different default), it could end up opening a text editor for example. So
> some kind of whitelist would be needed.

If you don't have Python installed or if it's not associated to execute .py
files, then the .py won't appear in PATHEXT.

> In that case, what do you think about special casing Python support? If the
> extension is .py, lookup the Python interpreter (maybe in PATH for
> simplicity?) and use it. This does mean that if the user wants to use Lua,
> Perl or any other scripting language, then they would have to create a
> similar patch for Wireshark to support it out-of-the-box without a batch
> script.

I don't like the special case idea. The PATHEXT exists for a reason, we just
need to use it.

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

[Wireshark-bugs] [Bug 15711] New: Wireshark initializes c-ares library without calling WSAStartup()

[bugzilla-daemon]

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

Bug ID: 15711
   Summary: Wireshark initializes c-ares library without calling
WSAStartup()
   Product: Wireshark
   Version: Git
  Hardware: x86
OS: Windows 10
Status: UNCONFIRMED
  Severity: Major
  Priority: Low
 Component: Dissection engine (libwireshark)
  Assignee: bugzilla-ad...@wireshark.org
  Reporter: deso...@gmail.com
  Target Milestone: ---

Build Information:
Paste the COMPLETE build information from "Help->About Wireshark", "wireshark
-v", or "tshark -v".
--
On Windows, the WSAStartup() should be called before c-ares library functions
are called:
https://github.com/c-ares/c-ares/pull/180/commits/7870bd2e58a4b22aa6b5c92d58aa5df15a07fbec

c-ares is initialized in host_name_lookup_init() in epan/addr_resolv.c.

This problem was found using Application Verifier.

-- 
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 15696] ws_pipe_wait_for_pipe() can wait on closed handles

[bugzilla-daemon]

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

--- Comment #1 from Gerrit Code Review  ---
Change 32896 had a related patch set uploaded by Tomasz Moń:
wsutil: Refactor WIN32 ws_pipe_wait_for_pipe()

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

-- 
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 15710] New: extcap: Python scripts are not executed on Windows

[bugzilla-daemon]

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

Bug ID: 15710
   Summary: extcap: Python scripts are not executed on Windows
   Product: Wireshark
   Version: Git
  Hardware: All
OS: Windows
Status: CONFIRMED
  Severity: Normal
  Priority: Low
 Component: Common utilities (libwsutil)
  Assignee: bugzilla-ad...@wireshark.org
  Reporter: pe...@lekensteyn.nl
CC: deso...@gmail.com, lom...@gmail.com
  Target Milestone: ---

Build Information:
Paste the COMPLETE build information from "Help->About Wireshark", "wireshark
-v", or "tshark -v".
--
Copying the sample .py extcap utility does enable the interface on Windows,
macOS and Linux works normally.

To reproduce:

 mkdir extcapdir
 cp test\sampleif.py extcapdir
 $Env:WIRESHARK_EXTCAP_DIR="$PWD\extcapdir"
 $Env:G_MESSAGES_DEBUG="all"
 tshark -D

Expected results (Linux):

 (process:19931): Capture-DEBUG: 13:41:34.378: spawn params: 
--extcap-interfaces --extcap-version=3.1
 (process:19931): Capture-DEBUG: 13:41:34.412:
/tmp/wsbuild/extcapdir/sampleif.py finished in 34.037ms
 (process:19931): Capture-DEBUG: 13:41:34.412: spawn output: extcap
{version=1.0}
interface {value=sampleif}{display=Remote dumpcap}
 ...
 13. sampleif (Remote dumpcap)

Actual results (Windows):

 (tshark.exe:2480): Capture-DEBUG: spawn params:  --extcap-interfaces
--extcap-version=3.1
 (tshark.exe:2480): Capture-DEBUG: E:\\wsbuild\\extcapdir\\sampleif.py finished
in 0,000ms
 (tshark.exe:2480): Capture-DEBUG: spawn params:  --extcap-interfaces
 (tshark.exe:2480): Capture-DEBUG: E:\\wsbuild\\extcapdir\\sampleif.py finished
in 0,000ms
 (tshark.exe:2480): Capture-DEBUG: extcap: completed discovery of 1 tools in
0,000ms

(Note missing command output.)

While discussing https://code.wireshark.org/review/32754, Tomasz Moń writes:

> It is likely that the function that looks for extcaps already finds .py
> files if the configured .py file integration on Windows. It can be
> easily checked by looking at the PATHEXT environment variable.
>
> The limitation is that win32_create_process() in win32-utils.c is not
> aware of how to execute scripts that CreateProcess() cannot execute
> directly. That is, having the .py present in PATHEXT does not make
> CreateProcess() aware of how to launch them.
>
> One possibility would be to modify win32_create_process() to try
> CreateProcess() and if it fails, check if extension is in PATHEXT and if
> it is, then use AssocQueryString to look for the executable and prepend
> the executable to the supplied commandline. This however, just like the
> overlapped I/O, is quite simple in high level talk, but not so easy to
> actually implement it right.
>
> Having said that, I perfectly understand why the person who came up with
> the .bat wrapper idea, just wrote it in the documentation - as it gets
> the job done with (what I would consider) only a minor annoyance. 

Indeed, I do have ".py" in PATHEXT, so extcap_get_extcap_paths (extcap.c) does
pass the g_file_test(extcap_path, G_FILE_TEST_IS_EXECUTABLE) check and
therefore tries to execute it.

Digging through the git logs for the WSDG recommendation to create a batch
file, it looks like Dario added it first via doc/README.extcap (which
subsequently got incorporated into the WSDG).

Use of AssocQueryString to lookup the program associated with an extension
could work, but I am worried that on systems without Python installed (or a
different default), it could end up opening a text editor for example. So some
kind of whitelist would be needed.

In that case, what do you think about special casing Python support? If the
extension is .py, lookup the Python interpreter (maybe in PATH for simplicity?)
and use it. This does mean that if the user wants to use Lua, Perl or any other
scripting language, then they would have to create a similar patch for
Wireshark to support it out-of-the-box without a batch script.

-- 
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|CONFIRMED   |IN_PROGRESS

--- Comment #3 from Peter Wu  ---
Hi Fabian, could you try the above patch? It fixes the build for me.

-- 
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 #2 from Gerrit Code Review  ---
Change 32895 had a related patch set uploaded by Peter Wu:
CMake: fix Windows build when all binaries are disabled

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

-- 
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 15065] Wireshark can call extcap with empty multicheck argument

[bugzilla-daemon]

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

Pascal Quantin  changed:

   What|Removed |Added

 CC||pas...@wireshark.org
 Resolution|--- |FIXED
 Status|IN_PROGRESS |RESOLVED

-- 
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 15065] Wireshark can call extcap with empty multicheck argument

[bugzilla-daemon]

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

--- Comment #7 from Gerrit Code Review  ---
Change 32891 merged by Pascal Quantin:
Qt: Do not turn empty parameter values into spaces

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

-- 
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|UNCONFIRMED |CONFIRMED
 CC||pe...@lekensteyn.nl
 Ever confirmed|0   |1

--- Comment #1 from Peter Wu  ---
I can reproduce build failures on Windows on current master
(v3.1.0rc0-564-g727aaad3ae), I'll have a look.

FWIW, disabling all BUILD_xxx options on Linux works fine.

mkdir build && cd build
cmake -GNinja $(grep 'BUILD\S+' -Po ../CMakeOptions.txt | sed 's/.*/-D&=OFF/')
..
ninja
DESTDIR=$PWD/fs ninja install

-- 
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 15706] Build issue in Wireshark - 3.0.1 on RHEL6

[bugzilla-daemon]

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

--- Comment #3 from Peter Wu  ---
Could you also verify that the above patch stops CMake from succeeding?

As for suggestions, upgrade to RHEL7, continue using 2.6.x, or upgrade your
libs.

-- 
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 15706] Build issue in Wireshark - 3.0.1 on RHEL6

[bugzilla-daemon]

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

--- Comment #2 from Gerrit Code Review  ---
Change 32894 had a related patch set uploaded by Peter Wu:
CMake: bail out if minimum GLib version is not satisfied

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

-- 
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 10578] IPv6 Mobility Option Mobile Node Link Layer Identifier Link-layer Identifier field is read beyond the option data

[bugzilla-daemon]

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

--- Comment #4 from boaz.brick...@gmail.com ---
(In reply to Guy Harris from comment #3)
> So was this packet captured from a network, so that it should be valid, or
> is it somewhat fuzzed/randomized for use as part of the testing?  Wireshark
> reports a garbage string for the Service Selection option, and the payload
> protocol for the Mobile IPv6 header is AH, not "no next protocol"; RFC 6275
> says "Implementations conforming to this specification SHOULD set the
> payload protocol type to IPPROTO_NONE (59 decimal)."

I'm pretty sure this was not captured from the network and generated using code
for tests.

-- 
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 15706] Build issue in Wireshark - 3.0.1 on RHEL6

[bugzilla-daemon]

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

Peter Wu  changed:

   What|Removed |Added

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

--- Comment #1 from Peter Wu  ---
As mentioned in
https://www.wireshark.org/docs/relnotes/wireshark-3.0.0.html
https://wiki.wireshark.org/Development/Support_library_version_tracking

the minimum GLib version is 2.32 which is not present in RHEL6. Other libraries
(see the 3.0.0 release notes) have also seen a bump in the minimum version
requirement.

The fact that CMake did not error out is a bug, I'll try to fix that.

-- 
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 12787] Extcaps hang when launched from windows console

[bugzilla-daemon]

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

Peter Wu  changed:

   What|Removed |Added

 CC||pe...@lekensteyn.nl

--- Comment #8 from Peter Wu  ---
> It seems to me that the extcap detaches from the current console, so it 
> prints > the prompt before the actual printfs take place.

Could we close this bug than or would you like to have it addressed in a
different way?

-- 
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 15708] [HTTP/2] HEADERS frame fails after Fast Retransmission

[bugzilla-daemon]

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

--- Comment #5 from Peter Wu  ---
Oh that option should certainly not be enabled, maybe we should print some
expert info when this condition is enabled. Or maybe just remove it, it can
only ever work for block ciphers and will break with any cipher that uses a
counter (AEAD cipher suites in TLS 1.2 and all ciphers in 1.3).

Do you remember the reason for enabling this preference?

-- 
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 15065] Wireshark can call extcap with empty multicheck argument

[bugzilla-daemon]

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

--- Comment #6 from Gerrit Code Review  ---
Change 32891 had a related patch set uploaded by Pascal Quantin:
Qt: Do not turn empty parameter values into spaces

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

-- 
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