Re: Libpcap corrupts output

[Cove Schneider <cove () wildpackets com>]

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 in part in the hopes  
> of defeating the duplicate-message dissector.)
>
> 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?

Sorry, the "other end" is referring to where tcpdump is actually  
running vs.
"this end" where my app is running (on a Win32 machine).

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

Right, I'm not sure something like that is going on... (see my last
paragraph)

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

Of course, that makes sense...

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

My app is a Win32 app, but it effectively does this:

        ssh -T remotemachine "tcpdump -w-"| my_app

Though I'm currently using cryptlib to do the ssh connection. It could
be that cryptlib is exposing a bug in OpenSSH or vice-versa. Using
OpenSSH's client it works fine though, albeit a fair bit slower than
cryptlib's.

So, I tried adding a check before the fwrite() to see if the fd  
(stdout) was
in blocking mode or not, and it was always in blocking mode. So it  
occurred to
me that the failed fwrite() may simply be an interrupted write as  
tcpdump
gets a SIGTERM when the ssh connection is being shutdown. In which  
case I'm
now thinking that the corruption must be happening in either OpenSSH  
or cryptlib.

I'll talk with the SSH folk and see what they say.

Anyway, sorry for all the bother and thanks for all your help. Much  
appreciated.

Cove


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