Re: [Wireshark-dev] Are AEAD cyphers accepted for IKEv2 decryption table?

[Peter Wu]

Hi Codrut,

On Tue, Aug 02, 2016 at 07:51:47AM +, Codrut Grosu wrote:
> Hi,
> 
> I'm working at a strongSwan plugin that will generate a IKEv2
> decryption table for wireshark.
> 
> In IKEv2 decryption table(wireshark) at encryption algorithm field
> there are only the following algorithms: "3DES[RFC2451]",
> "AES-CBC-128[RFC3602]", "AES-CBC-192[RFC3602]", "AES-CBC-256[RFC3602]"
> and "NULL[RFC2410]".
> 
> But strongSwan accepts AEAD cyphers like: AES_CCM_ICV8, AES_CCM_ICV12,
> AES_CCM_ICV16, AES_GCM_ICV8, AES_GCM_ICV12, AES_GCM_ICV16,
> NULL_AUTH_AES_GMAC, CAMELLIA_CCM_ICV8, CAMELLIA_CCM_ICV12,
> CAMELLIA_CCM_ICV16 and CHACHA20_POLY1305.
> 
> So, wireshark can decrypt packets that are encrypted with AEAD cyphers?

The available ciphers are listedn in epan/dissectors/packet-isakmp.c,
around line 1632 (ikev2_encr_algs). Supported ciphers are the ones you
mentioned, but it should be relatively easy to add support for the other
ciphers since gcrypt supports it (there are also some examples for this
in the SSL dissector). If you start adding support for this, please try
to make a packet capture available containing the various ciphers.

The libgcrypt docs are at
https://gnupg.org/documentation/manuals/gcrypt/Working-with-cipher-handles.html

If you want to start working on it, note that there is some related work
in this dissector (if it shows empty, then it is already closed):
https://code.wireshark.org/review/#/q/status:open+file:epan/dissectors/packet-isakmp.c
-- 
Kind regards,
Peter Wu
https://lekensteyn.nl
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

[Wireshark-dev] Documentation error in README.dissector?

[Paul Offord]

Hi,

README.dissector describes two accessor functions that access null terminated 
strings and return the string length.  The document says:

-
gint tvb_get_nstringz(tvbuff_t *tvb, const gint offset, const guint bufsize, 
guint8* buffer);
gint tvb_get_nstringz0(tvbuff_t *tvb, const gint offset, const guint bufsize, 
guint8* buffer);

Returns a null-terminated buffer containing data from the specified tvbuff,
starting at the specified offset, and containing all characters from the
tvbuff up to and including a terminating null character in the tvbuff.
"*lengthp" will be set to the length of the string, including the terminating
null.
-

I think these notes have been incorrectly copied and pasted from similar 
functions above this point in the doc.  Three particular points:


1.   We pass the address of the buffer we want to use as a parameter

2.  The value returned in the string length

3.  The length returned doesn't include the  null terminator

Am I right?  Should I raise a bug?

Thanks and regards...Paul

__

This message contains confidential information and is intended only for the 
individual named. If you are not the named addressee you should not 
disseminate, distribute or copy this e-mail. Please notify the sender 
immediately by e-mail if you have received this e-mail by mistake and delete 
this e-mail from your system.

Any views or opinions expressed are solely those of the author and do not 
necessarily represent those of Advance Seven Ltd. E-mail transmission cannot be 
guaranteed to be secure or error-free as information could be intercepted, 
corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The 
sender therefore does not accept liability for any errors or omissions in the 
contents of this message, which arise as a result of e-mail transmission.

Advance Seven Ltd. Registered in England & Wales numbered 2373877 at Endeavour 
House, Coopers End Lane, Stansted, Essex CM24 1SJ

__
This email has been scanned by the Symantec Email Security.cloud service.
For more information please visit http://www.symanteccloud.com
_
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] checklicenses.py

[João Valverde]

On 08/05/2016 08:17 PM, João Valverde wrote:



On 08/05/2016 11:53 AM, João Valverde wrote:



