select()ing on the underlying descriptor of a pcap_t

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

select()ing on the underlying descriptor of a pcap_t

Fernando Gont-2
Hi, folks,

I'm doing I/O multiplexing with a pcap descriptor (select()ing on the
underlying descriptor, to avoid having my app block on libpcap calls).

When it comes to checking for writeability, it turns out that in most
OSes this is basically a noop (the descriptor is always readable). For
example, in FreeBSD and Linux, select() always return the descriptor as
"writeable", without actually performing any real checks on the BPF or
the like.

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

Thoughts?

Thanks!

Best regards,
--
Fernando Gont
e-mail: [hidden email] || [hidden email]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

Reply | Threaded
Open this post in threaded view
|

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

Philip Guenther-2
On Tue, Jan 10, 2012 at 4:10 PM, Fernando Gont <[hidden email]> 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.


Philip Guenther

Reply | Threaded
Open this post in threaded view
|

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

Claudio Jeker
On Tue, Jan 10, 2012 at 07:58:29PM -0800, Philip Guenther wrote:

> On Tue, Jan 10, 2012 at 4:10 PM, Fernando Gont <[hidden email]> 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