tcpdump mailing list archives
Re: Libpcap corrupts output
From: Guy Harris <guy () alum mit edu>
Date: Tue, 02 May 2006 14:16:41 -0700
(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-message dissector.)
Cove Schneider wrote:
Guy Harris wrote:Either1) 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.
"Other end" on the machine running tcpdump? Or "other end" on the other end of the network connection? If the latter, that has no effect on the end to which tcpdump is writing. Even if the former, that should have no effect as long as the OS isn't broken and this is being done with a pipe - setting the *receiving* end of the pipe to non-blocking should have no effect on the *sending* end. If it does, that's an OS bug - an application reading from a pipe should be able to run its pipe in non-blocking mode without any effect on the process on the other end of the pipe (most code that would write to a pipe assumes, explicitly or implicitly, that it's writing to something that's blocking - non-blocking I/O is the exception, and applications should only have to deal with it if they explicitly request it).
From the BSD man page for write():When using non-blocking I/O on objects such as sockets that are subjectto flow control, write() and writev() may write fewer bytes thanrequested; 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.
But libpcap isn't "using non-blocking I/O" on the output - it never requests requests non-blocking I/O on the output. It's apparently getting non-blocking I/O shoved down its throat. libpcap shouldn't work around that any more than, say, "grep" should.
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.
So you're doing tcpdump -w - | ssh remotemachine command or something such as that?
Any thoughts or suggestions would be appreciated.
I'd suggest writing a program that checks whether its standard output is in non-blocking mode, and doing nbtest | ssh remotemachine cat and see what it reports. If it reports that the standard output is blocking, report that as a bug to your OS vendor(s). A sample program would be #include <stdio.h> #include <fcntl.h> int main(int argc, char **argv) { int flags; flags = fcntl(1, F_SETFL, 0); printf("Standard output is %s\n", (flags & O_NONBLOCK) ? "non-blocking" : "blocking"); return 0; } - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Current thread:
- Libpcap corrupts output Cove Schneider (Apr 28)
- Re: Libpcap corrupts output Guy Harris (Apr 28)
- Re: Libpcap corrupts output Cove Schneider (Apr 30)
- Re: Libpcap corrupts output Guy Harris (May 02)
- Re: Libpcap corrupts output Cove Schneider (May 02)
- Re: Libpcap corrupts output Guy Harris (May 18)
- Re: Libpcap corrupts output Cove Schneider (Apr 30)
- Re: Libpcap corrupts output Guy Harris (Apr 28)