[tcpdump-workers] snprintf in libpcap

[Michael Richardson via tcpdump-workers]

--- Begin Message ---
Back in 2016, we note in the CHANGES:
Replace sprintf() with pcap_snprintf().

but, we have no prototype for this, and apparently no definition, and we use
snprintf() everywhere.  I'm trying to merge Ray's changes which are rebased
into pull request #914.

I think that we just use "snprintf()" now.

--
]   Never tell me the odds! | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works|IoT architect   [
] m...@sandelman.ca  http://www.sandelman.ca/|   ruby on rails[



--- End Message ---
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers

Re: [tcpdump-workers] [the-tcpdump-group/libpcap] Use tab instead of space in formatting pcap-int.h (#918)

[Michael Richardson via tcpdump-workers]

--- Begin Message ---
Guy Harris  wrote:
>> I thought we wanted all spaces?

> If we do, we should replace all the tabs in pcap-int.h with spaces; we
> should at least be consistent, and change #918 fixed one inconsistent
> case.

Let's agree that we are going towards spaces.
I think most files are using 8-space indents, a la Linux Kernel.

I'm not fond of forcing people to omit {} when there is a single line, but I
can live with it.

> Spaces have the advantage that they don't get misinterpreted by editors
> that think tabs occur every 4 spaces rather than the UN*X standard of 8
> spaces.  Wireshark's been moving in that direction to some extent.

Agreed.

>> I propose to put emacs and vim definitions into every file.

> "Definitions" as in "modelines"?  Sounds reaonsable - Wireshark haz
> them in most if not all files, and even has a Web page to generate
> them:

> https://www.wireshark.org/tools/modelines.html

good.
I will submit a whitespace change to master next week, and then a modeline fix.
Are there any integrations to github that will warn people to fix their
whitespace settings?

--
]   Never tell me the odds! | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works|IoT architect   [
] m...@sandelman.ca  http://www.sandelman.ca/|   ruby on rails[

--- End Message ---
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers

Re: [tcpdump-workers] [the-tcpdump-group/libpcap] Use tab instead of space in formatting pcap-int.h (#918)

[Michael Richardson via tcpdump-workers]

--- Begin Message ---
Francois-Xavier Le Bail  wrote:
>> > If we do, we should replace all the tabs in pcap-int.h with spaces; we
>> > should at least be consistent, and change #918 fixed one inconsistent
>> > case.
>>
>> Let's agree that we are going towards spaces.
>> I think most files are using 8-space indents, a la Linux Kernel.

> Where is the beginning of this discussion ?

In a github ticket, #918.

--- End Message ---
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers

Re: [tcpdump-workers] [the-tcpdump-group/libpcap] Use tab instead of space in formatting pcap-int.h (#918)

[Michael Richardson via tcpdump-workers]

--- Begin Message ---
Francois-Xavier Le Bail via tcpdump-workers wrote:
>> In a github ticket, #918.

> I don't see the message starting this conversation in #918, nor the
> following ones. Could you push
> them in the list?

#918 fixes a space->tab, I think.
I took it directly to the list to ask if this was right.
You didn't miss anything.

--
]   Never tell me the odds! | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works|IoT architect   [
] m...@sandelman.ca  http://www.sandelman.ca/|   ruby on rails[

--- End Message ---
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers

Re: [tcpdump-workers] [pcap-ng-format] "Custom" link-layer types for pcap and pcapng

[Michael Richardson via tcpdump-workers]

--- Begin Message ---
Guy Harris  wrote:
> A link-layer type value of 0x will be reserved as LINKTYPE_CUSTOM,
> with libpcap offering a DLT_CUSTOM.

sounds good.

> A custom link-layer type has a 32-bit IANA-registered Private Enterprise 
Number (PEN):

> https://en.wikipedia.org/wiki/Private_Enterprise_Number

That works, since many already have PENs, and for middle sized and small
entities, they will know what it is, and who controls it.  For larger
entities, this will sadly be meaningless.

I think that this is a really good internal-only format.

> We could either 1) also say it should have a 32-bit per-vendor
> link-layer type number or 2) say that if the vendor plans to use it for
> more than one type of link-layer header, they have to arrange that the
> link-layer header should begin with information necessary to determine
> what the *rest* of the link-layer header is.

At first blush, I prefer to let the vendor figure it out...

> every non-custom block includes a block type, and every non-custom
> option has an option type, but not every *block* in a capture file has
> a link-layer header type - a pcap header has a link-layer type that
> applies to all packets in the file and a pcapng IDB has a link-layer
> type that applies to all packets on that interface;

> knowing the link-layer type up front makes it easier to generate BPF
> filter code for an interface, if we support these types for live
> capture (or if the vendor's private capture mechanism supports it);

yeah...

> so I'm inclined to go with 1).

okay, so how would we be able to generate code for an encapsulation that we
don't know about?

> In that model:

> in pcap files, if the lower 16 bits of the 32-bit link-layer type value
> is 0x, the two "Reserved" fields (which were formerly a
> rarely-if-ever-used and not-supported-by-libpcap-or-Wireshark time zone
> offset and time stamp resolution) MUST contain the PEN and
> vendor-specific link-layer type;

not a big fan of this, but okay.

> in pcapng file, if the link-layer type in an IDB is 0x, the IDB
> *MUST* contain a new option, containing the PEN and vendor-specific
> link-layer type.

good.

> Given that it's for *two* capture file formats, these lists are
> probably better places for discussion than having two pull requests and
> discussing them in comments there.

--
]   Never tell me the odds! | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works|IoT architect   [
] m...@sandelman.ca  http://www.sandelman.ca/|   ruby on rails[

