[tcpdump-workers] tcpslice maintainer

2011-08-15 Thread Michal Sekletar

Hello everyone,

I'd like to send a patch for tcpslice to it's maintainer, but email 
address  seem to be dead. Is there anyone out there 
still maintaining tcpslice?

I hope this is right place to ask because tcpslice is related project.

Thanks

--
Michal Sekletar, 
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.


Re: [tcpdump-workers] [libpcap] fix typo on manpage install (#320)

2013-09-24 Thread Michal Sekletar
On Mon, Sep 23, 2013 at 12:41:45PM -0700, Guy Harris wrote:
> 
> On Sep 23, 2013, at 11:45 AM, Michael Richardson  wrote:
> 
> > But it means that anyone who checks out code from git is foobar if they can
> > not get the *correct* version of autoconf installed to generate the files.
> 
> So, if it's possible to do so, perhaps we should have a post-commit/post-push
> hook on bpf.tcpdump.org that will run autoreconf any time configure.in or
> aclocal.m4 is changed and commit the result.
> 
> That way, what's on bpf.tcpdump.org will be generated by the autoconf version
> on bpf.tcpdump.org, so we control the version of autoconf used to generate
> what goes into the tarball *and* what's used by people who check out from git
> (as long as they don't change configure.in or aclocal.m4, but there's not that
> much we can do to help people who do change them other than pointing them at
> the GNU project repository for autoconf).

I agree to have pust-update hook a keep configure checked in git. This should
work for the time being and give you control over the version of autotools used
to generate build scripts.

But is this gonna work in the long run? If there are issues with build system
which are not possible to workaround and prevent us from using new versions of
autotools then I dare to say we should introduce stable versions. For example
we might support release 1.5 on currently all platforms but move on from the old
cruft on master and deprecate platforms which are no longer relevant today. We
could start adding notes to commits in order to mark those which are worth to
backport to stable version.

Cheers,

Michal

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


Re: [tcpdump-workers] Multiple call to pcap_open_live

2013-11-18 Thread Michal Sekletar
On Mon, Nov 18, 2013 at 12:38:24AM -0500, Benjamin Vanheuverzwijn wrote:
> Hi,

Hi Benjamin,

> 
> libpcap version: 1.4.0 (on archlinux)

I am running Fedora 19 (libpcap-1.4.0). 

> 
> Is it possible to have multiple call to "pcap_open_live()" followed by
> pcap_close() ?

It shouldn't be a problem.

> 
> It seems like pcap_close() doesn't cleanly close opened resources, if you
> strace the following program, you will see file descriptors growing up.

I am unable to reproduce the issue. In strace output I see only descriptor 3
which is acquired and closed on every iteration. Tried with two NICs, wired and
wireless.

> 
> Am i doing it wrong? How it should be done?

>From output you have provided I have a suspicion that your problem is somehow
caused by calling open() on those /sys/bus/usb/* files. I don't have those in my
strace output, probably because interface you have used is hotplugged wireless
usb dongle, I guess (judging by interface name from udev).

I might be able to try again with wireless USB dongle tomorrow. Will keep you
posted on my findings.

> 
> Thanks,

Cheers,

Michal
> 
> To reproduce:
> // Compile with gcc -o openlive openlive.c -l pcap
> #include 
> 
> int main(int argc, char *argv[]) {
> int i=0;
> for (i = 0; i != 2000; ++i) {
> char errbuf[256];
> pcap_t *pcap = pcap_open_live("wls3", 1024, 1, 0, errbuf);
> pcap_close(pcap);
> }
> return 0;
> }
> 
> $ strace ./openlive
> [...]
> open("/sys/bus/usb/devices/4-2/devnum", O_RDONLY) = 16
> fstat(16, {st_mode=S_IFREG|0444, st_size=4096, ...}) = 0
> mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
> 0x7f5e040f
> read(16, "8\n", 4096)   = 2
> [...]
> open("/sys/bus/usb/devices/usb4/speed", O_RDONLY) = 91
> fstat(91, {st_mode=S_IFREG|0444, st_size=4096, ...}) = 0
> mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
> 0x7fc006371000
> read(91, "480\n", 4096) = 4
> 
> 
> -- 
> Benjamin Vanheuverzwijn
> ___
> tcpdump-workers mailing list
> tcpdump-workers@lists.tcpdump.org
> https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers


Re: [tcpdump-workers] Setting the Buffer Size Without Restarting the NIC?

2014-02-06 Thread Michal Sekletar
On Thu, Feb 06, 2014 at 02:36:10AM -0800, Hei Chan wrote:
> Hi,
> 
> Thanks for your reply.
> 
> I forgot to mention my OS -- CentOS 6.5.
> 
> Now, I look at the word "activated", and I am a bit confused.
> 
> Does it refer to a device that is enabled in the OS?  Or does it refer to a
> device that is "activated" by pcap_*() such that even a device is enabled in
> the OS but could be "not activated" before those pcap_*() calls?
Hi,

Activated refers to pcap_t handle. Before you can do capture on the device
you have to have handle and after that capture parameters are set and finally
handle is marked as activated. So it doesn't refer to status of the device in
OS.

> 
> Thanks in advance.

Cheers,

Michal
> 
> 
> 
> On Thursday, February 6, 2014 6:24 PM, Guy Harris  wrote:
> 
> On Feb 6, 2014, at 12:19 AM, Hei Chan  wrote:
> 
> > When I call pcap_set_buffer_size() on an actively using/running NIC, it 
> > gives me an error:
> > can't perform  operation on activated capture
> > 
> > Is there a way to change the pcap capture buffer size without deactivating 
> > it?
> 
> On at least some platforms, no, there isn't - other than having libpcap close 
> the device and reopen it.
> 
> > How does this buffer different from SO_RCVBUF?
> 
> Well, on the machine on which I'm typing this:
> 
>     $ uname -sr
>     Darwin 12.5.0
> 
> (better known as
> 
>     $ sw_vers
>     ProductName:    Mac OS X
>     ProductVersion: 10.8.5
>     BuildVersion:   12F45
> 
> ) it's different because it's not a socket buffer because it's not a buffer 
> for a socket, and it's set with BIOCSBLEN.
> 
> That's also true on all current OSes that have the letters "B", "S", and "D" 
> at the end of the name, as well as Solaris 11.
> 
> (Translation: not all the world is Linux.)
> 
> And, even on Linux, with sufficiently-modern versions of libpcap (going back 
> to 1.0) and sufficiently modern kernels (going back at least to 2.6.0, I 
> think) it's typically set with a pile of calls that set up a memory-mapped 
> buffer that cannot simply be resized on the fly - you'd have to destroy the 
> buffer and re-create it (and lose packets as a result).
> 
> 
> > It seems like SO_RCVBUF doesn't matter in this context anymore because 
> > libpcap goes through a different route in receiving packets?
> 
> Yes, as per the above.  The only platforms on which it's a normal socket are
> 
>     1) Linux if libpcap is so old that it doesn't support memory-mapped 
> captures or the kernel is so old that it doesn't offer memory-mapped captures;
> 
>     2) IRIX;
> 
>     3) SunOS 3.x (assuming the code hasn't suffered so much from code rot 
> that it no longer works at all on 3.x);
> 
>     4) some specialized devices on Linux.
> 
> ___
> tcpdump-workers mailing list
> tcpdump-workers@lists.tcpdump.org
> https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers


Re: [tcpdump-workers] libpcap 1.5.3 pcap_open_offline_with_tstamp_precision() broken

2014-06-06 Thread Michal Sekletar
On Thu, Jun 05, 2014 at 07:21:26PM +0200, Steffen Bauch wrote:
> Hi,
> 
> libpcap 1.5.3 (as deployed in Ubuntu 14.04 LTS) (and current GIT
> master head) will not output timestamps in a right way if pcapng
> savefiles are used and timestamp conversion is requested with
> pcap_open_offline_with_tstamp_precision(). For traditional pcap
> files necessary timestamp conversion will work in a right way.
> 
> To reproduce this problem:
> 
> 1. Capture a network trace with dumpcap as pcapng file
> 
> dumpcap -i eth0 -w timestamp_problem.pcapng
> 
> per default this capture will have microsecond timestamp resolution
> 
> 2. Open the file with
> pcap_open_offline_with_tstamp_precision(filename,
> PCAP_TSTAMP_PRECISION_NANO, errbuf);
> 
> 3. Retrieve frames with pcap_dispatch and a callback function and
> print the content of the timevals (sec and usec).
> 
> All frames retrieved will have subsecond timestamps between 0 and
> 999, which is wrong.
> 
> 4. Convert the file from pcapng to pcap
> 
> editcap timestamp_problem.pcapng timestamp_working.pcap -F pcap
> 
> 5. Perform steps 2 and 3 for the pcap file and see correct subsecond
> timestamps in nanosecond range 0 - 9
> 
> The reason for the problem is a wrong computation of the scaling
> factor in pcap_ng_next_packet in sf-pcap-ng.c
> 
> Assume you have a file with microsecond resolution and request
> nanosecond output. In this case you will be required to scale the
> value up for representation purposes. But the code will perform the
> following:
> 
> frac *= ps->ifaces[interface_id].tsresol; /*
> resolution of the interface: multiply with a small value: 100 */
> frac /= ps->user_tsresol; /* requested output
> resolution, divide with a large value: 10 */
> 
> This will lead to an overall downscaling of the fractional part, an
> overall division by factor 1000 which doesn't seem to be right. In
> my opinion the code should multiply with the output resolution and
> divide by the interface resolution.
> 
>   frac *= ps->user_tsresol; /* requested output resolution, 
> multiply
> with a large value: 10 */
> frac /= ps->ifaces[interface_id].tsresol; /*
> resolution of the interface: divide with a small value: 100 */

Thanks for reporting this. I tested your patch and I can confirm it fixes the
issue. Can you please open pull request and submit your patch via github?

> 
> Best regards,
> 
> Steffen

Cheers,

Michal
> 
> -- 
> Web: http://datenkobold.de Twitter: @steffenbauch
> ___
> tcpdump-workers mailing list
> tcpdump-workers@lists.tcpdump.org
> https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers


Re: [tcpdump-workers] pcapng save files

2014-07-03 Thread Michal Sekletar
On Thu, Jul 03, 2014 at 11:52:03AM -0400, Michael Richardson wrote:
> 
> Guy Harris  wrote:
> > The current libpcap support uses the existing APIs, which can't expose
> > the full capabilities of pcap-ng; it requires all interfaces in the
> > pcap-ng file to have the same link-layer header type and snapshot
> > length, and all sections of the pcap-ng file to have the same byte
> > order.  (Then again, Wireshark requires all sections of the pcap-ng
> > file to be the same section :-); it currently supports only one
> > section.  This needs to be fixed as well.)
> 
> Yes, this is a good point.  I don't think we can go there until we start
> using pcapng by default, and start considering pcap as read-only.
> 
> Also, I think that we will need to have a set of pcapng utilities.
> I was trying to run "netdude" which lets you pick/chose/edit pcap files,
> but the version of gtk that is requires is now obsolete... so I wound up
> trying to hex editing my pcap file to remove the unwanted packet, then I used
> tcpslice when I failed to get that right.
> 
> (I realize that pcapng files have the goal that concatenation is simple)
> 
> > OS X Mountain Lion has changes to libpcap and tcpdump that allow
> > tcpdump to write pcap-ng files (-P specifies "write pcap-ng"); sadly,
> > those changes are under the APSL, patent clauses included, so I'm loath
> > to incorporate them into our libpcap and tcpdump.
> 
> Interesting, I didn't know Apple did that.
> Who did that work, I'm curious?  And why?

