Re: Libpcap corrupts output

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

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

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