[Wireshark-bugs] [Bug 15208] MATE unable to extract fields for PDU

[bugzilla-daemon]

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

Scott Harman  changed:

   What|Removed |Added

 CC||sc...@harman.tv

-- 
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 15208] New: MATE unable to extract fields for PDU

[bugzilla-daemon]

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

Bug ID: 15208
   Summary: MATE unable to extract fields for PDU
   Product: Wireshark
   Version: 2.6.4
  Hardware: x86-64
OS: Windows 10
Status: UNCONFIRMED
  Severity: Normal
  Priority: Low
 Component: Dissection engine (libwireshark)
  Assignee: bugzilla-ad...@wireshark.org
  Reporter: sc...@harman.tv
  Target Milestone: ---

Created attachment 16651
  --> https://bugs.wireshark.org/bugzilla/attachment.cgi?id=16651=edit
Sample capture

Build Information:
Version 2.6.4-SAMSupport (v2.6.4) 
Copyright 1998-2018 Gerald Combs  and contributors.
License GPLv2+: GNU GPL version 2 or later
 This is free software;
see the source for copying conditions. There is NO warranty; not even for
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. 
Compiled (64-bit) with Qt 5.9.1, with WinPcap (4_1_3), with GLib 2.42.0, with
zlib 1.2.11, with SMI 0.4.8, with c-ares 1.14.0, with Lua 5.2.4, with GnuTLS
3.4.11, with Gcrypt 1.7.6, with MIT Kerberos, with MaxMind DB resolver, with
nghttp2 1.14.0, with LZ4, with Snappy, with libxml2 2.9.4, with QtMultimedia,
with AirPcap, with SBC, with SpanDSP, with bcg729. 
Running on 64-bit Windows 10, build 17763, with Intel(R) Core(TM) i7-6600U CPU
@ 2.60GHz (with SSE4.2), with 8084 MB of physical memory, with locale
English_Australia.1252, with WinPcap version 4.1.3 (packet.dll version
4.1.0.2980), based on libpcap version 1.0 branch 1_0_rel0b (20091008), with
GnuTLS 3.4.11, with Gcrypt 1.7.6, without AirPcap, binary plugins supported (18
loaded). Built using Microsoft Visual C++ 14.0 build 24215 

--
Hi team - I'd logged a question on ask.wireshark.org
(https://ask.wireshark.org/question/5499/mate-protocol-weirdness/) but have now
extablished that the issue also occurs with the sample MATE dissectors
available on the Wiki.

Basic dissector for our giop-q_quentin plugin:

~~~
Pdu giop_pdu Proto giop Transport tcp/ip {
Extract giop_addr From ip.addr;
Extract giop_port From tcp.port;
Extract giop_type From giop.type;
Extract giop_request_id From giop.request_id;
Extract giop_request_op From giop.request_op;
};

Gop giop_req On giop_pdu Match (giop_request_id) {
Start (giop_type = 0);
Stop (giop_type = 1);
Extra (giop_request_op);
};

Done;
~~~
I've tested this in a few versions
With the web example, the pdu doesn't contain anything other than the time, and
likewise isn't extracting any sensible 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 15205] Infinite read loop when extcap exits with error and error message

[bugzilla-daemon]

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

--- Comment #14 from Guy Harris  ---
So if you truly cannot rely on *anything* about the data that arrives on the
standard error from an extcap program, then you should define a mechanism, with
a *defined protocol*, for reporting errors, encourage the use of *that* rather
than the standard error for reporting errors, and just read what you can from
the standard error and report that.

Only errors from code *not* under the control of the extcap program's author
would show up on the standard error, and would indicate some failure on the
part of the program (i.e., probably a bug of some sort).

-- 
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 15205] Infinite read loop when extcap exits with error and error message

[bugzilla-daemon]

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

--- Comment #13 from Guy Harris  ---
(In reply to Stig Bjørlykke from comment #12)
> 
> We are about to close the
> extcap utility using g_spawn_close_pid() so I suppose we just read whatever
> is in the pipe before closing. This is a better feedback to the user than
> presenting nothing.

Whatever.

-- 
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 15202] Customize ask.wireshark.org for Wireshark

[bugzilla-daemon]

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

Alexis La Goutte  changed:

   What|Removed |Added

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

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

[Wireshark-bugs] [Bug 15205] Infinite read loop when extcap exits with error and error message

[bugzilla-daemon]

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

Stig Bjørlykke  changed:

   What|Removed |Added

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

--- Comment #12 from Stig Bjørlykke  ---
(In reply to Guy Harris from comment #11)
> So how do you know when you have the entire message string?  Do you just
> hope that a single read from the pipe will deliver the entire message?

I did not design or refactor this code, I just want to avoid the infinite loop
reading stderr from the extcap utility. We are about to close the extcap
utility using g_spawn_close_pid() so I suppose we just read whatever is in the
pipe before closing. This is a better feedback to the user than presenting
nothing.

-- 
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 14381] cannot find any Mongo Wire Protocol (MONGO) package