FWIW, 

https://www.opensource.apple.com/source/libpcap/libpcap-42/libpcap/pcapng.c

> 
> >> PCAPNG is magic 0x1A2BC3D4.
> >> PCAP is magic   0xa1b23c4d.
> >> I would have liked if PCAPNG had used the same magic, and actually just
> >> bumped the PCAP_VERSION_MAJOR...
> 
> > I.e., if the major version number of the file is 3, the rest of the
> > file header would look more like a pcap-ng Section Header Block, with
> > the magic number being the block type?
> 
> Yes, that's I would have preferred.
> 
> >> Did anyone tell the /bin/file people about the PCAPNG magic number?
> 
> > Yes:
> 
> Good.
> 
> >> Anyway, I'm thinking that there should be another tcpdump 4.x release
> >> that writes to pcap format by default, but has an option to force 
> output
> >> format to pcapng, and then a 5.x release that defaults to writing
> >> pcapng.
> 
> > Yes; the new libpcap would have a new API that can read pcap and
> > pcap-ng files and expose the full capabilities of pcap-ng, and another
> > new API that can write pcap-ng files (and perhaps also pcap files; that
> > would let us fix some infelicities in the current pcap writing API,
> > such as not being able to get a write error indication or a close error
> > indication), and tcpdump would, if those APIs are available in libpcap,
> > use the new APIs to read files and would offer a -P flag to write
> > pcap-ng files.  (The existing APIs would remain, for the benefit of
> > programs not yet changed to use the new APIs.)
> 
> I think that we should be able to make the existing APIs wrappers around
> new function?
> 
> Are there specific things in a new API that would make wireshark happier?
> feel free to start a new thread ;-)
> 
> > Tcpdump 5.x would do the same, but write pcap-ng files by default; I'm
> > not sure whether we should then make -P specify "write pcap" or add a
> > new option for that.
> 
> I'd like it to be -P pcap or -P pcapng (or -P pcap3 ).
> I'd also like tcpdump 5 to come with a new (alternate) main() where we
> get to start again on all the single letter options and go for long options.
> 
> --
> ]   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
> [

Cheers,

Michal

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


Re: [tcpdump-workers] buildbot failure in tcpdump+libpcap on Solaris-10-SPARC

2014-08-22 Thread Michal Sekletar
On Fri, Aug 22, 2014 at 05:33:14AM +, buildbot-no-re...@wireshark.org wrote:
> The Buildbot has detected a new failure on builder Solaris-10-SPARC while 
> building tcpdump+libpcap.
> Full details are available at:
>  http://buildbot.wireshark.org/tcpdump/builders/Solaris-10-SPARC/builds/100
> 
> Buildbot URL: http://buildbot.wireshark.org/tcpdump/
> 
> Buildslave for this Build: solaris-10-sparc
> 
> Build Reason: The Nightly scheduler named 'nightly' triggered this build
> Build Source Stamp: [branch master] HEAD
> Blamelist: 
> 
> BUILD FAILED: failed

Seems like bpf.tcpdump.org is still down.

Michal
> 
> sincerely,
>  -The Buildbot
> 
> 
> 
> ___
> tcpdump-workers mailing list
> tcpdump-workers@lists.tcpdump.org
> https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers


Re: [tcpdump-workers] tcpdump and libpcap releases, and future thoughts

2014-09-08 Thread Michal Sekletar
On Wed, Sep 03, 2014 at 03:34:14PM -0400, Michael Richardson wrote:
> 
> I pushed the button on libpcap 1.6.2 early last night.
> This includes patches that Guy asked for.  It seems that we might
> need more patches to better select Linux memory mapped packet
> choices?
> 
> I pushed the button on tcpdump 4.6.2 later that night.
> I was trying to use libnetdissect in another project, and that needs
> tcpdump, and I needed both amd64 and x86 versions to make everything
> work nicely under Travis-CI, so I used the ../../sourcecode/configure
> method to build outside the source tree, and found that tcpdump couldn't find
> libpcap properly.  I also found a related bug in an
> AC_MSG_ERROR(). Apparently , is a bad thing to have an error message,
> and putting "" around things just confuses m4.
> 
> I would like to move all of the source for libnetdissect into a subdir,
> and make it easier to build just that part, and finally introduce my
> idea for a second main()/getopt() containing top-level program for tcpdump,
> one which is not called tcpdump, but rather "pktdump".
> 
> pktdump would start with a clean slate of -SingleLetter options, probably
> starting with *no* single letter options, only --long-options, and we
> can decide which ones deserve shortcuts  I think we already have a
> BSD licensed getopt_long in missing/ I guess I could go check... yes.

Hi, 

this request is a bit unrelated to your proposal, but I think it better be
considered sooner than later.

In the future I'd like to see pktdump to implement an architecture which would
allow a user to run a packet dissector completely unprivileged. Meaning, that
*all* privileged operations are done by a very tiny server program running on
the side. We could then not implement equivalent of -Z option and possibly hook
up the pktdump with an authentication mechanism like polkit or similar.

Michal

> 
> I'm open to suggestions on other ways to proceed.
> 
> --
> ]   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 mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers


