Re: [tcpdump-workers] [tcpdump-security] [libpcap] Problem with version 1.9.0

2018-07-23 Thread Jan Stary 
On Jul 23 13:30:55, g...@alum.mit.edu wrote:
> On Jul 23, 2018, at 1:04 PM, Jan Stary  wrote:
> 
> > From both a sysadmin and user perspective, I find the GNU autotools
> > amd CMake a major annoyance. Would you please consider doing what e.g.
> > http://mandoc.bsd.lv/cgi-bin/cvsweb/configure does?
> 
> What advantage would it give us that would make it worth our effort?

A ./configure script like that is (in my experience) much more
readable and writable, and about hundreds of times faster.
It does not depend on autoconf, automake, m4, etc and does not
require the user to install, to run, or to understand the GNU tools.
The produced Makefile.* is a fraction of that produced by auto*.

Please try it out, either with http://mandoc.bsd.lv/ or with
e.g. https://github.com/columbia-irt/rtptools to see for yourself.
Run ./configure and look at config.h and Makefile.*: clean, obvious code.

To quote from http://mandoc.bsd.lv/cgi-bin/cvsweb/INSTALL :

  The mandoc package intentionally does not use GNU autoconf because
  we consider that toolset a blatant example of overengineering that
  is obsolete nowadays, since all modern operating systems are now
  reasonably close to POSIX and do not need arcane shell magic any
  longer.  If your system does need such magic, consider upgrading
  to reasonably modern POSIX-compliant tools rather than asking for
  autoconf-style workarounds.

If you decide to go that way, I am prepared to help with the effort.

Jan

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

Re: [tcpdump-workers] Metamako DLT Request

2018-07-23 Thread Guy Harris 
On Jul 23, 2018, at 6:36 PM, David Mirabito  wrote:

> We'd like to request a new DLT_ value for Metamako's packet capture trailer
> that is generated by our MetaWatch network application.
> 
>  https://www.metamako.com/applications/metawatch-app.html
> 
> It is a variable length data trailer, appended immediately after an
> original Ethernet Payload. It is backwards-compatible with DLT_EN10MB but
> adds additional fields after the original frame payload until the
> end-of-frame marker.
> 
> We were thinking something like this
> 
>LINKTYPE_METAMAKO_TRAILER --> DLT_METAMAKO_TRAILER
> 
> Is there anything in particular that you require?

A detailed description of the format of the trailer.

Presumably, for Ethernet packets with a type field, the trailer can't be found 
until the payload is dissected, because there's no other way to determine how 
large the payload is.

Also, presumably, the trailer comes after any padding, and there's no FCS in 
these packets.
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers

[tcpdump-workers] Metamako DLT Request

2018-07-23 Thread David Mirabito 
[ Resending for a colleague who was not a subscriber and whose mail may
have bounced. Apologies in advance for any duplication ]


Hi,

We'd like to request a new DLT_ value for Metamako's packet capture trailer
that is generated by our MetaWatch network application.

  https://www.metamako.com/applications/metawatch-app.html

It is a variable length data trailer, appended immediately after an
original Ethernet Payload. It is backwards-compatible with DLT_EN10MB but
adds additional fields after the original frame payload until the
end-of-frame marker.

We were thinking something like this

LINKTYPE_METAMAKO_TRAILER --> DLT_METAMAKO_TRAILER

Is there anything in particular that you require?

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

Re: [tcpdump-workers] Precompiled binaries or compile script needed for Android

2018-07-23 Thread enh 
On Sat, Jul 21, 2018 at 2:34 PM Michael Richardson  wrote:

>
> enh  wrote:
> >> secur...@tcpdump.org is not an appropriate place to ask about
> binaries.
> >> Sometime on tcpdump-workers might be able to help you.
> >> https://www.androidtcpdump.com/ also is around.
> >> I don't know who runs it.
> >>
> >> I spent some time trying to integrate the Android (ASOP) build
> system
> >> Makefiles into tcpdump, but it never went upstream, and I ran out of
> >> time.
>
> > as the AOSP maintainer of external/tcpdump and external/libpcap, i
> don't
> > think that would help you or me. it's usually just a pain for us
> when an
> > upstream project has an Android.mk because then we have to
> coordinate for
> > build system changes that no-one outside of AOSP actually cares
> about.
>
> And if we could bring you into the fold, then you could maintain the file
> you want?
>

even for projects where i have an upstream commit bit, it's not helpful to
either side to have the Android.mk in the upstream project. Android's
compiler toolchain gets updated frequently, so it's often necessary to slip
in a -Wno-new-warning-that-a-project-doesn't-care-about or whatever.
there's also the need to work around the mismatch between autoconf (or
equivalent) and Android's single tree for four architectures with generated
files checked in: that sometimes leads to Android.mk effectively taking
over the role of config.h itself.

and at the same time, there's no benefit to upstream from keeping an
Android.mk that's only useful in AOSP and that they can't usually test
themselves anyway. and why would they? even on very beefy machines, an AOSP
build isn't quick. and the download is even worse.

what _would_ be useful:

