Cove Schneider wrote:
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 b
On May 2, 2006, at 14:16 , Guy Harris wrote:
(I'm not sure this message made it to the list; it never showed up
in my mailbox, at least. I'm resending it. However, it appears to
have been recorded in the duplicate-message detector, so it at
least got that far; I'm adding this extra text i
(I'm not sure this message made it to the list; it never showed up in my
mailbox, at least. I'm resending it. However, it appears to have been
recorded in the duplicate-message detector, so it at least got that far;
I'm adding this extra text in part in the hopes of defeating the
duplicate-me
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 loo
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 t
Hello,
I have a problem where my app pipes the output of tcpdump over a
network connection and on slower connections it appears that libpcap
sometimes doesn't write out the whole packet data segment. I believe
this is being caused by the lack of error checking in pcap_dump():
(0.9.4) save
