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

2014-09-13 Thread Denis Ovsienko
> How about: > sudo pktcap - | pktdump - Although architecturally cleaner and SMP-friendlier than now, to survive busy everyday end-users this approach would greatly benefit from a single front-end process that would launch the other binaries, connect them together and properly distribu

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

2014-09-12 Thread Guy Harris
On Sep 12, 2014, at 4:08 PM, Michael Richardson wrote: > > Michal Sekletar wrote: >> 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 >> v

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

2014-09-12 Thread Michael Richardson
Michal Sekletar wrote: > 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 co

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

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

2014-09-06 Thread Denis Ovsienko
>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". I don't fully unde

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

2014-09-03 Thread Guy Harris
On Sep 3, 2014, at 4:44 PM, Michael Richardson wrote: > My logic is that if we have the switch/env-var to force libpcap to use a > particular method, that permits not only benchmarking, but also isolation of > bugs easier. OK, I'd vote for an environment variable, so as not to 1) add a

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

2014-09-03 Thread Michael Richardson
Guy Harris wrote: > On Sep 3, 2014, at 12:34 PM, Michael Richardson > wrote: >> It seems that we might need more patches to better select Linux memory >> mapped packet choices? > I'd prefer a patch that reduces or the removes the *need* to do so, > such as this patch, w

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

2014-09-03 Thread Guy Harris
On Sep 3, 2014, at 12:34 PM, Michael Richardson wrote: > It seems that we might need more patches to better select Linux memory mapped > packet choices? I'd prefer a patch that reduces or the removes the *need* to do so, such as this patch, which I'm in the process of testing (yes, I already

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

2014-09-03 Thread Michael Richardson
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 proje