Re: [tcpdump-workers] Official patches for CVE-2014-8767/CVE-2014-8768/CVE-2014-8769?

2014-11-23 Thread Michal Sekletar
On Fri, Nov 21, 2014 at 11:01:15PM +0100, Romain Francoise wrote:
> On Fri, Nov 21, 2014 at 03:47:06PM -0500, Michael Richardson wrote:
> > It's supposed to happen, but I'm checking.
> > Should be there now.  Is cron failing to do it's thing?
> 
> Ok, the fixes still aren't on master, but now there's a tcpdump-4.7
> branch with the commits I need.

Please, can somebody with push access fix this.

Also it would be nice if we agree on single place where development happens and
stick to that.

Because bpf.tcpdump.org has a bad track-record (IIRC multiple power, network
failures in the past) I am for sticking with GitHub.

> 
> So I apparently need all of these?
> 
> 3f5693a 10 days ago Guy Harris Report a too-long unreachable destination list.
> 54d2912 10 days ago Guy Harris Not using offsetof() any more, so no need for 
> .
> e302ff0 10 days ago Guy Harris Further cleanups.
> 3e8a443 10 days ago Guy Harris Clean up error message printing.
> ab4e52b 10 days ago Guy Harris Add initial bounds check, get rid of union 
> aodv.
> 4038f83 10 days ago Guy Harris Do more bounds checking and length checking.
> 9255c9b 10 days ago Guy Harris Do bounds checking and length checking.
> 
>  print-aodv.c   | 481 
> ++---
>  print-geonet.c | 270 ++--
>  print-olsr.c   |  56 +--
>  3 files changed, 417 insertions(+), 390 deletions(-)
> 
> That's a lot bigger than typical security patches. :(

