Gerald Combs wrote:
Stephen Fisher wrote:
On Thu, Sep 27, 2007 at 12:04:13PM -0400, Jeff Morriss wrote:
Could other *NIX users test tshark to see if it works (I'll see in a
while if the buildbots are happy about it)?
Tshark works fine now on MacOS X. Thanks!
It's working for me on Ubuntu, OS X, and Solaris, except for writing to stdout.
Running "tshark -w -" in each case doesn't produce any output. Writing directly
to a file works fine.
Printing out the g_log's says:
Capture.128: sync_pipe_start
Capture.128: CAPTURE OPTIONS :
Capture.128: CFile : 0x(nil)
Capture.128: Filter :
Capture.128: Interface : eth0
Capture.128: Interface Descr : eth0
Capture.128: SnapLen (0): 65535
Capture.128: Promisc : 1
Capture.128: LinkType : -1
Capture.128: SavingToFile : 1
Capture.128: SaveFile : -
Capture.128: RealTimeMode : 1
Capture.128: ShowInfo : 1
Capture.128: QuitAfterCap : 0
Capture.128: MultiFilesOn : 0
Capture.128: FileDuration (0): 60
Capture.128: RingNumFiles (0): 0
Capture.128: AutostopFiles (0): 1
Capture.128: AutostopPackets (0): 0
Capture.128: AutostopFilesize(0): 1024 (KB)
Capture.128: AutostopDuration(0): 60
Capture.128: ForkChild : -1
Capture.128: read 3 length error, required 12825249 > len 4096, indicator: 4294967252
(null).16: Unknown message from dumpcap, try to show it as a string: Ôò¡
Capture.128: sync_pipe_input_cb: error reading from sync pipe
Capture.128: sync_pipe_wait_for_child: wait till child closed
Capture.128: sync_pipe_wait_for_child: capture child closed
(null).128: input pipe closed
It looks like dumpcap is taking tshark's command literally and sending
stuff out its stdout but its stdout is tshark's communication pipe to it(?).
My guess is we'd need to intercept an output file of "-" and... Get
another fd/pipe between tshark and dumpcap to transfer the actual
packets? (I'm out of time for now, maybe I can look at it again later.)
