Re: [Wireshark-dev] [tcpdump-workers] New RFCs for 1) pcap file format and 2) rpcapd protocol?

[Francois-Xavier Le Bail]

On 22/03/2020 18:29, Guy Harris via tcpdump-workers wrote:

> 5) Treat rpcap as "remote procedure call for libpcap" and put it under the 
> the-tcpdump-group team, and put pcap under the pcapng team as per the same 
> reason as 4).

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

Re: [Wireshark-dev] [tcpdump-workers] New RFCs for 1) pcap file format and 2) rpcapd protocol?

[Guy Harris]

On Mar 21, 2020, at 2:38 PM, Guy Harris via tcpdump-workers 
 wrote:

> On Mar 21, 2020, at 2:14 PM, Guy Harris via tcpdump-workers 
>  wrote:
> 
>> The options I see are:
> 
> 4) add a new team for rpcap, as it's a protocol rather than a file format, 
> and thus only indirectly tied to pcap/pcapng, and putting the pcap format in 
> the pcapng team because you can't have a pcap*ng* without having had a pcap 
> in the first place.

5) Treat rpcap as "remote procedure call for libpcap" and put it under the 
the-tcpdump-group team, and put pcap under the pcapng team as per the same 
reason as 4).
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] [tcpdump-workers] New RFCs for 1) pcap file format and 2) rpcapd protocol?

[Guy Harris]

On Mar 22, 2020, at 9:49 AM, Michael Tuexen  
wrote:

> I would support this. However, last time I tried this, I was not successful.
> There were not very interested in defining a file format...

They've done so in the past:

https://tools.ietf.org/html/rfc1761 (and 
https://tools.ietf.org/html/rfc3827)

and, for non-capture-file formats:

https://tools.ietf.org/html/rfc8536#section-3
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] Build failure (kerberos)

[Dario Lombardo]

Ok, thanks.

On Sun, Mar 22, 2020 at 9:48 AM Martin Mathieson <
martin.r.mathie...@googlemail.com> wrote:

>
>>> ./asn1/kerberos/packet-kerberos-template.c: In function
>>> ‘dissect_krb5_PAC_CREDENTIAL_INFO’:
>>> ./asn1/kerberos/packet-kerberos-template.c:2187:2: error: implicit
>>> declaration of function ‘decrypt_krb5_data’
>>> [-Werror=implicit-function-declaration]
>>> ./asn1/kerberos/packet-kerberos-template.c:2187:11: error: assignment
>>> makes pointer from integer without a cast [-Werror]
>>> ./asn1/kerberos/packet-kerberos-template.c: At top level:
>>> ./asn1/kerberos/kerberos.cnf:360:1: error:
>>> ‘dissect_kerberos_PA_ENC_TS_ENC’ defined but not used
>>> [-Werror=unused-function]
>>>
>>>
I don't know which part of the asn1/cnf/template generates this function.
Can anyone guide me through the asn1 dissector generation process?
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] [tcpdump-workers] New RFCs for 1) pcap file format and 2) rpcapd protocol?

[Michael Tuexen]

> On 21. Mar 2020, at 23:10, Michael Richardson  wrote:
> 
> 
> Guy Harris via tcpdump-workers  wrote:
>> Currently, on GitHub, there's a "pcapng" team:
>> https://github.com/pcapng
> 
>> with one repository containing the pcapng specification, and a 
>> "the-tcpdump-group" team:
> 
>> https://github.com/the-tcpdump-group
>> with repositories for libpcap, tcpdump, and the tcpdump.org Web site.
> 
>> It makes sense to me to keep those specifications on a site such as
>> GitHub; GitHub comes to mind first because that's where pcapng
>> currently is.
> 
>> 1) add them as repositories to the pcapng team;
> 
>> 1) has the slight disadvantage that the name for the team suggests it's
>> for pcapng only; it appears that teams can be renamed:
> 
> ...
> 
>> Were we to rename it, I don't know what would be a good new name.
> 
> I'm good with pcapng, because I also have no other suggestion.
> I would like to restart the opsawg work on an IETF specification for this.
I would support this. However, last time I tried this, I was not successful.
There were not very interested in defining a file format...
Maybe things have changed, but I don't know.


Best regards
Michael
> 
> --
> Michael Richardson , Sandelman Software Works
> -= IPv6 IoT consulting =-
> 
> 
> 
> ___
> Sent via:Wireshark-dev mailing list 
> Archives:https://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://www.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://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] [tcpdump-workers] New RFCs for 1) pcap file format and 2) rpcapd protocol?

[Michael Richardson]

Guy Harris via tcpdump-workers  wrote:
> Currently, on GitHub, there's a "pcapng" team:
> https://github.com/pcapng

> with one repository containing the pcapng specification, and a 
"the-tcpdump-group" team:

> https://github.com/the-tcpdump-group
> with repositories for libpcap, tcpdump, and the tcpdump.org Web site.

> It makes sense to me to keep those specifications on a site such as
> GitHub; GitHub comes to mind first because that's where pcapng
> currently is.