1. if it was easier for folks to build with the NDK. but we think it scales
better if we get to the point where it's trivial to cross compile. like i
said, if you know how to set up a suitable cross-compilation toolchain you
can already build tcpdump out of the box with configure/make. and as i
said, the next step is to remove the need to set up a cross-compilation
toolchain (
https://android.googlesource.com/platform/ndk/+/master/docs/Roadmap.md).
and i really need to get around to publishing a script that hides even
that, so it's more of an "apt-get" kind of experience. we're working on
it...

2. if AOSP was always up to date. i know historically a lot of projects
were added to external/ and then left to rot, but my team has been trying
to clean that up, and libpcap/tcpdump were actually fairly early
beneficiaries. i removed all local hacks some time ago and the reason i'm
on this mailing list is because there isn't a separate -announce mailing
list :-)

i have someone working on automating updates of projects hosted on github,
though, so hopefully we'll be able to take the human out of the loop for
libpcap this (1.9.0 release...

> (luckily since we switched to Android.bp i haven't seen any upstream
> > project even think it might be a good idea for them to have one of
> those!)
>
> ha.
>
> --
> ]   Never tell me the odds! | ipv6 mesh
> networks [
> ]   Michael Richardson, Sandelman Software Works| network
> architect  [
> ] m...@sandelman.ca  http://www.sandelman.ca/|   ruby on
> rails[
>
>
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers

Re: [tcpdump-workers] [tcpdump-security] [libpcap] Problem with version 1.9.0

2018-07-23 Thread Guy Harris 
On Jul 23, 2018, at 1:04 PM, Jan Stary  wrote:

> From both a sysadmin and user perspective, I find the GNU autotools
> amd CMake a major annoyance. Would you please consider doing what e.g.
> http://mandoc.bsd.lv/cgi-bin/cvsweb/configure does?

What advantage would it give us that would make it worth our effort?
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers

Re: [tcpdump-workers] [tcpdump-security] [libpcap] Problem with version 1.9.0

2018-07-23 Thread Dagobert Michelsen 
Hi Jan,

Am 23.07.2018 um 22:04 schrieb Jan Stary :
> 
> From both a sysadmin and user perspective, I find the GNU autotools
> amd CMake a major annoyance. Would you please consider doing what e.g.
> http://mandoc.bsd.lv/cgi-bin/cvsweb/configure does?
> 
> A simple, hand written shell script, with a set of obvious
> {test,compat}-*.c helpers. No dependency on anything, orders
> of multitude smaller and faster then a auto*-generated configure.

No - please! Handwritten configure scripts are the worst nightmare for
downstream packages as each package uses its own way to configure flags
for compilation, linkage, install relocation etc. This makes
packaging stuff hard as it requires specific adjustments of build
procedures. I maintain roughly 1600 packages and this would not be
possible when there were no standards. Autotools is far from perfect,
but it is a standard and after you figured something out it works for
hundreds of builds in the same way.


Best regards

  — Dago

-- 
"You don't become great by trying to be great, you become great by wanting to 
do something,
and then doing it so hard that you become great in the process." - xkcd #896

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

Re: [tcpdump-workers] [tcpdump-security] [libpcap] Problem with version 1.9.0

2018-07-23 Thread Jan Stary 
On Jul 23 18:38:17, g...@greenie.muc.de wrote:
> Hi,
> 
> On Mon, Jul 23, 2018 at 09:35:30AM -0400, Michael Richardson wrote:
> > Let's switch over to cmake as our official mechanism now... i.e. have
> > travis, etc. use it in preference to configure.
> 
> From a sysadmin perspective, I find cmake to be a major annoyance
> (because it usually does not exist on systems where I want to install
> packages, and if your platform is not "mainstream i386/amd64", there's
> quite often no binary packages, so "go out and compile cmake" is it,
> then... like, FreeBSD/Sparc64).
> 
> I do understand that this is not for me to decide and that you're
> fully free to ignore me, but I still wanted to say it so nobody can
> say afterwards "hey, we announced this on the list and nobody spoke
> up".
> 
> (If you say "... use it in preference to configure" and configure stays
> around as fallback, I shut up and be happy :-) )

From both a sysadmin and user perspective, I find the GNU autotools
amd CMake a major annoyance. Would you please consider doing what e.g.
http://mandoc.bsd.lv/cgi-bin/cvsweb/configure does?

A simple, hand written shell script, with a set of obvious
{test,compat}-*.c helpers. No dependency on anything, orders
of multitude smaller and faster then a auto*-generated configure.

Jan

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

Re: [tcpdump-workers] [tcpdump-security] [libpcap] Problem with version 1.9.0

2018-07-23 Thread Dagobert Michelsen 
Hi,

Am 23.07.2018 um 19:11 schrieb Ray Bellis :
> On 23/07/2018 17:38, Gert Doering wrote:
>> I do understand that this is not for me to decide and that you're
>> fully free to ignore me, but I still wanted to say it so nobody can
>> say afterwards "hey, we announced this on the list and nobody spoke
>> up".
> 
> FWIW, I loath CMake too. :p