Yes, I spent good couple hours backporting those to older versions we have in
Fedora 19 and 20.

> 
> > It's in the tcpdump.org/beta/ directory, but I didn't want to release
> > until the distros had a chance to patch.
> 
> But did you notify the distros? Because I didn't get advance notice, and
> the others haven't released security updates yet either.

I was notified by Red Hat Security Response Team once CVEs where public. In the
disclosure report there was a mention of existing patches therefore I
checked GitHub because that is place where most of the development happens these
days, and found no fixes.

I started to work on the patches ASAP and after submitting the first one
as Pull Request #413 I was told that patches actually do exist but the legacy
place where tcpdump/libpcap code lives was not synced to GitHub for days.

Michal

> 
> Thanks,
> -- 
> Romain Francoise 
> http://people.debian.org/~rfrancoise/
> ___
> tcpdump-workers mailing list
> tcpdump-workers@lists.tcpdump.org
> https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers


Re: [tcpdump-workers] Official patches for CVE-2014-8767/CVE-2014-8768/CVE-2014-8769?

2014-11-24 Thread Michal Sekletar
On Mon, Nov 24, 2014 at 09:22:23AM -0500, Michael Richardson wrote:
> 
> Guy Harris  wrote:
> > (I'm fine with making it the Official Home if Michael chooses to do so.
> > I've managed to cope with the workflow changes required when
> > libpcap/tcpdump switched to Git, when Wireshark switched to Git, and
> > when Wireshark switched to Git+Gerrit, with the aid of some time spent
> > with a porcelain kiln, so I can probably spend a little more time
> > firing the clay and glaze, if necessary, if libpcap/tcpdump switches to
> > using GitHub. :-)) 
> 
> What I'm hearing is that using git is confusing, because it allows tcpdump
> to exist on more than one person's laptop at a time.