--- End Message ---
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers

Re: [tcpdump-workers] tcpslice licence

[Michael Richardson via tcpdump-workers]

--- Begin Message ---
Denis Ovsienko via tcpdump-workers  wrote:
> [...]
>> The first step I'd take would be to get rid of the GPLed headers in
>> favor of BSD-licensed headers, e.g. taking the ip.h, tcp.h, and udp.h
>> headers from tcpdump and changing the code to work with them.
> [...]

> I have prepared changes that include headers from /usr/include/netinet
> instead and am going to commit it tomorrow after proof-reading and
> confirming it builds on different systems.

This is awesome work.  Thank you.

--- End Message ---
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers

Re: [tcpdump-workers] CVE-2020-8037: memory allocation in ppp decapsulator

[Michael Richardson via tcpdump-workers]

--- Begin Message ---
Hi, CVE-2020-8037 causes a big amount of memory to be allocated (then freed),
it does not cause an attack.

I'm sorry that I haven't managed to succeed in doing the right CVE.json dance
to get the mitre data updated.

Bill Fenner via tcpdump-workers  wrote:
> I realize that http://www.tcpdump.org/security.html says there is no
> commitment from the tcpdump group to release security fixes on any
> timeframe whatsoever.  However, is there a way for someone who ships
> tcpdump with their product to be made aware of unreleased security
> fixes, or should we rely on Red Hat and others for that?

I can strive to do better.
I think that you are on the security@ list, and I think that this did go
through that list at the time.

--
]   Never tell me the odds! | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works|IoT architect   [
] m...@sandelman.ca  http://www.sandelman.ca/|   ruby on rails[

--- End Message ---
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers

[tcpdump-workers] sorry for all the testing

[Michael Richardson via tcpdump-workers]

--- Begin Message ---
Simple tests like:
  echo "testing 1.2.3." | Mail -s "testing 1.2.3" 
tcpdump-workers@lists.tcpdump.org

are working, but complex emails are not.

--- End Message ---
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers

[tcpdump-workers] pcap_open_offline_... and options and the like

[Michael Richardson via tcpdump-workers]

--- Begin Message ---
trying without GPG signature

{Hi, my email never made it through the list earlier.
Francois' email went through earlier today, so I am at a loss
as to what has happened.  And other lists worked.  I thought mailman was
stuck, but I dunno.  I backed up the list configuration, and list names, and
remade the list, and then I found other postfix vs mailman issues that seemed
to affect only lists hosted at lists.tcpdump.org.  Moving on, I hope}


We have:
   pcap_t *
   pcap_open_offline_with_tstamp_precision(const char *fname, u_int precision,
char *errbuf)

and:
  pcap_t *
  pcap_open_offline(const char *fname, char *errbuf)

and then we have:
 #ifdef _WIN32
  pcap_t* pcap_hopen_offline_with_tstamp_precision(intptr_t osfd, u_int 
precision,
  char *errbuf)

And we have a pull request
https://github.com/the-tcpdump-group/libpcap/pull/982 that I just rebased
that adds a "hidden" option.
Code originally from Ray Bellis, and a lot of the root DNS operators want this.
Note that this loads a .so file to do the work.
  Examples are at:
https://github.com/DNS-OARC/dnscap/blob/develop/src/dumper.c
https://github.com/raybellis/libpcap-gzip

Ray went in that direction when we complained that distros might not want an
additional dependancy upon -lz or something else.

  { So I come to believe that I erred here: the dependancy upon -lz might have
been better than this.  But.}

The pcap_open_offline() patched starts with:
const pcap_ioplugin_t *plugin = 
pcap_ioplugin_init(getenv("PCAP_IOPLUGIN_READ"));

And I really don't want to do it this way with the environment variable.
(Convince me otherwise)

I really think that changing behaviour of programs via environment variables
is a recipe for security holes.   I would much happier if this was a --option
for tcpdump, and if anyone wants to pull it from an an environment variable
that they put that into the application rather than the library.

So I would prefer if the code instead did some new pcap_open_offline_with..(new 
argument).
Something that we could expand without continuing to make new functions!

For many things, the best situation is if we can do a pcap_set_XXX().
For timestamps, we didn't do that, because we need the precision in order to
help validate the pcap header.  Perhaps we could have done this another way.

For live captures, we have the sequence pcap_create/pcap_activate split,
and perhaps there is a way that we can make use of the same kind of flow.
(Note that the pcap(3) page is vague as to what things can be between
pcap_create() and pcap_activate)

Options that I see are:
  1) do nothing for input, we can solve this later.
 The major win is on output, and just create pcap_dump_compressed_open()
 for now.

  2) rework input and output so that a pcap_t */pcap_dumper_t * could be
 returned, uninitialized, accept some set_options, and then be activated.

  3) more extensive rework so that pcap_create() could create handle for
 live and offline captures, and that specifying the capture type was
 just another set.

These are not mutually exclusive.

--
]   Never tell me the odds! | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works|IoT architect   [
] m...@sandelman.ca  http://www.sandelman.ca/|   ruby on rails[
--- End Message ---
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers

