Tobias Ulmer wrote:
> On Tue, Sep 22, 2015 at 11:46:08AM -0400, Ted Unangst wrote:
> > Todd C. Miller wrote:
> > > On Mon, 21 Sep 2015 20:13:05 -0400, "Ted Unangst" wrote:
> > >
> > > > We can put a "long" poll() in front of pcap to wait until there are
> > > > packets
> > > > (maybe never if you
Tobias Ulmer wrote:
> On Tue, Sep 22, 2015 at 11:46:08AM -0400, Ted Unangst wrote:
> > Todd C. Miller wrote:
> > > On Mon, 21 Sep 2015 20:13:05 -0400, "Ted Unangst" wrote:
> > >
> > > > We can put a "long" poll() in front of pcap to wait until there are
> > > > packets
> > > > (maybe never if you
On Tue, Sep 22, 2015 at 11:46:08AM -0400, Ted Unangst wrote:
> Todd C. Miller wrote:
> > On Mon, 21 Sep 2015 20:13:05 -0400, "Ted Unangst" wrote:
> >
> > > We can put a "long" poll() in front of pcap to wait until there are
> > > packets
> > > (maybe never if you aren't using pf logging), and the
Todd C. Miller wrote:
> On Mon, 21 Sep 2015 20:13:05 -0400, "Ted Unangst" wrote:
>
> > We can put a "long" poll() in front of pcap to wait until there are packets
> > (maybe never if you aren't using pf logging), and then let the timeout work
> > it's magic.
>
> This:
>
> > + if (poll(
On Mon, 21 Sep 2015 20:13:05 -0400, "Ted Unangst" wrote:
> We can put a "long" poll() in front of pcap to wait until there are packets
> (maybe never if you aren't using pf logging), and then let the timeout work
> it's magic.
This:
> + if (poll(&pfd, 1, INFTIM) == 1) {
will also ma
I think this will help pflogd sleep better at night...
My understanding of the pcap/bpf timeout is that it will always wait that
long, even if packets are received, so that you don't get one read() per
packet. But using this timeout doesn't mean wait forever until you get
something.
We can put a