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.