Is this a vote? It is a real pain to customize parameters in CMake
and I avoid it wherever possible and I would really appreciate if
autoconf at least won’t go away.


Best regards

  — Dago

-- 
"You don't become great by trying to be great, you become great by wanting to 
do something,
and then doing it so hard that you become great in the process." - xkcd #896

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

Re: [tcpdump-workers] [libpcap] Problem with version 1.9.0

2018-07-23 Thread Francois-Xavier Le Bail 
On 23/07/2018 15:33, Michael Richardson wrote:
> Francois-Xavier Le Bail via tcpdump-security wrote:
> > Hello,
> 
> > We have in 1.9.0 branch:
> 
> > $ git grep '1\.9\.0-PRE-GIT'
> > configure:# Generated by GNU Autoconf 2.69 for pcap 1.9.0-PRE-GIT.
> > configure:PACKAGE_VERSION='1.9.0-PRE-GIT'
> > configure:PACKAGE_STRING='pcap 1.9.0-PRE-GIT'
> 
> oh.
> 
> > $ tcpdump --version
> > make: Nothing to be done for 'all'.
> > tcpdump version 4.10.0-PRE-GIT
> > libpcap version 1.9.0-PRE-GIT (with TPACKET_V3)
> <
> > OpenSSL 1.1.0f  25 May 2017
> > libdnet unknown version
> > Compiled with AddressSanitizer/CLang.
> 
> > Need autoreconf.
> > And 1.9.1 ?
> 
> Let's do 1.9.1 in September.

Why not this week to have a proper version tag ?

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

Re: [tcpdump-workers] [tcpdump-security] [libpcap] Problem with version 1.9.0

2018-07-23 Thread Ray Bellis 
On 23/07/2018 17:38, Gert Doering wrote:

> I do understand that this is not for me to decide and that you're
> fully free to ignore me, but I still wanted to say it so nobody can
> say afterwards "hey, we announced this on the list and nobody spoke
> up".

FWIW, I loath CMake too. :p

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

Re: [tcpdump-workers] [tcpdump-security] [libpcap] Problem with version 1.9.0

2018-07-23 Thread Gert Doering 
Hi,

On Mon, Jul 23, 2018 at 09:35:30AM -0400, Michael Richardson wrote:
> Let's switch over to cmake as our official mechanism now... i.e. have
> travis, etc. use it in preference to configure.

From a sysadmin perspective, I find cmake to be a major annoyance
(because it usually does not exist on systems where I want to install
packages, and if your platform is not "mainstream i386/amd64", there's
quite often no binary packages, so "go out and compile cmake" is it,
then... like, FreeBSD/Sparc64).

I do understand that this is not for me to decide and that you're
fully free to ignore me, but I still wanted to say it so nobody can
say afterwards "hey, we announced this on the list and nobody spoke
up".

(If you say "... use it in preference to configure" and configure stays
around as fallback, I shut up and be happy :-) )

gert

-- 
"If was one thing all people took for granted, was conviction that if you 
 feed honest figures into a computer, honest figures come out. Never doubted 
 it myself till I met a computer with a sense of humor."
 Robert A. Heinlein, The Moon is a Harsh Mistress

Gert Doering - Munich, Germany g...@greenie.muc.de
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers

Re: [tcpdump-workers] [tcpdump-security] [libpcap] Problem with version 1.9.0

2018-07-23 Thread Michael Richardson 
Guy Harris via tcpdump-security  wrote:
>>> Need autoreconf.

> I've updated libpcap-release-howto.md, in the
>g...@bpf.tcpdump.org:maintainer-notes repository, to include the
>autoreconf step (and to clean up the formatting, to work as standard
>Markdown, as well as replacing the specific version numbers with
>variables).

> By the way, is there still a good reason to have the configure scripts
> and config.h.in files checked into Git, or should we remove them from
> Git and require people who build from Git to generate the configure
> scripts themselves (they're probably doing that as developers, so I
> don't mind requiring them to have autoconf installed)?  Generating the
> configure scripts is already part of the release process.

I've mixed feelings about this.

Let's switch over to cmake as our official mechanism now... i.e. have
travis, etc. use it in preference to configure.

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

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

[tcpdump-workers] [libpcap] Problem with version 1.9.0

2018-07-23 Thread Michael Richardson 
Francois-Xavier Le Bail via tcpdump-security wrote:
> Hello,

> We have in 1.9.0 branch:

> $ git grep '1\.9\.0-PRE-GIT'
> configure:# Generated by GNU Autoconf 2.69 for pcap 1.9.0-PRE-GIT.
> configure:PACKAGE_VERSION='1.9.0-PRE-GIT'
> configure:PACKAGE_STRING='pcap 1.9.0-PRE-GIT'

oh.

> $ tcpdump --version
> make: Nothing to be done for 'all'.
> tcpdump version 4.10.0-PRE-GIT
> libpcap version 1.9.0-PRE-GIT (with TPACKET_V3)
<
> OpenSSL 1.1.0f  25 May 2017
> libdnet unknown version
> Compiled with AddressSanitizer/CLang.

> Need autoreconf.
> And 1.9.1 ?

Let's do 1.9.1 in September.

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


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