I don't agree. Rather what are you hearing is a request that code should appear
in master branch on GitHub with reasonable time delay.

There are two options, make bpf.tcpdump.org sync with GitHub after every commit
or do development on GitHub only. Or the other way around, I don't care. But 
given
questionable reliability of bpf.tcpdump.org (IIRC there were numerous outages
for longer time periods in the past) I'd prefer GitHub.

I don't care what people do in their private repos, but having two "main" repos
for tcpdump/libpcap is confusing and doesn't bring any benefit whatsoever. Or am
I missing some obvious benefit of current solution.

Michal
> 
> So I guess we should remove it from git, and go back to CVS?
> 
> -- 
> ]   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] Official patches for CVE-2014-8767/CVE-2014-8768/CVE-2014-8769?

2014-11-25 Thread Michal Sekletar
On Tue, Nov 25, 2014 at 09:52:59AM +0100, Romain Francoise wrote:
> On Mon, Nov 24, 2014 at 11:26:06AM -0800, Michal Zalewski wrote:
> > I didn't request one, but probably. RH or Debian folks can likely just
> > assign one from their pools.
> 
> I can ask the Debian security team to assign one, or we can ask
> cve-assign@mitre directly. Or perhaps the other Michal can get one via
> internal Red Hat channels?

I will contact Red Hat SRT to look into that.

