Re: Libpcap corrupts output

[Cove Schneider <cove () wildpackets com>]

Guy Harris wrote:
> 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.

I believe it's 1 here, the other end of the pipe is handled by openssh 
and from looking at the source it appears its pipe is set to non-blocking.

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

My apologies if my original query was offensive, that wasn't my 
intention. Anyway, this is why I asked:

From the BSD man page for write():

     When using non-blocking I/O on objects such as sockets that are 
subject
     to flow control, write() and writev() may write fewer bytes than
     requested; the return value must be noted, and the remainder of 
the oper-
     ation should be retried when possible.

I'm not sure that's a fair assumption for other OS's but that's what 
appears to happen under Linux too.

So I guess my predicament is that I'd like to stream the packets over an 
ssh connection and apparently ssh uses a non-blocking pipe to get the 
stdout from programs. There are some other ways I could work around 
this, but they are rather clumsy.

Any thoughts or suggestions would be appreciated.

Thanks,

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