> 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
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
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
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
>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
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
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
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