On 08/05/2016 11:50 AM, Guy Harris wrote:

On Aug 5, 2016, at 3:36 AM, João Valverde
 wrote:


On 08/05/2016 11:21 AM, Guy Harris wrote:


Should we just grab some version that works and include it in the
tools directory, so that we don't get mysterious failures when
updating the version of Ubuntu on the buildbot and don't fail - or
require somebody to dig up or install via CPAN - on systems that
don't distribute it?


No... too many CPAN dependencies.


I.e., it's not a standalone script, and you'd have to get a ton of
other scripts from CPAN and distribute them as well?


Yes (naturally this is the dependency problem CPAN itself tries to
solve).


The Debian licensecheck.pl version prior to the Smedegaard take over was
standalone. I think we should import that to tools.


Done in https://code.wireshark.org/review/#/c/16913/.

The master buildbot check licenses step is passing with a FIXME_FILES 
exception but let's not leave this hack in there forever...


I just added that because the new failures were caused by the different
licensecheck.pl version. Hopefully FIXME_FILES will be removed soon with 
a better solution.

___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] checklicenses.py

[Guy Harris]

On Aug 6, 2016, at 1:21 PM, João Valverde  
wrote:

> Done in https://code.wireshark.org/review/#/c/16913/.

Does "Removed regex to check files without an extension." mean that we are, or 
aren't, checking files without an extension?

If it means we aren't, should we give the few scripts that don't have an 
extension an extension, such as .sh for shell scripts, so that we check them 
for a license?  Most of our shell scripts have a .sh extension, although that's 
not necessarily the right answer for shell scripts to be run as commands.
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] checklicenses.py

[João Valverde]

On 08/06/2016 10:07 PM, Guy Harris wrote:

On Aug 6, 2016, at 1:21 PM, João Valverde  
wrote:


Done in https://code.wireshark.org/review/#/c/16913/.


Does "Removed regex to check files without an extension." mean that we are, or 
aren't, checking files without an extension?

If it means we aren't, should we give the few scripts that don't have an 
extension an extension, such as .sh for shell scripts, so that we check them 
for a license?  Most of our shell scripts have a .sh extension, although that's 
not necessarily the right answer for shell scripts to be run as commands.


It means we aren't checking files without an extension. I removed that 
match from the Debian script as unworkable for our purposes, made worse 
by the fact that the check licenses step is being run on an unclean 
build directory by PD.


I think your suggestion to add an .sh extension for files we wish to 
include would be best. But otherwise we should feel free to tailor 
checklicenses.py + licensecheck.pl in the tools dir to suit our needs.


For future reference here is the diff I applied to the upstream 
licensecheck.pl:


--- ../licensecheck.pl  2016-08-05 20:43:04.098683796 +0100
+++ tools/licensecheck.pl   2016-08-06 20:18:20.415943059 +0100
@@ -193,8 +193,6 @@ my $default_ignore_regex = qr!

 my $default_check_regex =
 qr!
