Fwd: Re: select()ing on the underlying descriptor of a pcap_t

[Fernando Gont <fernando () gont com ar>]

Hi, Folks,

FYI.

(A patch has already been implemented and should be committed any time
soon).

Thanks,
Fernando




-------- Original Message --------
Subject: Re: select()ing on the underlying descriptor of a pcap_t
Date: Wed, 11 Jan 2012 09:29:07 +0100
From: Claudio Jeker <cjeker () diehard n-r-g com>
To: tech () openbsd org

On Tue, Jan 10, 2012 at 07:58:29PM -0800, Philip Guenther wrote:
> On Tue, Jan 10, 2012 at 4:10 PM, Fernando Gont <fernando () gont com ar> wrote:
> ...
> > However, in OpenBSD (and apparently NetBSD, too) the underlying
> > descriptor for a pcap_t is never writeable.
> >
> > If anything, it'd seem that having select() always report that the
> > pcap_t descriptor is "writeable" is a better choice.
> >
> > That said, it would be great to have select() return "writeable" with
> > similar semantics to those of the Sockets API, such that one knows when
> > it's "safe" to pcap_inject() packets...
>
> It appears to me that it's always "safe", that write() on a bpf will
> never block, so I think I agree that it should always show itself to
> poll() as writable.  Now, it may be that the packet will be thrown
> away if the output queue is backed up, but that's not the question
> that poll() asks generally, so that's fine.

And this machtes behaviour of other network sockets (like UDP and RAW IP)
because those are as well always writeable even though the network stack
may later on happily drop the packet because of full queues.
Only streaming sockets (or reliable dgram sockets) are able to block on
write waiting for packets to drain from the socket buffer.

So yes, marking bpf descriptors always writeable makes sense.
-- 
:wq Claudio


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