Re: Libpcap corrupts output

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

On Apr 28, 2006, at 2:12 PM, Cove Schneider wrote:

> As far as I can tell fwrite() will occasionally write short. I'm  
> assuming because my pipe is "backed up" and libpcap can't write  
> anymore data to it (though I would expect it to block in that case,  
> so I'm not really sure what's causing it to temporarily write short  
> data).

Either

	1) the pipe is or other network connection is in non-blocking mode  
(in which case it *won't* block in that case)

or

        2) there's a bug in the OS on which you're running this.

> Is there any plan to change this behavior?  It would be useful to  
> me if it retried and wrote out the rest of the data.

Is there any plan to change your setup not to use non-blocking  
sockets, or is there any plan by the supplier of your OS to cause  
blocking sockets on your system not to behave like non-blocking  
sockets (if that's the OS bug) or to cause the standard I/O library's  
"fwrite()" on your system to keep writing until everything's written  
out or an I/O error occurs?  I don't know.

Is there any plan to change *libpcap* to retry?  No, as that's not  
its job - that's either write's job or fwrite's job.

Is there any plan to add a new API to let you write to a  
pcap_dumper_t and get an indication of whether that write got an  
error?  Yes, although that won't be usable as a callback for pcap_loop 
() or pcap_dispatch(), as there's no provision for a callback  
returning an error indication.

It would probably be useful to lots of other code on your system,  
too, if write() or fwrite() (whichever of those is at fault here, if  
the pipe or network connection is in blocking mode), so, if that's  
what's happening, you should complain to your OS supplier about this.
-
This is the tcpdump-workers list.
Visit https://lists.sandelman.ca/ to unsubscribe.