Michal

> 
> -- 
> Romain Francoise 
> http://people.debian.org/~rfrancoise/
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers


Re: [tcpdump-workers] bpf.tcpdump.org vs github

2014-11-25 Thread Michal Sekletar
On Mon, Nov 24, 2014 at 10:01:11PM -0500, Michael Richardson wrote:
> 
> okay, can we start again.
> I would appreciate some clear data and clear complaints.  
> 
> This is what I heard:
>  a) which is "master", bpf or github?

There are commits on github/master which are not on bpf. We already have
maintenance branch for 4.7 but there was no release yet. No commit on master has
tcpdump-4.7 tag. This is very confusing.

>  b) bpf is unreliable.

I mean an outage for hour or two and regular maintaince windows are
fine but if site is unreachable for days without prior notice then it is
unreliable in my book.

>  c) there is some issue (please explain more) with bpf.tcpdump.org
>  experiencing auto-merging difficulties.

In my opinion you are putting this mildly. I am sorry, but current situation 
with
tcpdump/libpcap git is very unfortunate.
Why auto-merging doesn't work I can't tell. I have no idea who is an admin of
bpf and what cron job doing the merge actually does.

>  d) this CVE process has been botched (I said this, and I take
>  responsability for this)

It could have been much less painful if all of the above was not the case.

> 
> before I propose some solution/policy/adjustment, I want to make sure that
> I've heard all the issues.

I don't follow, you don't like the idea to use GitHub then why we encourage
people to use it as tool for contributing to the project.

Michal

> 
> -- 
> ]   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] Official patches for CVE-2014-8767/CVE-2014-8768/CVE-2014-8769?

2014-11-25 Thread Michal Sekletar
On Tue, Nov 25, 2014 at 03:43:21PM +0100, Michal Sekletar wrote:
> On Tue, Nov 25, 2014 at 09:52:59AM +0100, Romain Francoise wrote:
> > On Mon, Nov 24, 2014 at 11:26:06AM -0800, Michal Zalewski wrote:
> > > I didn't request one, but probably. RH or Debian folks can likely just
> > > assign one from their pools.
> > 
> > I can ask the Debian security team to assign one, or we can ask
> > cve-assign@mitre directly. Or perhaps the other Michal can get one via
> > internal Red Hat channels?
> 
> I will contact Red Hat SRT to look into that.