> 1) add them as repositories to the pcapng team;

> 1) has the slight disadvantage that the name for the team suggests it's
> for pcapng only; it appears that teams can be renamed:

...

> Were we to rename it, I don't know what would be a good new name.

I'm good with pcapng, because I also have no other suggestion.
I would like to restart the opsawg work on an IETF specification for this.

--
Michael Richardson , Sandelman Software Works
 -= IPv6 IoT consulting =-





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

Re: [Wireshark-dev] [tcpdump-workers] New RFCs for 1) pcap file format and 2) rpcapd protocol?

[Francois-Xavier Le Bail]

On 21/03/2020 22:14, Guy Harris via tcpdump-workers wrote:
> 1) has the slight disadvantage that the name for the team suggests it's for 
> pcapng only; it appears that teams can be renamed:
> 
>   
> https://help.github.com/en/github/setting-up-and-managing-organizations-and-teams/renaming-a-team
> 
> Were we to rename it, I don't know what would be a good new name.

Option 1) with a rename to pcapteam or pcapXteam?
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] [tcpdump-workers] New RFCs for 1) pcap file format and 2) rpcapd protocol?

[Mario Rugiero]

El sáb., 21 mar. 2020 18:15, Guy Harris via tcpdump-workers <
tcpdump-work...@lists.tcpdump.org> escribió:

> 1) has the slight disadvantage that the name for the team suggests it's
> for pcapng only; it appears that teams can be renamed:
>
>
> https://help.github.com/en/github/setting-up-and-managing-organizations-and-teams/renaming-a-team
>
> Were we to rename it, I don't know what would be a good new name.
>
I'd be careful with this option, as it may affect downstream projects, as
some download links that may be used for automated download (as part of a
build process) could break. If there's anything downloadable I wouldn't
change the team's name unless we make sure the old links remain accessible.
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] New RFCs for 1) pcap file format and 2) rpcapd protocol?

[Eliot Lear]

This very much depends on how stable you wish the spec to be.  If you
want to to be entirely osified, I recommend actual RFCs.  Otherwise,
perhaps a renamed team like "pcap-format" (or whatever the people on the
team want to call it)?

Eliot

On 21.03.20 22:15, Guy Harris wrote:
> There should probably be RFC-style specifications for 1) the pcap file format 
> and 2) the rpcapd protocol used for remote capturing.
>
> Currently, on GitHub, there's a "pcapng" team:
>
>   https://github.com/pcapng
>
> with one repository containing the pcapng specification, and a 
> "the-tcpdump-group" team:
>
>   https://github.com/the-tcpdump-group
>
> with repositories for libpcap, tcpdump, and the tcpdump.org Web site.
>
> It makes sense to me to keep those specifications on a site such as GitHub; 
> GitHub comes to mind first because that's where pcapng currently is.
>
> The options I see are:
>
>   1) add them as repositories to the pcapng team;
>
>   2) add them as repositories to the the-tcpdump-group team;
>
>   3) give them each their own teams.
>
> I see pcapng - and the pcap file format and rpcapd protocol - as not being 
> directly tied to libpcap.  *Historically*, pcap originated as the format that 
> libpcap read and wrote, and rpcap was a protocol initially implemented in the 
> WinPcap derivative of libpcap, but:
>
>   1) pcapng arose independently, and one of the earliest implementations 
> was in Wireshark (where the internal APIs were easier to change; libpcap's 
> support currently works through the existing API, but that hides a lot of the 
> capabilities of pcapng);
>
>   2) code other than libpcap code reads and writes pcap files (including, 
> but not limited to, Wireshark's code);
>
>   3) some devices either implement an rpcap server or could perhaps 
> usefully do so, and they might have reasons to have independent 
> implementations rather than basing their implementations on libpcap's rpcapd.
>
> So I'm not inclined to go with option 2) - and if we do go with option 2), 
> whatever arguments are offered for that would probably apply to pcapng as 
> well, so it would, in that case, make sense to move the pcapng repository to 
> that team as well.
>
> 1) has the slight disadvantage that the name for the team suggests it's for 
> pcapng only; it appears that teams can be renamed:
>
>   
> https://help.github.com/en/github/setting-up-and-managing-organizations-and-teams/renaming-a-team
>
> Were we to rename it, I don't know what would be a good new name.
> ___
> Sent via:Wireshark-dev mailing list 
> Archives:https://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
>  mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
>



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

Re: [Wireshark-dev] Build failure (kerberos)

[Martin Mathieson via Wireshark-dev]

Hi Dario,

KERBEROS is listed among OPTIONAL packages not found (at the end of cmake
output).  I will also attach CMakeCache.txt.

-- The following OPTIONAL packages have been found:

 * Git
 * GMODULE2
 * PCAP
 * ZLIB
 * LZ4 , LZ4 is lossless compression algorithm used in some protocol
(CQL...) , 
   LZ4 decompression in CQL and Kafka dissectors
 * LibXml2
 * SETCAP
 * XSLTPROC