[bugzilla-daemon]

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

Alexis La Goutte  changed:

   What|Removed |Added

 CC||pe...@lekensteyn.nl

-- 
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 14381] cannot find any Mongo Wire Protocol (MONGO) package

[bugzilla-daemon]

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

--- Comment #3 from Alexis La Goutte  ---
(In reply to Michael Mann from comment #2)
> I believe the issue is that the provided .pcap on the wiki, when you load it
> into Wireshark doesn't show any MONGO traffic.  To show the mongo traffic I
> had to disable the SSL dissector and then use Decode As (for MONGO) on the
> port.  There may be other "preference manipulations" that can be done to
> have the MONGO traffic show up, but it may be considered confusing that it
> doesn't show up by default.
> Maybe SSL is too aggressive?

a second effect of change from Bug 14275
(g4cf7cd3ed20c57dc5977be5be37ced0bd1706d61)

-- 
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 15205] Infinite read loop when extcap exits with error and error message

[bugzilla-daemon]

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

--- Comment #11 from Guy Harris  ---
(In reply to Stig Bjørlykke from comment #9)
> (In reply to Guy Harris from comment #8)
> > Then you'd better make sure the stderr pipe is closed after the message is
> > written, otherwise the behavior of ws_read_string_from_pipe() will be
> > unpredictable.
> 
> The stderr pipe is created by g_spawn_async_with_pipes() and must be closed
> by the caller, which is the Wireshark extcap handling code. Therefore we
> can't ensure this pipe is closed after the message is written.
> 
> Remember that the extcap utility may be written by a user, and we should not
> loop infinite even if the extcap utility misbehaves.

So how do you know when you have the entire message string?  Do you just hope
that a single read from the pipe will deliver the entire message?

-- 
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 15205] Infinite read loop when extcap exits with error and error message

[bugzilla-daemon]

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

--- Comment #10 from Gerrit Code Review  ---
Change 30221 had a related patch set uploaded by Stig Bjørlykke:
extcap: Close stdout_fd and stderr_fd when done

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

-- 
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 15205] Infinite read loop when extcap exits with error and error message

[bugzilla-daemon]

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

--- Comment #9 from Stig Bjørlykke  ---
(In reply to Guy Harris from comment #8)
> Then you'd better make sure the stderr pipe is closed after the message is
> written, otherwise the behavior of ws_read_string_from_pipe() will be
> unpredictable.

The stderr pipe is created by g_spawn_async_with_pipes() and must be closed by
the caller, which is the Wireshark extcap handling code. Therefore we can't
ensure this pipe is closed after the message is written.

Remember that the extcap utility may be written by a user, and we should not
loop infinite even if the extcap utility misbehaves.

-- 
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 15207] Changing language setting doesn't change the language used

[bugzilla-daemon]

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

Alexis La Goutte  changed:

   What|Removed |Added

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

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

[Wireshark-bugs] [Bug 15056] ESP will not decode since 2.6.2 - works fine in 2.4.6 or 2.4.8

[bugzilla-daemon]

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

--- Comment #11 from Gerrit Code Review  ---
Change 30218 merged by Jaap Keuter:
ESP: improve IPv6 address matching

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

-- 
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 14949] Test don't compile without pcap

[bugzilla-daemon]

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

--- Comment #3 from Gerrit Code Review  ---
Change 30220 had a related patch set uploaded by Peter Wu:
test: make it possible to use pytest-style test fixtures

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

-- 
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 15207] Changing language setting doesn't change the language used

[bugzilla-daemon]

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

Guy Harris  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |INCOMPLETE

--- Comment #2 from Guy Harris  ---
What does the "About" information for *Wireshark*, rather than *TShark*, show?

-- 
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 15207] Changing language setting doesn't change the language used

[bugzilla-daemon]

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

Guy Harris  changed:

   What|Removed |Added

Summary|Language Interface  |Changing language setting
   ||doesn't change the language
   ||used
  Component|GTK+ UI |Qt UI

--- Comment #1 from Guy Harris  ---
So this is changing the language in the Wireshark preferences, not changing the
*system* language setting?

When the language preference in Wireshark is set to its default value, which is
"Use the system setting", does it use that setting or does it use English even
if that's not the system setting?

-- 
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 15207] New: Language Interface

[bugzilla-daemon]

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

Bug ID: 15207
   Summary: Language Interface
   Product: Wireshark
   Version: 2.6.4
  Hardware: x86-64
OS: Windows 10
Status: UNCONFIRMED
  Severity: Major
  Priority: Low
 Component: GTK+ UI
  Assignee: bugzilla-ad...@wireshark.org
  Reporter: xerxe...@gmail.com
  Target Milestone: ---

Created attachment 16650
  --> https://bugs.wireshark.org/bugzilla/attachment.cgi?id=16650=edit