Re: [tcpdump-workers] pcap_open_offline_... and options and the like

[Michael Richardson via tcpdump-workers]

--- Begin Message ---
Michael Richardson via tcpdump-workers wrote:
> trying without GPG signature

YUP. That's it.  So mailman2 will have to get replaced finally.
It eats emails with signature attachments, I think.  This is new.

After a few hours thinking about my previous email I wanted to reply about my
current thinking, and then was surprised not to see my email having got
through.

The distro on my list machine doesn't have mailman3, so maybe it is getting
upgraded too!.

In https://github.com/the-tcpdump-group/libpcap/pull/983
Guy asked:

guy> "Would affect" as in "those would be changed in separate commits"?

guy> This is similar to some stuff I've been thinking about, based on
guy> some long-ago requests for device-specific options.

guy> The stuff I've been working on gave a name and description for
guy> each option; the name is for use on the command line, e.g. with a
guy> --capture-option flag, e.g. --capture-option channel=XXX, and the
guy> description would be for use in 1) GUI applications such as Wireshark
guy> and 2) a --show-capture-options flag that would give a list, for a given
guy> device, of the available options, giving the name and the description.

guy> Presumably:

guy> this would affect pcap_init() by having a set of global pcap options to
guy> apply (in an argument to pcap_init()?;

guy> this would affect 'pcap_activate()by having a per-device list of
guy> options, with calls to set the options being made afterpcap_create()and
guy> beforepcap_activate()`;

guy> this would affect pcap_open_offline() by having something such as a
guy> pcap_open_offline_with_options() call that takes a list of options as an
guy> argument;

guy> this would affect pcap_dump_open*() by having similar
guy> pcap_dump_open*_with_options() routines.
guy> There would presumably be calls to indicate which options are available 
for a particular context.

To which I replied:

> The stuff I've been working on gave a name and description for each option;
> the name is for use on the command line, e.g. with a --capture-option flag,
> e.g. --capture-option channel=XXX, and the description would be for use in
> 1) GUI applications such as Wireshark and 2) a --show-capture-options flag
> that would give a list, for a given device, of the available options,
> giving the name and the description.

I think that it could support such use case with some additional calls.
There is perhaps a chicken and egg issue with not knowing which options apply
until a device has been selected.
But at least, compile time options in libpcap would become apparent.

> There would presumably be calls to indicate which options are available for a 
> particular context.

yes, I think so.
See what I roughed out in this pull request, which is the minimum I think I
need to do the ioplugin.
Strings and integers and an ENUM. Maybe we want to have a call to find out if
an enum is valid (i.e. not #ifdef out).

--
]   Never tell me the odds! | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works|IoT architect   [
] m...@sandelman.ca  http://www.sandelman.ca/|   ruby on rails[


--- End Message ---
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers

[tcpdump-workers] man pages... what's cool now? (fwd) Michael Richardson: man pages... what's cool now?

[Michael Richardson via tcpdump-workers]

--- Begin Message ---

I forgot not to PGP sign.

--- End Message ---
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers

[tcpdump-workers] draft-gharris-opsawg-pcap.txt --- FCS length description

[Michael Richardson via tcpdump-workers]

--- Begin Message ---

{resend due to problems with PGP signatures vs mailman}

Hi, I have reworked the document that Guy put into XML describing the *PCAP*
(not NG) format.   I found the text for LinkType to be confusing, and
frankly, I think wrong.

   *  LinkType (32 bits): an unsigned value that defines, in the lower
  16 bits, the link layer type of packets in the file, and
  optionally indicates the length of the Frame Check Sequence (FCS)
  of packets in the upper 16 bits.  The list of Standardized Link
  Layer Type codes is available in [LINKTYPES].  If bit 5 is set,
  bits 0 through 3 contain the length of the FCS field at the end of
  all packets; if bit 5 is not set, the length of the FCS field at
  the end of all packets is unknown.  Bit 4, and bits 6 through 15,
  SHOULD be filled with 0 by pcap file writers, and MUST be ignored
  by pcap file readers.

The numbering is driven by how the IETF likes to number bits, which has
always been a bit bizarre.

You can see the document at:
https://datatracker.ietf.org/doc/draft-gharris-opsawg-pcap/
and from the links at:
https://github.com/pcapng/pcapng
which are fixed and updated thanks to circleci actions, I hope.

Looking at libpcap's pcap/pcap.h:
   https://github.com/the-tcpdump-group/libpcap/blob/master/pcap/pcap.h#L217

we see:
/*
 * Macros for the value returned by pcap_datalink_ext().
 *
 * If LT_FCS_LENGTH_PRESENT(x) is true, the LT_FCS_LENGTH(x) macro
 * gives the FCS length of packets in the capture.
 */
#define LT_FCS_LENGTH_PRESENT(x)((x) & 0x0400)
#define LT_FCS_LENGTH(x)(((x) & 0xF000) >> 28)
#define LT_FCS_DATALINK_EXT(x)  x) & 0xF) << 28) | 0x0400)

this suggests that the FCS length is really only 3 bits (maximum FCS size of
7 bytes?  Or does 0 indicate 8 bytes?  Ethernet is 4...).

I see, however:
   pcap-dag.c:
p->linktype_ext = LT_FCS_DATALINK_EXT(pd->dag_fcs_bits/16);

I can find no other references.  So I guess Ethernet gets a value of 2 (*16 
bits).
I can't find any other uses.
pcap_datalink_ext() is in pcap.c, but no the man page.

The code does not ignore bits 28:16 of the linktype field (the bits numbered
6:15 in the diagram).
Since we are nowhere close to 64K link types, from looking at the pcap
document only, we could make it 28-bits:
 BUT: pcapng has a 16-bit LinkType only, so we really need to limit 
this to
 16-bits OOPS.  I'll fix this in -01.

What I'm looking for in this email is:
1) confirmation that Linktype is 16-bits.
2) some explanation of valid FCS values. Seems to be a multiple of 16-bits.
   Is 0 valid?  Or would that be indicated by LENGTH_PRESENT(x)==0?
   Or is 0 ==> 8 * 16-bits => 128 bits of FCS.

I'm going to propose IANA considerations in a followup email and in -01.

--
Michael Richardson. o O ( IPv6 IøT consulting )
   Sandelman Software Works Inc, Ottawa and Worldwide




--
Michael Richardson. o O ( IPv6 IøT consulting )
   Sandelman Software Works Inc, Ottawa and Worldwide




--- End Message ---
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers

[tcpdump-workers] draft-gharris-opsawg-pcap.txt --- IANA considerations

[Michael Richardson via tcpdump-workers]

--- Begin Message ---

The short of it is:

1) reserve bits 16:28 of linktype as zero.
2) lower 32K Specification Required (any document),
   upper 32K First Come First Served

Details:
  The Registry has three sections according to {{RFC8126}}:
  * values from 0 to 32767 are marked as Specification Required.
  *   except that values 147 to 162 are reserved for Private Use
  * values from 32768 to 65000 are marked as First-Come First-Served.
  * values from 65000 to 65536 are marked as Private Use.

3) I have included the tcpdump.org linktype database that we maintain.
   It might be a week old, but I don't think we've allocated anything
   in the past month.
   It is at: http://www.tcpdump.org/linktypes.html
   Some entries have further links under /linktypes/... which we could
   enter as the correct reference.
   There are 112 entries.
   It may be that we should do something different for initializing IANA.

I did some editing of the description field to shorten in a lot, but I got
tired about 30% through the list, not sure if we should even include that
column.
There are many entries like:
   LINKTYPE_PPP_ETHER  |   51   |PPPoE; per RFC 2516

where I think that maybe this should point directly at RFC2516.
I'm not entirely sure about this.

Where this gets more complex is:
   LINKTYPE_PPP_WITH_DIR204 DLT_PPP_WITH_DIRPPP, as per
   RFC 1661 and RFC 1662, preceded with a one-byte pseudo-header with a zero
   value meaning "received by this host" and a non-zero value meaning "sent
   by this host"; if the first 2 bytes are 0xff and 0x03, it's PPP in
   HDLC-like framing, with the PPP header following those two bytes,
   otherwise it's PPP without framing, and the packet begins with the PPP
   header. The data in the frame is not octet-stuffed or bit-stuffed.

in this case, the text in linktypes.html is probably most appropriate.


Name:   draft-gharris-opsawg-pcap
Revision:   01
Title:  PCAP Capture File Format
Document date:  2020-12-22
Group:  Individual Submission
Pages:  29
URL:https://www.ietf.org/archive/id/draft-gharris-opsawg-pcap-01.txt
Status: https://datatracker.ietf.org/doc/draft-gharris-opsawg-pcap/
Html:   
https://www.ietf.org/archive/id/draft-gharris-opsawg-pcap-01.html
Htmlized:   https://tools.ietf.org/html/draft-gharris-opsawg-pcap-01
Diff:   https://www.ietf.org/rfcdiff?url2=draft-gharris-opsawg-pcap-01


--
Michael Richardson. o O ( IPv6 IøT consulting )
   Sandelman Software Works Inc, Ottawa and Worldwide




--- End Message ---
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers

Re: [tcpdump-workers] [OPSAWG] draft-gharris-opsawg-pcap.txt --- FCS length description

[Michael Richardson via tcpdump-workers]

--- Begin Message ---
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512


Carsten Bormann  wrote:
> On 2020-12-22, at 01:31, Michael Richardson  wrote:
>>
>> #define LT_FCS_LENGTH(x) (((x) & 0xF000) >> 28)
>> #define LT_FCS_DATALINK_EXT(x)   x) & 0xF) << 28) | 
0x0400)
>>
>> this suggests that the FCS length is really only 3 bits

> 4 bits, really (assuming 32-bit unsigned integers).

The LT_FCS_LENGTH(x) (bit 28) is treated as a flag to say that the thing is 
there.
The DATALINK_EXT(x) might be borked here, only accepting odd values, which
would really be a problem.  I suspect there are bugs here.

- --
Michael Richardson. o O ( IPv6 IøT consulting )
   Sandelman Software Works Inc, Ottawa and Worldwide




-BEGIN PGP SIGNATURE-

iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl/hcmwACgkQgItw+93Q
3WWUmQf/cGNrWzIqKeCjf8u76FPPEDckcL9/6EObSfKkiQ+qvdjqcG5FQnBngHmO
Wpj9sodteZaqsWtRvz3KckChk94WGPZ/1QcoCNo31Lpa5sYsDI0NYBPjD8NNsOLg
z4IINSHjhY4jVxVJuvDDf31e1vAnlKze8uFCnPZ954V6p3k1pV6xcAYtOvXWThKt
XKu0MwXX2GkXoHabpmYJesVL1s1LZDKZ4R8reAzbx+DFyDyM/0qYYprrjOUO6xGd
FkaQaJ37D08TTZ9sjrpJ9xKruPysTYc7QluXgtCuAGtvqeU56wAaWVPJxhzNK4N3
mrApAK/q4NBEjyTP0A/BYD4HcRDW4Q==
=pfBZ
-END PGP SIGNATURE-
--- End Message ---
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers

Re: [tcpdump-workers] [OPSAWG] [pcap-ng-format] draft-gharris-opsawg-pcap.txt --- IANA considerations

[Michael Richardson via tcpdump-workers]

--- Begin Message ---

<#secure method=pgp mode=sign>

Guy Harris  wrote:
>> The short of it is:
>>
>> 1) reserve bits 16:28 of linktype as zero.

> In pcap files, presumably; you have only bits 0:15 in pcapng IDBs.

Yes.  That's why I changed the illustration of the packet so that only 16
bits were in the LinkType.

> Note that the registry is for both pcap and pcapng, so the specs should 
say that.

>> 2) lower 32K Specification Required (any document),
>> upper 32K First Come First Served
>>
>> Details:
>> The Registry has three sections according to {{RFC8126}}:
>> * values from 0 to 32767 are marked as Specification Required.
>> *   except that values 147 to 162 are reserved for Private Use
>> * values from 32768 to 65000 are marked as First-Come First-Served.
>> * values from 65000 to 65536 are marked as Private Use.

> Presumably "to 65535" - 65536 doesn't fit in the 16-bit pcapng field.

Oops.

> So, for FCFS, does that mean anybody who wants a linktype can just grab 
one?

Yes, but it's not quite the free-for-all one might imagine.
They have to email IANA and there are some records kept.
IANA does do some amount of abuse control.

I've re-read RFC8726, in case we want to send pcap via the ISE, as OPSAWG is
very slow to adopt documents.   The short of it is that we *CAN* create
Registries on the Independent Stream Editor Q.
  https://www.rfc-editor.org/about/independent/

But, we can not create Specification Required registries as that requires
assignment of Designated Experts.  FCFS streams are fine.
Options are there:
  1) get OPSAWG to adopt this document.
  2) ask an AD to sponsor the document.
  3) not split the Registry as per above, use FCFS for it all.
  4) move the LinkType Registry to pcapng, send pcap via ISE as
 Informational (might get hung up waiting for pcapng, however, depending
 upon how we write the text, and whether or not it results in a MISREF)

I have no particular preference.


> And, as per my idea of using 65535 to mean "custom linktype", similar
> to pcapng custom blocks and options, with either:

I'm happy with this proposal, but isn't it pcapng specific?
We can reserve 65535 itself for that use.


>> I did some editing of the description field to shorten in a lot, but I 
got
>> tired about 30% through the list, not sure if we should even include that
>> column.
>> There are many entries like:
>> LINKTYPE_PPP_ETHER  |   51   |PPPoE; per RFC 2516

> That one's there for NetBSD; I *think* the packet contains just a PPPoE
> header and payload.  I may have to dig into the NetBSD code to see what
> they do.

okay, but we don't have to get that perfect in the document.
What matters is that it points to /linktypes.html in the IANA registry.


--
Michael Richardson. o O ( IPv6 IøT consulting )
   Sandelman Software Works Inc, Ottawa and Worldwide




--- End Message ---
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers

Re: [tcpdump-workers] [OPSAWG] [pcap-ng-format] draft-gharris-opsawg-pcap.txt --- FCS length description

[Michael Richardson via tcpdump-workers]

--- Begin Message ---

<#secure method=pgp mode=sign>

Guy Harris  wrote:
> a 6-bit "extension" field, storing information about the
> capture, such an indication of whether the packets include an
> FCS and, if so, how many bytes of FCS are present.

> So what NetBSD had was a convention where a capture file could have a
> link-layer type that combined an AF_ value with some additional bits to
> distinguish the value from a regular LINKTYPE_ value; I don't know what
> AF_ values they supported for that, or where that code was, or whether
> it's still supported.

Wow, lots of ill-defined complexity here.

I think that we should just regard this as water under the bridge.
If NetBSD wants to propose a use for those empty bits, then a new
specification could update that use case.

--
Michael Richardson. o O ( IPv6 IøT consulting )
   Sandelman Software Works Inc, Ottawa and Worldwide
--- End Message ---
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers

Re: [tcpdump-workers] [OPSAWG] [pcap-ng-format] draft-gharris-opsawg-pcap.txt --- IANA considerations

[Michael Richardson via tcpdump-workers]

--- Begin Message ---

 wrote:
>> -Message d'origine-
>> De : OPSAWG [mailto:opsawg-boun...@ietf.org] De la part de Michael
>> Richardson
>> Envoyé : mardi 22 décembre 2020 17:36
>> À : Guy Harris 
>> Cc : Pcap-ng file format ;
>> ops...@ietf.org; tcpdump-workers 
>> Objet : Re: [OPSAWG] [pcap-ng-format] draft-gharris-opsawg-pcap.txt
>> --- IANA considerations
>>
>> But, we can not create Specification Required registries as that
>> requires assignment of Designated Experts.

> [Med] I'm not sure if the rules changed since then, but experts can be
> designated for registries created by ISE documents. See for example:
> 
https://www.iana.org/assignments/iax-parameters/iax-parameters.xhtml#iax-parameters-7

Well, this document is ten years ago, and RFC8726 is Nov. 2020, and I think
that the confusion on this question is what generated the need for RFC8726.

Adrian: wrt:
  https://mailarchive.ietf.org/arch/msg/opsawg/m4I4vMrYyAxhv18k3LcUk-_Te94/

--
Michael Richardson. o O ( IPv6 IøT consulting )
   Sandelman Software Works Inc, Ottawa and Worldwide
--- End Message ---
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers

Re: [tcpdump-workers] Any way to filter ether address when type is LINUX_SLL?

[Michael Richardson via tcpdump-workers]

--- Begin Message ---
Bill Fenner via tcpdump-workers  wrote:
> It would be perfectly reasonable (and fairly straightforward) to update
> libpcap to be able to filter on the Ethernet address in DLT_LINUX_SLL
> or DLT_LINUX_SLL2 mode.  There are already filters that match other
> offsets in the SLL or SLL2 header.  However, I don't think it could be
> done on live captures, only against a savefile.

Yes, I agree.
--- End Message ---
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers

[tcpdump-workers] bpf.tcpdump.org updates

[Michael Richardson via tcpdump-workers]

--- Begin Message ---
bpf.tcpdump.org is being updated from devuan ascii (2.0) to devuan beowolf 
(3.1).
(Equvialent to Debian buster).

I've doing this to upgrade git to the version that supports --mirror, which is
not the right thing for the local repositories.
(I was, you know, reading the man page...)

Are we using buildbot? I don't think so.

and the list is eating my emails if they are signed.


--- End Message ---
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers

Re: [tcpdump-workers] bpf.tcpdump.org updates

[Michael Richardson via tcpdump-workers]

--- Begin Message ---
Michael Richardson via tcpdump-workers wrote:
> bpf.tcpdump.org is being updated from devuan ascii (2.0) to devuan
> beowolf (3.1).  (Equvialent to Debian buster).

> I've doing this to upgrade git to the version that supports --mirror,
> which is not the right thing for the local repositories.  (I was, you
> know, reading the man page...)

which is *now* the right thing...

--- End Message ---
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers

Re: [tcpdump-workers] Any way to filter ether address when type is LINUX_SLL?

[Michael Richardson via tcpdump-workers]

--- Begin Message ---
Guy Harris via tcpdump-workers  wrote:
> I've been thinking about a world in which we have more pcapng-style
> APIs.  With a capture API that can deliver, for each packet, something
> similar to a pcapng Enhanced Packet Block, with an interface number
> from the capturing program can determine a link-layer header type, so
> that not all captured packet have to have the same link-layer header
> type, it might be possible to generate a filter program that:

I like this as an idea for an API.

>   could use one of the SKF_ magic offsets to fetch the "next protocol
> type" value for the protocol after the link-layer protocol, so
> link-layer-type-independent code could be used to check for common
> "next protocol type" values such as IPv4, IPv6, and ARP;

>   could use one of the SKF_ magic offsets to fetch the offset, relative
> to the beginning of the raw packet data, of the first byte past the
> link-layer header, so that link-layer-type-independent code could be
> used to check for anything at the next protocol layer (IP address,
> etc.);

That would be very nice.
The kernel already has done all the L2 processing, might as well leverage it.

>   could use one of the SKF_ magic offsets to fetch the ARPHRD_ type
> giving the link-layer header type, and, based on that run different
> code to check fields in the link-layer header.

> This would be done by using a raw socket (PF_PACKET/SOCK_RAW) rather
> than a cooked socket.

> With all of that, we could do live-capture filtering of MAC addresses
> (source *or* destination).

Cool.
--- End Message ---
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers

Re: [tcpdump-workers] libpcap detection and linking in tcpdump

[Michael Richardson via tcpdump-workers]

--- Begin Message ---
Guy Harris via tcpdump-workers  wrote:
>> $ /tmp/libpcap/bin/pcap-config --libs -L/tmp/libpcap/lib
>> -Wl,-rpath,/tmp/libpcap/lib -lpcap

> So that *should* cause /tmp/libpcap/lib to be added to the executable's
> path, which *should* cause it to look in /tmp/libpcap/lib for shared
> libraries.

I have never seen this work since the move from SunOS-style
shared-library/AOUT to ELF twenty years ago.
-R/tmp/libpcap/lib is what I used to do, but AFAIK, this is equally a no-op.

> I'll try experimenting with one of my Ubuntu VMs.

> In the meantime, for some fun head-exploding reading, take a look at
>   https://en.wikipedia.org/wiki/Rpath
> and perhaps some other documents found by a search for

Yeah... I don't even know what to say.

--
]   Never tell me the odds! | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works|IoT architect   [
] m...@sandelman.ca  http://www.sandelman.ca/|   ruby on rails[


--- End Message ---
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers

Re: [tcpdump-workers] libpcap detection and linking in tcpdump

[Michael Richardson via tcpdump-workers]

--- Begin Message ---
Guy Harris via tcpdump-workers  wrote:
> (The existence of libtool is an indication that shared libraries have
> gotten messy on UN*X.)

> Perhaps for this particular case the right thing to do is to set
> LD_LIBRARY_PATH when running the temporarily-installed tcpdump.

Effectively, this is what libtool tries to do.
I would rather just be explicit about it somehow.

Maybe that goes into how we use "make check", but I'm not sure where else it 
matters.

--
]   Never tell me the odds! | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works|IoT architect   [
] m...@sandelman.ca  http://www.sandelman.ca/|   ruby on rails[

--- End Message ---
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers

Re: [tcpdump-workers] Request to add MCTP and PCI_DOE to PCAP link type

[Michael Richardson via tcpdump-workers]

--- Begin Message ---
Yao, Jiewen via tcpdump-workers  wrote:
> Hello Any response ?

> Thank you Yao Jiewen

...
Hi, sorry abotu that.

> Hi I write this email to request to below 2 link types.


>   1.  MCTP

> Management Component Transport Protocol (MCTP) is an industry standard
> defined by Distributed Management Task Force (DMTF) Platform Management
> Communication Interface (PMCI) working group
> (https://www.dmtf.org/standards/pmci)

> DSP0236
> 
(https://www.dmtf.org/sites/default/files/standards/documents/DSP0236_1.3.1.pdf)
> is the Management Component Transport Protocol (MCTP) Base
> Specification. It defines the MCTP transport header.  DSP0239
> 
(https://www.dmtf.org/sites/default/files/standards/documents/DSP0239_1.7.0.pdf)
> defines the Management Component Transport Protocol (MCTP) IDs and
> Codes. It defines the MCTP message type in a MCTP packet payload.

> Proposal:

> LINKTYPE_ name LINKTYPE_ value Corresponding DLT_ name Description
> LINKTYPE_MCTP XXX DLT_MCTP MCTP packet is defined in DMTF PMCI working
> group Management Component Transport Protocol (MCTP) Base
> 
Specification(https://www.dmtf.org/sites/default/files/standards/documents/DSP0236_1.3.1.pdf)
> 8.1 MCTP packet fields. It starts with MCTP transport header in Figure
> 4 - Generic message fields.

These descriptions look great.
Why not follow 
https://github.com/the-tcpdump-group/libpcap/blob/master/doc/DLT_ALLOCATE_HOWTO.md
and send a pull request?

>   1.  PCI_DOE

> PCI Data Object Exchange (DOE) is an industry standard defined by
> PCI-SIG (https://pcisig.com/) Data Object Exchange (DOE)
> ECN
> (https://members.pcisig.com/wg/PCI-SIG/document/14143).

This link is behind some kind of paywall.
Maybe there is a public definition we can refer to?

> Proposal:

> LINKTYPE_ name LINKTYPE_ value Corresponding DLT_ name Description
> LINKTYPE_PCI_DOE XXX DLT_PCI_DOE PCI Data Object Exchange (DOE) is
> defined in PCI-SIG Data Object Exchange (DOE) ECN
> (https://members.pcisig.com/wg/PCI-SIG/document/14143) 6.xx.1 Data
> Objects. It starts with DOE Data Object Header 1 in Figure 6-x1: DOE
> Data Object Format.



> The reason I submit this request is because we are implementing a
> "SpdmDump" tool to dump the SPDM message defined in DMTF PMCI Security
> Protocol and Data Model (SPDM) Specification DSP0274
> 
(https://www.dmtf.org/sites/default/files/standards/documents/DSP0274_1.1.0.pdf).
> SPDM is similar to network Transport Layer Security (TLS) protocol. It
> is a transport layer protocol.  The MCTP and the PCI_DOE are the
> transport layer binding to send message to hardware device (MCTP
> capable device or PCI_DOE capable device).

> We did a prototype for the SpdmDump tool
> (https://github.com/jyao1/openspdm/blob/master/Doc/SpdmDump.md). We can
> generate a PCAP file and parse it offline.  In our prototype, we use
> below definition: #define LINKTYPE_MCTP 290 // 0x0122 #define
> LINKTYPE_PCI_DOE 291 // 0x0123 If you can assign same number, it will
> be great.  If different number is assigned, we will change our
> implementation accordingly.

> Thank you Yao Jiewen



> ___ tcpdump-workers mailing
> list tcpdump-workers@lists.tcpdump.org
> https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers

--- End Message ---
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers

Re: [tcpdump-workers] Request to add MCTP and PCI_DOE to PCAP link type

[Michael Richardson via tcpdump-workers]

--- Begin Message ---
Yao, Jiewen  wrote:
> Thank you.  I will file a Pull-Request.

> The DOE header definition can be found
> 
https://github.com/jyao1/openspdm/blob/master/Include/IndustryStandard/PciDoeBinding.h
> It starts from PCI_DOE_DATA_OBJECT_HEADER.

That sounds like enough of a definition to me.

--- End Message ---
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers

Re: [tcpdump-workers] Stick with Travis for continuous integration, or switch?

[Michael Richardson via tcpdump-workers]

--- Begin Message ---
Denis Ovsienko via tcpdump-workers  wrote:
> My last commit to libpcap had waited in the queue for 2 days to get
> tested. Obviously, the old free service is in the process of
> disappearing, as advertised. I am migrating tcpslice and libpcap to the
> new free service today, and tcpdump migration is imminent. If anybody
> has useful input to make, please do not delay.

I moved other open source projects without incident.
So please don't hesitate, it was just unclear to me how to do it at first,
and now I found the "migrate" button.

--
]   Never tell me the odds! | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works|IoT architect   [
] m...@sandelman.ca  http://www.sandelman.ca/|   ruby on rails[

--- End Message ---
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers

Re: [tcpdump-workers] Stick with Travis for continuous integration, or switch?

[Michael Richardson via tcpdump-workers]

--- Begin Message ---
Francois-Xavier Le Bail via tcpdump-workers wrote:
> To save CI runtime, I have committed
> a063c2d21417345ee583551ef2c07a0be6b32696 for libpcap.

> This will currently run only five builders (amd64, arm64, ppc64le,
> s390x and osx) and do the matrix processing with scripts.

Thanks.

--- End Message ---
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers

Re: [tcpdump-workers] Request for new LINKTYPE_* code LINKTYPE_AUERSWALD_LOG

[Michael Richardson via tcpdump-workers]

--- Begin Message ---

developer--- via tcpdump-workers  wrote:
> We would like to request a dedicated LINKTYPE_* / DLT_* code.
> Auerswald is a major German telecommunications equipment manufacturer.
> We have implemented the option to capture (combined) network traffic
> and logging information as pcap/pcapng in our soon to be released new
> product line.

> For development, we so far have used LINKTYPE_USER0 and would like to
> change this to a proper code before the commercial release.

> We also plan to publicly release the dissector and would like to make
> sure both can be released with a proper code from the get go.  The
> dissector we currently use is however only in lua.

> Our preferred name would be LINKTYPE_AUERSWALD_LOG

That sounds great.
Ideally, you would have a document somewhere that would describe your capture
format.  We might want to review the format.

I would note that if you are just adding logging, and you just want to use
pcapng, that you might store your ethernet captures as normal EN10B, and your
logging in a new LINKTYPE_, which was specific to your log format.
In pcapng, you can mix different LINKTYPEs, in a single file.
(But, not in pcap, which is/was a major reason pcapng was designed)

Then you can ideally follow:

  
https://github.com/the-tcpdump-group/libpcap/blob/master/doc/DLT_ALLOCATE_HOWTO.md

send a pull request.

> If anyone is interested we can provide further information.

> Best regards

> Frank Gorgas-Waller Software Architect

> Auerswald Gesellschaft für Datensysteme mbH Vor den Grashöfen 1 38162
> Cremlingen Germany

--
]   Never tell me the odds! | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works|IoT architect   [
] m...@sandelman.ca  http://www.sandelman.ca/|   ruby on rails[

--- End Message ---
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers

Re: [tcpdump-workers] Speed specific Link-Layer Header Types for USB 2.0

[Michael Richardson via tcpdump-workers]

--- Begin Message ---

Tomasz Moń via tcpdump-workers wrote:
>> When low-speed capture is performed, it has to be performed at the leaf
>> (in graph-theory sense) connection. Full-speed traffic never make it to
>> the low-speed cables, so the capture will contain only low-speed
>> packets.

> Is there anything still to discuss here? I have opened the pull
> requests [1] [2] few weeks ago. I have also prepared Wireshark [3]
> change that I would like to merge before Wireshark 4.0 release.

> I think I have summed up whole discussion in the libpcap commit
> message. High-speed and Low-speed are pretty much clear, as these links
> never observe other speed packets. Full-speed is the only disputable
> one, but I believe the PRE packets are really a corner case that is not
> worth per-packet speed encoding. If the user has obsolete setup to
> trigger the corner case in the first place, then such user will
> definitely know to just capture at the downstream link for low-speed
> traffic.

I think that Guy and I thought that you'll be better off with a single
LINKTYPE with a subtype header, but if you want to go with three, I don't
object.

--
]   Never tell me the odds! | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works|IoT architect   [
] m...@sandelman.ca  http://www.sandelman.ca/|   ruby on rails[

--- End Message ---
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers

[tcpdump-workers] mailman3 list imported

[Michael Richardson via tcpdump-workers]

--- Begin Message ---

The mailing list has been moved from a mailman2 host to a mailman3 host.
I had subscribed everyone with an option to confirm, but that was a bad idea.
I have now found the import21 command, and imported the "pickle" file from
the mailman2 installation.

I hope that this email finds you well, and that the SPF and DKIM for the list
checks out for you.

The old pipermail archives at:
   https://lists.tcpdump.org/pipermail/tcpdump-workers/

have been copied over, and I'll adjust the info pointer.
They won't get updated as things are moved over to Hyperkitty.
I will import the mboxes into hyperkitty, as soon as I figure out where the
debian installed hyperkitty django commands are actually installed.

I'm sorry for the confusion.  Sunday/Monday is the day that I had time and
energy, and the number of tedious things to tweak and validate was many.
The mailman2 web interface had to be turned off when it became clear that it
was being abused to do email DDoS against all sorts of random victims.

My previous four attempts to send this email got rejected, because
multipart/signed was not an acceptable mime type.

--- End Message ---
___
tcpdump-workers mailing list -- tcpdump-workers@lists.tcpdump.org
To unsubscribe send an email to tcpdump-workers-le...@lists.tcpdump.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s