Re: pcap_t not writeable on OpenBSD

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

Hi, Guy,

On 01/10/2012 10:43 PM, Guy Harris 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.

Agreed.



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

Simply put:
I have a list of addresses that I need to test from time to time to see
if they are "alive". Each address has an associated "last probed" and
"last seen" timestamp.

So I call select() with a timeout. If there are packets to read, I
process the incoming packets and update the corresponding "last seen" if
appropriate. If an address has been non-responsive for a long time, I
delete it. If it has been a long time since I "last probed" an address I
send a probe packet, etc.

The point is that I shouldn't block on any call, since that would
prevent the app from doing any of the other tasks it needs to do.


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

It's a daemon that monitor network traffic, and it's meant to be
lightweight. -- So I *do* want to avoid wasting lots of CPU time on
failed calls. However, if pcap_ineject() does fail when there are no
buffers or the like (i.e., the packet would be discarded even before it
hits the wire), that would still be good enough: I could implement
something along the lines of "do not retry to pcap_inject() till 500ms
from the last error".


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

In this particular case, the app is meant to monitor addresses from the
local network... So if my packet does hit the wire, chances are that it
does get to its intended destination.


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

Yes, for a WAN, things get tricky (I still have to tackle that problem
for another app). But in this case, I simply want to be able to tell
whether my packet hit the wire or not (i.e., have pcap_inject() block or
return an error if the packet was discarded before it hit the wire).
Will run a test now, but: Is this the case already, or might there be OS
on which pcap_inject() and the like could silently fail?

Thanks!

Best regards,
-- 
Fernando Gont
e-mail: fernando () gont com ar || fgont () si6networks com
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1



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