I got a response from a member of Red Hat's SRT stating that since the issue was
already reported publicly they can not assign CVE number. If we want to request
CVE number we should either write to oss-security list or ask MITRE directly.

Michal

> 
> Michal
> 
> > 
> > -- 
> > Romain Francoise 
> > http://people.debian.org/~rfrancoise/
> ___
> tcpdump-workers mailing list
> tcpdump-workers@lists.tcpdump.org
> https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers


Re: [tcpdump-workers] bpf.tcpdump.org vs github

2014-11-25 Thread Michal Sekletar
On Tue, Nov 25, 2014 at 01:12:18PM -0500, Michael Richardson wrote:
> 
> Michal Sekletar  wrote:
> >> okay, can we start again.  I would appreciate some clear data and
> >> clear complaints.
> >> 
> >> This is what I heard: a) which is "master", bpf or github?
> 
> > There are commits on github/master which are not on bpf. We already
> > have maintenance branch for 4.7 but there was no release yet. No commit
> > on master has tcpdump-4.7 tag. This is very confusing.
> 
> Right, but the idea was supposed to be that we DO NOT PUBLISH the fault until
> after you guys (the distros) actually have a package.So, this is ENTIRELY
> ON PURPOSE.   Are you saying that you'd prefer to have a zero-day exploit?

Disregarding security patches, those two git trees are out-of-sync anyway. If I
understand current state correctly, then whatever is pushed to GH must be pull 
to
bpf manually. Other way around somewhat works.

> 
> >> b) bpf is unreliable.
> 
> > I mean an outage for hour or two and regular maintaince windows are
> > fine but if site is unreachable for days without prior notice then it
> > is unreliable in my book.
> 
> I am unaware of it being unreachable for more than a Sunday afternoon to
> Monday morning; and that instability with power was solved.

I was also referring to other occurrences in the past. IIRC buildbot was sending
emails to workers multiple times that build is failing and reason at the time
was bpf server unreachability.

> 
> >> before I propose some solution/policy/adjustment, I want to make sure
> >> that I've heard all the issues.
> 
> > I don't follow, you don't like the idea to use GitHub then why we
> > encourage people to use it as tool for contributing to the project.
> 
> github has lots of nice features.
> 
> Maybe we should only use github --- certainly when I first proposed github,
> many people were uncertain about it --- it was too new, and we were too
> experienced with sourceforge coming and going to want to sign up for another
> disaster.

GitHub or something else, I will let this decision to you, core developers. All
I am saying is that having to "master" trees is sub-optimal, confusing and adds
needless work to people.

Michal

> 
> -- 
> ]   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] Libpcap timeout settings in tcpdump - too long when printing to a terminal?

2015-01-09 Thread Michal Sekletar
On Thu, Jan 08, 2015 at 06:57:08PM -0800, Guy Harris wrote:
> With TPACKET_V3 support, Linux users are discovering what those of us using 
> BSD-flavored OSes have known for quite a while:
> 
>   
> http://askubuntu.com/questions/570885/can-tcpdump-on-ubuntu-14-04-show-packets-in-real-time
> 
> Tcpdump uses a timeout of 1 second when opening a capture device; this can, on
> platforms that do BPF-style buffering, cause a 1-second delay before packets
> show up.  TPACKET_V3 is the first Linux capture mechanism to do BPF-style
> buffering, so when a Linux user switches to a distribution version that
> introduces a kernel that supports TPACKET_V3 and a libpcap that uses
> TPACKET_V3, they'll start seeing delays that they haven't seen before.

Is there any rational behind 1s value. Not saying it is wrong, just curious.

> 
> The longer timeout can reduce capturing overhead, and if you're capturing a
> high volume of traffic to a file, it's probably the right timeout to have.
> If, however, you're printing packets to the console, you're probably doomed if
> it's a high volume of traffic, and may want less of a delay if it's a low
> volume of traffic.