Wireshark GUI only English

Build Information:
TShark (Wireshark) 2.6.4 (v2.6.4-0-g29d48ec8)

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

This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Compiled (64-bit) with WinPcap (4_1_3), with GLib 2.42.0, with zlib 1.2.11,
with
SMI 0.4.8, with c-ares 1.14.0, with Lua 5.2.4, with GnuTLS 3.4.11, with Gcrypt
1.7.6, with MIT Kerberos, with MaxMind DB resolver, with nghttp2 1.14.0, with
LZ4, with Snappy, with libxml2 2.9.4.

Running on 64-bit Windows 10, build 17763, with Intel(R) Core(TM) i7-6700 CPU @
3.40GHz (with SSE4.2), with 32706 MB of physical memory, with locale
German_Switzerland.1252, with WinPcap version 4.1.3 (packet.dll version
4.1.0.2980), based on libpcap version 1.0 branch 1_0_rel0b (20091008), with
GnuTLS 3.4.11, with Gcrypt 1.7.6, binary plugins supported (13 loaded).

Built using Microsoft Visual C++ 14.12 build 25835
--
In this release the language can not be changed. For example when you change to
German (also every other language), nothing happens. Always the English version
will be shown. But this is only after the update from version 2.6.3 to 2.6.4.
Thanks for help in advance.
Greetings
Michael

-- 
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 15056] ESP will not decode since 2.6.2 - works fine in 2.4.6 or 2.4.8

[bugzilla-daemon]

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

--- Comment #10 from Gerrit Code Review  ---
Change 30218 had a related patch set uploaded by Jaap Keuter:
ESP: improve IPv6 address matching

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

-- 
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 15206] New: OPC UA decoding does not consider the signature of message chunks

[bugzilla-daemon]

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

Bug ID: 15206
   Summary: OPC UA decoding does not consider the signature of
message chunks
   Product: Wireshark
   Version: 2.6.4
  Hardware: x86
OS: Windows 7
Status: UNCONFIRMED
  Severity: Major
  Priority: Low
 Component: Dissection engine (libwireshark)
  Assignee: bugzilla-ad...@wireshark.org
  Reporter: j...@hms.se
  Target Milestone: ---

Created attachment 16649
  --> https://bugs.wireshark.org/bugzilla/attachment.cgi?id=16649=edit
Create Session Request/Response

Build Information:
Version 2.6.4 (v2.6.4-0-g29d48ec8) 

Copyright 1998-2018 Gerald Combs  and contributors.
License GPLv2+: GNU GPL version 2 or later
 This is free software;
see the source for copying conditions. There is NO warranty; not even for
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. 

Compiled (64-bit) with Qt 5.9.5, with WinPcap (4_1_3), with GLib 2.42.0, with
zlib 1.2.11, with SMI 0.4.8, with c-ares 1.14.0, with Lua 5.2.4, with GnuTLS
3.4.11, with Gcrypt 1.7.6, with MIT Kerberos, with MaxMind DB resolver, with
nghttp2 1.14.0, with LZ4, with Snappy, with libxml2 2.9.4, with QtMultimedia,
with AirPcap, with SBC, with SpanDSP, with bcg729. 
Running on 64-bit Windows 7 Service Pack 1, build 7601, with Intel(R) Core(TM)
i7-6600U CPU @ 2.60GHz (with SSE4.2), with 7856 MB of physical memory, with
locale Swedish_Sweden.1252, with WinPcap version 4.1.3 (packet.dll version
4.1.0.2980), based on libpcap version 1.0 branch 1_0_rel0b (20091008), with
GnuTLS 3.4.11, with Gcrypt 1.7.6, without AirPcap, binary plugins supported (14
loaded). Built using Microsoft Visual C++ 14.12 build 25835 
Wireshark is Open Source Software released under the GNU General Public
License. 

Check the man page and http://www.wireshark.org for more information. 
--
When Wireshark concatenates several message chunks into a complete message when
the secure channel is signed, it does not consider the signature in the end of
each message chunk when decoding the message. This makes Wireshark to fail when
it tries to parse the message. All data that has been transmitted in the first
message chunk is parsed properly, but all data from message chunk 2 and forward
fails as it treats the signature of the first message chunk as message data.

In the attached Wireshark log a CreateSessionRequest is sent to an OPC UA
server and a response is received in return. The message chunk size is 8192
bytes (minimum allowed chunk size) and the response is therefore transferred in
two message chunks. The first chunk is completed in frame 12. The second chunk
is only one TCP frame and is received in frame 14. Wireshark can parse the
response until the ServerCertificate of ServerEndpoint[4]. This is also the
location where the message is split between message chunk 1 and 2.

What I can see, is that the message signature of message chunk 1 (last 20 bytes
of frame 12) is treated as message data and in this case as part of the
ServerCertificate of ServerEndpoint[4]. All data is then offset by 20 bytes and
 Wireshark fails to parse the remaining message 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