[tcpdump-workers] tcpslice maintainer
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)
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
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?
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
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
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
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
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?
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?
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?
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
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?
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
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?
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
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
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
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
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
