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.