-- The following REQUIRED packages have been found:

 * GLIB2 (required version >= 2.32.0)
 * GTHREAD2
 * GCRYPT (required version >= 1.4.2)
 * CARES (required version >= 1.5.0) , Library for asynchronous DNS
requests , 
   DNS name resolution for captures
 * LEX
 * YACC
 * Perl
 * PythonInterp (required version >= 3.4)
 * M
 * Qt5Core
 * Qt5LinguistTools
 * Qt5Network (required version >= 5.6.2)
 * Qt5Gui (required version >= 5.6.2)
 * Qt5Multimedia
 * Qt5PrintSupport
 * Qt5Widgets
 * POD

-- The following OPTIONAL packages have not been found:

 * Gettext
 * LIBSSH (required version >= 0.6) , Library for implementing SSH clients
, 
   extcap remote SSH interfaces (sshdump, ciscodump)
 * Systemd , System and Service Manager (libraries) , <
https://freedesktop.org/wiki/Software/systemd/>
   Support for systemd journal extcap interface (sdjournal)
 * MaxMindDB , C library for the MaxMind DB file format , <
https://github.com/maxmind/libmaxminddb>
   Support for GeoIP lookup
 * SMI
 * GNUTLS (required version >= 3.2.0)
 * KERBEROS
 * Minizip , C library for supporting zip/unzip functionality , <
https://www.winimage.com/zLibDll/minizip.html>
   Support for profiles import/export
 * BROTLI
 * SNAPPY , A fast compressor/decompressor from Google , <
https://google.github.io/snappy/>
   Snappy decompression in CQL and Kafka dissectors
 * ZSTD (required version >= 1.0.0) , A compressor/decompressor from
Facebook providing better compression than Snappy at a cost of speed , <
https://facebook.github.io/zstd/>
   Zstd decompression in Kafka dissector
 * NGHTTP2 , HTTP/2 C library and tools , 
   Header decompression in HTTP2
 * LUA (required version >= 5.1)
 * NL , Libraries for using the Netlink protocol on Linux , <
https://www.infradead.org/~tgr/libnl/>
   Support for managing wireless 802.11 interfaces
 * SBC , Bluetooth low-complexity, subband codec (SBC) decoder , <
https://git.kernel.org/pub/scm/bluetooth/sbc.git>
   Support for playing SBC codec in RTP player
 * SPANDSP , a library of many DSP functions for telephony , <
https://www.soft-switch.org>
   Support for G.722 and G.726 codecs in RTP player
 * BCG729 , G.729 decoder , <
https://www.linphone.org/technical-corner/bcg729/overview>
   Support for G.729 codec in RTP player
 * ILBC , iLBC decoder , 
   Support for iLBC codec in RTP player
 * CAP , The Libcap package implements the user-space interfaces to the
POSIX 1003.1e capabilities available in Linux kernels , <
https://sites.google.com/site/fullycapable/>
   Allow packet captures without running as root
 * DOXYGEN
 * SpeexDSP , SpeexDSP is a patent-free, Open Source/Free Software DSP
library , 
   RTP audio resampling
 * Asciidoctor (required version >= 1.5)

-- Configuring done
-- Generating done
-- Build files have been written to: /home/martin/wireshark-build

Martin



On Sat, Mar 21, 2020 at 10:59 PM Dario Lombardo  wrote:

> Hi, Martin
> There are indeed some issues with conditional compilation with kerberos.
> However I cannot reproduce this exact problem. Which  is your build
> environment?
>
> On Sat, Mar 21, 2020 at 9:41 PM Martin Mathieson via Wireshark-dev <
> wireshark-dev@wireshark.org> wrote:
>
>> I am seeing this:
>>
>> ./asn1/kerberos/packet-kerberos-template.c: In function
>> ‘dissect_krb5_PAC_CREDENTIAL_INFO’:
>> ./asn1/kerberos/packet-kerberos-template.c:2187:2: error: implicit
>> declaration of function ‘decrypt_krb5_data’
>> [-Werror=implicit-function-declaration]
>> ./asn1/kerberos/packet-kerberos-template.c:2187:11: error: assignment
>> makes pointer from integer without a cast [-Werror]
>> ./asn1/kerberos/packet-kerberos-template.c: At top level:
>> ./asn1/kerberos/kerberos.cnf:360:1: error:
>> ‘dissect_kerberos_PA_ENC_TS_ENC’ defined but not used
>> [-Werror=unused-function]
>> cc1: all warnings being treated as errors
>> epan/dissectors/CMakeFiles/dissectors.dir/build.make:35002: recipe for
>> target 'epan/dissectors/CMakeFiles/dissectors.dir/packet-kerberos.c.o'
>> failed
>>
>> The declaration/definition of decrypt_krb5_data() depends upon
>> HAVE_MIT_KERBEROS being defined, but there is no guard around calling it at
>> packet-kerberos-template.c:2187.
>>
>> Best regards,
>> Martin
>>
>> ___
>> Sent via:Wireshark-dev mailing list 
>> Archives:https://www.wireshark.org/lists/wireshark-dev
>> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
>>