Always there will be cases in which default setting are just not good enough. I
think that users doing high volume captures are minority so I'd not optimize
defaults for them.

> 
> Should we reduce the timeout if -w isn't specified - or do so if -w isn't
> specified *and* if we're outputting to a terminal (isatty(1) returns a
> non-zero value)?  Should we use immediate mode if libpcap supports it?  Should
> we offer a command-line option to override the default?  (I'd prefer to have
> the default be appropriate for most cases, which may mean a different default
> if printing packets or if printing them to the console rather than a file,
> but, in addition to that, a command-line option to allow more sophisticated
> users to tweak the timeout might be useful.)

I don't think using immediate mode is the right thing to do, because it defeats
the purpose of buffering done by kernel.

Can't we use new default timeout value (lower) if we detect TPACKET_V3, so we 
don't
defeat the purpose of buffering entirely but delay is short enough that output
looks realtime-ish to human observer looking at the console. If we are dumping
to savefile we should use higher value.

Michal

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


Re: [tcpdump-workers] Work on development

2015-05-11 Thread Michal Sekletar
On 05/08/2015 06:53 PM, Jesse Johnson wrote:

> I would like to put some effort into the code base.

Much appreciated.

> What are we using to edit the code and submit changes? Any special rules for 
> submitting changes?

To work on tcpdump/libpcap you don't need any specialized tools. Basic
tools like code editor (vim, emacs), C compiler, GNU Make and GNU
autotools are pretty much all you need. SCM we use is git. You can find
current master branches of tcpdump and libpcap here,

https://github.com/the-tcpdump-group

Changes are committed to your own fork on GitHub and once you are happy
with your patch you can submit Pull Request. If you are new to GitHub
here is the link where you can read how does the basic workflow looks like.

https://guides.github.com/introduction/flow/

Michal


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


Re: [tcpdump-workers] how many stable branches to have

2015-05-25 Thread Michal Sekletar
On 05/21/2015 08:16 PM, Michael Richardson wrote:

> I have no problem with having lts- branches created for distros, and I'd
> rather do that than have "old stable".  I'd rather call them something like:
>wheezy-4.7
> or centos7-4.7

Clearly having CentOS branch upstream would make my life easier,
nevertheless I don't think that branches named after possible downstream
users are good idea.

Instead I propose we should consider scheme used by Linux kernel, i.e.
having {tcpdump,libpcap}-$version-stable and
{tcpdump,libpcap}-$version-longterm branches.

On a related subject...If upstream decides to have some branches marked
as stable/longterm, then IMHO, also the process for merging patches
needs to be modified for those branches. E.g. pull request needs to get
at least two ACKs from core maintainers to get in.

Michal

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


Re: [tcpdump-workers] how many stable branches to have

2015-05-26 Thread Michal Sekletar

On 05/26/2015 11:46 AM, Francois-Xavier Le Bail wrote:


AFAIK, This is not the scheme used by the linux kernel.
they don't have '-stable' or '-longterm' in their names as these are
moving 'attributes' given on the main page of kernel.org.


You are right, those really are attributes.



I propose this:
We could give an "End of Life" date for each release branches.
This mean that after this date, the tcpdump group would not update any
more the branch.


Having clearly defined EoL is a good idea. However I think that some 
releases should be picked and supported for longer periods of time. For 
example on kernel.org there is still long-term branch for 2.6.32 kernel.


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


Re: [tcpdump-workers] Multiple interface listening modification

2015-06-04 Thread Michal Sekletar

On 06/04/2015 07:28 AM, Tugrul Erdogan wrote:


I am using libpcap 1.7.3 version and I need to listen multiple interface by
same user process call. I am planning to patch libpcap to be able to use a
socket array which will be attached different interfaces.


Can't you just pcap_open more interfaces and for each pcap_t* you get 
call pcap_fileno which will return back file descriptor for that 
capture. Then you can use select/epoll to multiplex on those descriptors.


Michal

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