Re: pcap_t not writeable on OpenBSD

[Guy Harris <guy () alum mit edu>]

On Jan 10, 2012, at 3:15 PM, Fernando Gont wrote:

> I would expect that if there are no buffers available, pcap_inject() or
> blocks, rather than silently fail.

"Blocks" and "silently fails" aren't the only alternatives; "returns -1 and sets errno to an error such as ENOBUFS" is 
a third alternative.

What pcap_inject() does is call some underlying OS routine, so its behavior reflects what the underlying OS routine 
does.  If the underlying OS doesn't expose a way for pcap_inject() to wait for buffers to be available, there's not 
much else it can do.

> (i.e., how do I control the rate at
> which I'm sending? how do I know if I should be retransmitting? etc.)

So what is it you're trying to do here?

If it's network flooding as part of a test, then presumably what you're trying to avoid is lots of CPU wasted on 
write()/sendmsg()/etc. calls that fail due to insufficient buffer space being available.  To avoid that you'd could try 
using non-portable mechanisms to determine the speed of the network and rate-limit your sending based on that, but 
that's not necessarily sufficient to keep you from dropping packets - just because you're on a 1Gb Ethernet, that 
doesn't mean you can, all by yourself, pump out 1Gb/s worth of packet data onto that Ethernet.  You might have to 
develop some mechanism to detect packets dropped due to insufficient buffer space (*if* the OS on which you're running 
supports that) and use that in some fashion as a signal to reduce the rate at which you're sending packets.  As the 
rate at which you can send packets might vary over time, you might have to come up with a way to recover if the network 
becomes less congested.-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.