-/[\w-]+$  # executable scripts or README like file
-|
 \.(  # search for file suffix
 c(c|pp|xx)?  # c and c++
|h(h|pp|xx)?  # header files for c and c++
@@ -594,7 +592,7 @@ EOF

 sub version {
 print <<"EOF";
-This is $progname, from the Debian devscripts package, version 
###VERSION###

+This is $progname, from the Debian devscripts package, version 2.16.2
 Copyright (C) 2007, 2008 by Adam D. Barratt 
; based

 on a script of the same name from the KDE SDK by .

@@ -657,7 +655,7 @@ sub parselicense {
$license = "GPL$gplver$extrainfo $license";
 }

-
+

 if ($licensetext =~ /is distributed under the terms of the GNU 
General Public License,/

and length $gplver) {
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] checklicenses.py

[Michael Mann]

So is the "checklicense tool" now the same between the Petri-Dish and the 
master buildbot?  Is that the reason the master buildbot now has to "pass" 
(otherwise all Petri-Dish runs will fail)?
 
If so, I prefer the way it used to be - master buildbot (legitimately) failing, 
but Petri-Dish being more lenient (even if it was unintentional).  The intent 
of the original email and my efforts was to only remove errors for files that 
had a legitimate reason not to have license template.  I think "all files 
without an extension" is a little too generous an exception (although I do 
appreciate all the work João did) .  Guy nicely outlined the remaining issues 
and I don't want those to get lost in the shuffle because the buildbot appears 
as if its "passing".


 
 
-Original Message-
From: João Valverde 
To: Developer support list for Wireshark 
Sent: Sat, Aug 6, 2016 5:43 pm
Subject: Re: [Wireshark-dev] checklicenses.py

On 08/06/2016 10:07 PM, Guy Harris wrote:> On Aug 6, 2016, at 1:21 PM, João 
Valverde  wrote:>>> Done in 
https://code.wireshark.org/review/#/c/16913/.>> Does "Removed regex to check 
files without an extension." mean that we are, or aren't, checking files 
without an extension?>> If it means we aren't, should we give the few scripts 
that don't have an extension an extension, such as .sh for shell scripts, so 
that we check them for a license?  Most of our shell scripts have a .sh 
extension, although that's not necessarily the right answer for shell scripts 
to be run as commands.It means we aren't checking files without an extension. I 
removed that match from the Debian script as unworkable for our purposes, made 
worse by the fact that the check licenses step is being run on an unclean build 
directory by PD.I think your suggestion to add an .sh extension for files we 
wish to include would be best. But otherwise we should feel free to tailor 
checklicenses.py + licensecheck.pl in the tools dir to suit our needs.For 
future reference here is the diff I applied to the upstream licensecheck.pl:--- 
../licensecheck.pl2016-08-05 20:43:04.098683796 +0100+++ 
tools/licensecheck.pl2016-08-06 20:18:20.415943059 +0100@@ -193,8 +193,6 @@ 
my $default_ignore_regex = qr!  my $default_check_regex =  qr!-/[\w-]+$ 
 # executable scripts or README like file-|  \.(
  # search for file suffix c(c|pp|xx)?  
# c and c++ |h(h|pp|xx)?  # header files for c and c++@@ 
-594,7 +592,7 @@ EOF  sub version {  print <<"EOF";-This is $progname, from 
the Debian devscripts package, version ###VERSION###+This is $progname, from 
the Debian devscripts package, version 2.16.2  Copyright (C) 2007, 2008 by Adam 
D. Barratt ; based  on a script of the same name 
from the KDE SDK by .@@ -657,7 +655,7 @@ sub parselicense {
   $license = "GPL$gplver$extrainfo $license";  }-+  if ($licensetext 
=~ /is distributed under the terms of the GNU General Public License,/   
and length $gplver) 
{___Sent
 via:Wireshark-dev mailing list Archives:
https://www.wireshark.org/lists/wireshark-devUnsubscribe: 
https://wireshark.org/mailman/options/wireshark-dev 
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] checklicenses.py

[João Valverde]

On 08/06/2016 11:01 PM, Michael Mann wrote:

So is the "checklicense tool" now the same between the Petri-Dish and
the master buildbot?  Is that the reason the master buildbot now has to
"pass" (otherwise all Petri-Dish runs will fail)?


Yes, that's the reason.


If so, I prefer the way it used  to be - master buildbot (legitimately)
failing, but Petri-Dish being more lenient (even if it was
unintentional).


OK, but PD was never lenient. The difference is that the PD 
licensecheck.pl used to match fewer files.


The intent of the original email and my efforts was to

only remove errors for files that had a legitimate reason not to have
license template.  I think "all files without an extension" is a little
too generous an exception (although I do appreciate all the work João
did) .  Guy nicely outlined the remaining issues and I don't want those
to get lost in the shuffle because the buildbot appears as if its "passing".


The overly generous situation was the extant situation before the recent 
buildbot upgrades to Ubuntu 16.04. But to eliminate is a one line change 
-- see the diff I mailed.




-Original Message-
From: João Valverde 
To: Developer support list for Wireshark 
Sent: Sat, Aug 6, 2016 5:43 pm
Subject: Re: [Wireshark-dev] checklicenses.py

On 08/06/2016 10:07 PM, Guy Harris wrote: > On Aug 6, 2016, at 1:21 PM,
João Valverde mailto:joao.valve...@tecnico.ulisboa.pt>> wrote: > >> Done in
https://code.wireshark.org/review/#/c/16913/. > > Does "Removed regex to
check files without an extension." mean that we are, or aren't, checking
files without an extension? > > If it means we aren't, should we give
the few scripts that don't have an extension an extension, such as .sh
for shell scripts, so that we check them for a license? Most of our
shell scripts have a .sh extension, although that's not necessarily the
right answer for shell scripts to be run as commands. It means we aren't
checking files without an extension. I removed that match from the
Debian script as unworkable for our purposes, made worse by the fact
that the check licenses step is being run on an unclean build directory
by PD. I think your suggestion to add an .sh extension for files we wish
to include would be best. But otherwise we should feel free to tailor
checklicenses.py + licensecheck.pl in the tools dir to suit our needs.
For future reference here is the diff I applied to the upstream
licensecheck.pl: --- ../licensecheck.pl 2016-08-05 20:43:04.098683796
+0100 +++ tools/licensecheck.pl 2016-08-06 20:18:20.415943059 +0100 @@
-193,8 +193,6 @@ my $default_ignore_regex = qr! my $default_check_regex
= qr! - /[\w-]+$ # executable scripts or README like file - | \.( #
search for file suffix c(c|pp|xx)? # c and c++ |h(h|pp|xx)? # header
files for c and c++ @@ -594,7 +592,7 @@ EOF sub version { print <<"EOF";
-This is $progname, from the Debian devscripts package, version
###VERSION### +This is $progname, from the Debian devscripts package,
version 2.16.2 Copyright (C) 2007, 2008 by Adam D. Barratt
; based on a script of the same name from the
KDE SDK by . @@ -657,7 +655,7 @@ sub parselicense {
$license = "GPL$gplver$extrainfo $license"; } - + if ($licensetext =~
/is distributed under the terms of the GNU General Public License,/ and
length $gplver) {
___
Sent via: Wireshark-dev mailing list mailto:d...@wireshark.org>> Archives:
https://www.wireshark.org/lists/wireshark-dev Unsubscribe:
https://wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe


___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe


___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] checklicenses.py

[João Valverde]

Let me also stress that only doc/*.pod and some airpcap files have the 
hacky soon-to-be-removed exception. These were grandfathered in. 
Everything else will still cause hard builbot failures.


On 08/06/2016 11:23 PM, João Valverde wrote:



On 08/06/2016 11:01 PM, Michael Mann wrote:

So is the "checklicense tool" now the same between the Petri-Dish and
the master buildbot?  Is that the reason the master buildbot now has to
"pass" (otherwise all Petri-Dish runs will fail)?


Yes, that's the reason.


If so, I prefer the way it used  to be - master buildbot (legitimately)
failing, but Petri-Dish being more lenient (even if it was
unintentional).


OK, but PD was never lenient. The difference is that the PD
licensecheck.pl used to match fewer files.

The intent of the original email and my efforts was to

only remove errors for files that had a legitimate reason not to have
license template.  I think "all files without an extension" is a little
too generous an exception (although I do appreciate all the work João
did) .  Guy nicely outlined the remaining issues and I don't want those
to get lost in the shuffle because the buildbot appears as if its
"passing".


The overly generous situation was the extant situation before the recent
buildbot upgrades to Ubuntu 16.04. But to eliminate is a one line change
-- see the diff I mailed.



-Original Message-
From: João Valverde 
To: Developer support list for Wireshark 
Sent: Sat, Aug 6, 2016 5:43 pm
Subject: Re: [Wireshark-dev] checklicenses.py

On 08/06/2016 10:07 PM, Guy Harris wrote: > On Aug 6, 2016, at 1:21 PM,
João Valverde mailto:joao.valve...@tecnico.ulisboa.pt>> wrote: > >> Done in
https://code.wireshark.org/review/#/c/16913/. > > Does "Removed regex to
check files without an extension." mean that we are, or aren't, checking
files without an extension? > > If it means we aren't, should we give
the few scripts that don't have an extension an extension, such as .sh
for shell scripts, so that we check them for a license? Most of our
shell scripts have a .sh extension, although that's not necessarily the
right answer for shell scripts to be run as commands. It means we aren't
checking files without an extension. I removed that match from the
Debian script as unworkable for our purposes, made worse by the fact
that the check licenses step is being run on an unclean build directory
by PD. I think your suggestion to add an .sh extension for files we wish
to include would be best. But otherwise we should feel free to tailor
checklicenses.py + licensecheck.pl in the tools dir to suit our needs.
For future reference here is the diff I applied to the upstream
licensecheck.pl: --- ../licensecheck.pl 2016-08-05 20:43:04.098683796
+0100 +++ tools/licensecheck.pl 2016-08-06 20:18:20.415943059 +0100 @@
-193,8 +193,6 @@ my $default_ignore_regex = qr! my $default_check_regex
= qr! - /[\w-]+$ # executable scripts or README like file - | \.( #
search for file suffix c(c|pp|xx)? # c and c++ |h(h|pp|xx)? # header
files for c and c++ @@ -594,7 +592,7 @@ EOF sub version { print <<"EOF";
-This is $progname, from the Debian devscripts package, version
###VERSION### +This is $progname, from the Debian devscripts package,
version 2.16.2 Copyright (C) 2007, 2008 by Adam D. Barratt
; based on a script of the same name from the
KDE SDK by . @@ -657,7 +655,7 @@ sub parselicense {
$license = "GPL$gplver$extrainfo $license"; } - + if ($licensetext =~
/is distributed under the terms of the GNU General Public License,/ and
length $gplver) {
___

Sent via: Wireshark-dev mailing list mailto:d...@wireshark.org>> Archives:
https://www.wireshark.org/lists/wireshark-dev Unsubscribe:
https://wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe


___

Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev

mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe


___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe


___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

[Wireshark-dev] Current Lua test failures on the buildbot

[Guy Harris]

Tested on an up-to-date Ubuntu 15.10 system; the test fails.  The TShark build 
information is:

TShark (Wireshark) 2.3.0 (v2.3.0rc0-230-ge32890a from master)

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

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

Compiled (64-bit) with libpcap, with POSIX capabilities (Linux), with 
libnl 3,
with GLib 2.46.2, with zlib 1.2.8, with SMI 0.4.8, with c-ares 1.10.0, 
with Lua
5.2, with GnuTLS 3.3.15, with Gcrypt 1.6.3, with MIT Kerberos, with 
GeoIP.

Running on Linux 4.2.0-42-generic, with locale en_US.UTF-8, with 
libpcap version
1.7.4, with GnuTLS 3.3.15, with Gcrypt 1.6.3, with zlib 1.2.8.
Intel(R) Core(TM) i7-4980HQ CPU @ 2.80GHz (with SSE4.2)

Built using gcc 5.2.1 20151010.

It also fails on an Ubuntu 14.10 system; the TShark build information is:

TShark (Wireshark) 2.3.0 (v2.3.0rc0-230-ge32890a from master)

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

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

Compiled (64-bit) with libpcap, without POSIX capabilities, with libnl 
3, with
GLib 2.42.1, with zlib 1.2.8, without SMI, without c-ares, with Lua 
5.2, without
GnuTLS, without Gcrypt, without Kerberos, without GeoIP.

Running on Linux 3.16.0-44-generic, with locale en_US.UTF-8, with 
libpcap
version 1.6.2, with zlib 1.2.8.
Intel(R) Core(TM) i7-4980HQ CPU @ 2.80GHz (with SSE4.2)

Built using gcc 4.9.1.

For what it's worth, the tests in question seem to be working on a "string" 
that's a byte array with byte values from 0 to 255; that's not a valid UTF-8 
string, so if the processing that's failing is assuming a UTF-8 string, its 
behavior isn't guaranteed not to change from, say, GLib release to GLib release.
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] Current Lua test failures on the buildbot

[João Valverde]

On 08/07/2016 03:47 AM, Guy Harris wrote:

Tested on an up-to-date Ubuntu 15.10 system; the test fails.  The TShark build 
information is:

TShark (Wireshark) 2.3.0 (v2.3.0rc0-230-ge32890a from master)

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

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

Compiled (64-bit) with libpcap, with POSIX capabilities (Linux), with 
libnl 3,
with GLib 2.46.2, with zlib 1.2.8, with SMI 0.4.8, with c-ares 1.10.0, 
with Lua
5.2, with GnuTLS 3.3.15, with Gcrypt 1.6.3, with MIT Kerberos, with 
GeoIP.

Running on Linux 4.2.0-42-generic, with locale en_US.UTF-8, with 
libpcap version
1.7.4, with GnuTLS 3.3.15, with Gcrypt 1.6.3, with zlib 1.2.8.
Intel(R) Core(TM) i7-4980HQ CPU @ 2.80GHz (with SSE4.2)

Built using gcc 5.2.1 20151010.

It also fails on an Ubuntu 14.10 system; the TShark build information is:

TShark (Wireshark) 2.3.0 (v2.3.0rc0-230-ge32890a from master)

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

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

Compiled (64-bit) with libpcap, without POSIX capabilities, with libnl 
3, with
GLib 2.42.1, with zlib 1.2.8, without SMI, without c-ares, with Lua 
5.2, without
GnuTLS, without Gcrypt, without Kerberos, without GeoIP.

Running on Linux 3.16.0-44-generic, with locale en_US.UTF-8, with 
libpcap
version 1.6.2, with zlib 1.2.8.
Intel(R) Core(TM) i7-4980HQ CPU @ 2.80GHz (with SSE4.2)

Built using gcc 4.9.1.

For what it's worth, the tests in question seem to be working on a "string" 
that's a byte array with byte values from 0 to 255; that's not a valid UTF-8 string, so 
if the processing that's failing is assuming a UTF-8 string, its behavior isn't 
guaranteed not to change from, say, GLib release to GLib release.


To be honest having our own GLib lrexlib bindings is a horrible idea 
(even more so for a possibly useful feature).


Brilliant piece of code but it should be merged upstream, not maintained 
in the Wireshark tree with a bus factor of 1.

___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] Current Lua test failures on the buildbot

[Guy Harris]

On Aug 6, 2016, at 7:47 PM, Guy Harris  wrote:

> It also fails on an Ubuntu 14.10 system; the TShark build information is:
> 
>   TShark (Wireshark) 2.3.0 (v2.3.0rc0-230-ge32890a from master)
> 
>   Copyright 1998-2016 Gerald Combs  and 
> contributors.
>   License GPLv2+: GNU GPL version 2 or later 
> 
>   This is free software; see the source for copying conditions. There is 
> NO
>   warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR 
> PURPOSE.
> 
>   Compiled (64-bit) with libpcap, without POSIX capabilities, with libnl 
> 3, with
>   GLib 2.42.1, with zlib 1.2.8, without SMI, without c-ares, with Lua 
> 5.2, without
>   GnuTLS, without Gcrypt, without Kerberos, without GeoIP.
> 
>   Running on Linux 3.16.0-44-generic, with locale en_US.UTF-8, with 
> libpcap
>   version 1.6.2, with zlib 1.2.8.
>   Intel(R) Core(TM) i7-4980HQ CPU @ 2.80GHz (with SSE4.2)
> 
>   Built using gcc 4.9.1.

Succeeds on Ubuntu 12.10; the TShark build information is:

TShark (Wireshark) 2.3.0 (v2.3.0rc0-231-g66711eb from master)

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

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

Compiled (64-bit) with libpcap, without POSIX capabilities, with libnl 
2, with
GLib 2.32.4, with zlib 1.2.3.4, without SMI, without c-ares, with Lua 
5.1, without
GnuTLS, without Gcrypt, without Kerberos, without GeoIP.

Running on Linux 3.2.0-101-generic, with locale en_US.UTF-8, with 
libpcap
version 1.1.1, with zlib 1.2.3.4.
Intel(R) Core(TM) i7-4980HQ CPU @ 2.80GHz (with SSE4.2)

Built using gcc 4.6.3.

Older GLib *and* older Lua; I'll see if I can try it with Lua 5.2.
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] Current Lua test failures on the buildbot

[Guy Harris]

> On Aug 6, 2016, at 8:22 PM, Guy Harris  wrote:
> 
> On Aug 6, 2016, at 7:47 PM, Guy Harris  wrote:
> 
>> It also fails on an Ubuntu 14.10 system; the TShark build information is:
>> 
>>  TShark (Wireshark) 2.3.0 (v2.3.0rc0-230-ge32890a from master)
>> 
>>  Copyright 1998-2016 Gerald Combs  and 
>> contributors.
>>  License GPLv2+: GNU GPL version 2 or later 
>> 
>>  This is free software; see the source for copying conditions. There is 
>> NO
>>  warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR 
>> PURPOSE.
>> 
>>  Compiled (64-bit) with libpcap, without POSIX capabilities, with libnl 
>> 3, with
>>  GLib 2.42.1, with zlib 1.2.8, without SMI, without c-ares, with Lua 
>> 5.2, without
>>  GnuTLS, without Gcrypt, without Kerberos, without GeoIP.
>> 
>>  Running on Linux 3.16.0-44-generic, with locale en_US.UTF-8, with 
>> libpcap
>>  version 1.6.2, with zlib 1.2.8.
>>  Intel(R) Core(TM) i7-4980HQ CPU @ 2.80GHz (with SSE4.2)
>> 
>>  Built using gcc 4.9.1.
> 
> Succeeds on Ubuntu 12.10; the TShark build information is:
> 
>   TShark (Wireshark) 2.3.0 (v2.3.0rc0-231-g66711eb from master)
> 
>   Copyright 1998-2016 Gerald Combs  and 
> contributors.
>   License GPLv2+: GNU GPL version 2 or later 
> 
>   This is free software; see the source for copying conditions. There is 
> NO
>   warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR 
> PURPOSE.
> 
>   Compiled (64-bit) with libpcap, without POSIX capabilities, with libnl 
> 2, with
>   GLib 2.32.4, with zlib 1.2.3.4, without SMI, without c-ares, with Lua 
> 5.1, without
>   GnuTLS, without Gcrypt, without Kerberos, without GeoIP.
> 
>   Running on Linux 3.2.0-101-generic, with locale en_US.UTF-8, with 
> libpcap
>   version 1.1.1, with zlib 1.2.3.4.
>   Intel(R) Core(TM) i7-4980HQ CPU @ 2.80GHz (with SSE4.2)
> 
>   Built using gcc 4.6.3.
> 
> Older GLib *and* older Lua; I'll see if I can try it with Lua 5.2.

Succeeds with Lua 5.2 as well; the TShark build information is:

TShark (Wireshark) 2.3.0 (v2.3.0rc0-231-g66711eb from master)

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

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

Compiled (64-bit) with libpcap, without POSIX capabilities, with libnl 
2, with
GLib 2.32.4, with zlib 1.2.3.4, without SMI, without c-ares, with Lua 
5.2,
without GnuTLS, without Gcrypt, without Kerberos, without GeoIP.

Running on Linux 3.2.0-101-generic, with locale en_US.UTF-8, with 
libpcap
version 1.1.1, with zlib 1.2.3.4.
Intel(R) Core(TM) i7-4980HQ CPU @ 2.80GHz (with SSE4.2)

Built using gcc 4.6.3.

So it looks as if something changed between GLib 2.32.4 and GLib 2.42.1.

___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe