It seems this is related to a permission issue associated with destination directory.  Once the permissions were changed or another directory was selected, it worked ok.

That's a *REALLY* bad error message for a permission problem, and should be fixed.  What was the permissions problem, so we can try to reproduce the problem and get it to report a better error?

Is the following related to the reported problem ?

  I just noticed today that on Linux that if 'tshark -i foo -w foo.pcap' is executed (non-root) where dumpcap does *not* have suid then tshark just exits without the error message expected from dumpcap (and the child process is gone).

dumpcap -i foo -w foo.pcap does give the expected error message.

(This is the current reason why the Buildbot 'test' stuff is failing on Ubuntu since the tests are using the uninstalled dumpcap).

Bill

Are you seeing that with current SVN tcpdump?  I tried it on Ubuntu 7.10 and got

$ ./tshark -i eth0 -w /etc/foo.pcap
Capturing on eth0
tshark: The capture session could not be initiated (socket: Operation not permitted).
Please check to make sure you have sufficient permissions, and that you have the proper interface or pipe specified.

OK: digging further into this I've determined the following so far (having run out of any more time today for further digging):

Summary
-------
1. perror() output from a child dumpcap seems to cause tshark (and wireshark ?)
   to ignore the output (and following output ?)

2. In my Fedora 8 environment, cap_set_proc() in dumpcap seems to have some
   problem (which causes a perror()).

Details
-------
1. My env: Fedora 8

2. Wireshark: latest SVN installed to /usr/local/bin

  [wsh-svn]$ ls -l /usr/local/bin/tshark /usr/local/bin/dumpcap
  -rwxr-xr-x 1 root root 118431 2008-02-19 17:27 /usr/local/bin/dumpcap
  -rwxr-xr-x 1 root root 672048 2008-02-19 17:27 /usr/local/bin/tshark

  ##Note Ihat I've removed suid on dumpcap.

  ## dumpcap
  [wsh-svn]$ /usr/local/bin/dumpcap -i foo -w foo.pcap
  capset(): Operation not permitted
  The capture session could not be initiated (socket: Operation not permitted).
  Please check to make sure you have sufficient permissions, and that you have
  the proper interface or pipe specified.

    ##Note: "Capset(): Operation not permitted" above comes from a
    ##       perror() in dumpcap

  ## tshark
  [wsh-svn]$ /usr/local/bin/tshark -i foo -w foo.pcap
  Capturing on foo
  ## Note no addt'l err msg text: See below for probable reason
  ## Also: the above tshark output is exactly what is currently happening
  ##  in the Ubuntu buildbot test faliure.

3. Wireshark: latest svn plus:
   - enable all tshark g_log warn, debug, etc
   - add 1 line of g_log output in capture_sync (see below)
       to verify actual dumpcap being called by tshark.

   Installed *locally*

  [wsh-svn]$ ls -l ~/local-wireshark/bin/tshark ~/local-wireshark/bin/dumpcap
  -rwxr-xr-x 1 wmeier wmeier 118431 2008-02-21 13:25 \
                  /home/wmeier/local-wireshark/bin/dumpcap
  -rwxr-xr-x 1 wmeier wmeier 671930 2008-02-21 13:25 \
                  /home/wmeier/local-wireshark/bin/tshark

   ## I've again removed suid from dumpcap (altho not really relevant
   ##   in this case)

  ## dumpcap
  [wsh-svn]$ ~/local-wireshark/bin/dumpcap -i foo -w pcap.cap
  capset(): Operation not permitted
  The capture session could not be initiated (socket: Operation not permitted).
  Please check to make sure you have sufficient permissions, and that you have 
  the proper interface or pipe specified.

  ## tshark
  [wsh-svn]$ ~/local-wireshark/bin/tshark -i foo -w pcap.cap
  Capturing on foo
  (process:22804): Capture-DEBUG: sync_pipe_start
  (process:22804): Capture-DEBUG: CAPTURE OPTIONS    :
  (process:22804): Capture-DEBUG: CFile              : 0x(nil)
  (process:22804): Capture-DEBUG: Filter             :
  (process:22804): Capture-DEBUG: Interface          : foo
  (process:22804): Capture-DEBUG: Interface Descr    : foo
  (process:22804): Capture-DEBUG: SnapLen         (0): 65535
  (process:22804): Capture-DEBUG: Promisc            : 1
  (process:22804): Capture-DEBUG: LinkType           : -1
  (process:22804): Capture-DEBUG: SavingToFile       : 1
  (process:22804): Capture-DEBUG: SaveFile           : pcap.cap
  (process:22804): Capture-DEBUG: RealTimeMode       : 1
  (process:22804): Capture-DEBUG: ShowInfo           : 1
  (process:22804): Capture-DEBUG: QuitAfterCap       : 0
  (process:22804): Capture-DEBUG: MultiFilesOn       : 0
  (process:22804): Capture-DEBUG: FileDuration    (0): 60
  (process:22804): Capture-DEBUG: RingNumFiles    (0): 0
  (process:22804): Capture-DEBUG: AutostopFiles   (0): 1
  (process:22804): Capture-DEBUG: AutostopPackets (0): 0
  (process:22804): Capture-DEBUG: AutostopFilesize(0): 1024 (KB)
  (process:22804): Capture-DEBUG: AutostopDuration(0): 60
  (process:22804): Capture-DEBUG: ForkChild          : -1
  (process:22804): Capture-DEBUG: argv[0]: \
                    /home/wmeier/local-wireshark/bin/dumpcap  ## (added)
(process:22804): Capture-DEBUG: read 7 length error, \
                    required 6385779 > len 4096, indicator: 99

** (process:22804): WARNING **: Unknown message from dumpcap, \
            try to show it as a string: capset(): Operation not permitted
E
(process:22804): Capture-DEBUG: sync_pipe_input_cb: error reading from sync pipe
(process:22804): Capture-DEBUG: sync_pipe_wait_for_child: wait till child closed
(process:22804): Capture-DEBUG: sync_pipe_wait_for_child: capture child closed
** (process:22804): DEBUG: input pipe closed

So: I see two problems:

1. perror() output from child dumpcap causes "Unknown message" in tshark
   This message is *only* seen if tshark g_logging for Warnings enabled.

   (This message should probably be a g_error ?)

2. When running w/o privileges in my environment dumpcap has problems 
   to do with capability handling ?
   (cat_set_proc & etc is new to me; I can test further tomorrow if
    needed).

Bill

I'm currently in the process of fixing the dumpcap cases where 
messages to stderr from dumpcap running in child mode must be written directly or indirectly via pipe_write_block.

This should enable various dumpcap errors to be displayed OK by wireshark and tshark when dumpcap is called from same.

[I now understand things are a bit more complicated than I first thought :)  ]

Results of further analysis: 

1. The problem as originally reported exists and can be seen by starting a wireshark capture to a file in a directory for which the user does not have write permission.

The popup window says only: "Child capture process exited: exit status 2"

Stderr shows:
16:34:47          Warn Unknown message from dumpcap, try to show it as a string: Error testing whether capture file is a pipe: Permission denied"

(Would a user always see the stderr output someplace ??).

2. The essence of the problem: When dumpcap runs in child mode (-Z), any messages output by dumpcap to stderr which are not in the special <strlen><string> format
will cause wireshark to dump the message to the log (g_warning) and not process the message (ie: show it in a warning pop-up).

(2a: For tshark the situation is worse: any non-specially-formatted error messages output by dumpcap to stderr will not appear at all since tshark is suppressing the g_warning messages caused by the 'invalid messages'. Note that 'write file permissions' issues do not cause a problem in tshark since the file permissions checking is apparently still done in tshark).

3. Looking at dumpcap: there are a number of messages output directly to stderr including those from errors while processing the command-line arguments. Many "should not happen" but there are a few (as above) which *can* happen during normal use of dumpcap by wireshark & tshark. In some cases these messages are output before dumpcap has even determined if it is running as a child such that (for the current code) it is too early to even determine if the 'special format' messages are required.

4. So: what's a fix ??

   I've not really worked on the "privilege separation" effort so I don't
   really understand the details of this code; 
   However a solution might be as follows:

a. Determine immediately upon dumpcap start-up whether dumpcap is running as a child. How to do this ? pre-parse the cmd-line args ? isapipe somehow ?

b. All dumpcap stderr messages (whether perror() or cmdarg_err() or ...
   must then use the special format if dumpcap is running as a child.

5. The above seems a bit messy; 
   Is there another approach ? A separate channel for the "special" messages ?
   
Would a quick and dirty fix be to put the "trying to show text ..." text in the pop-up when an 'invalid message' is received ?

============

On a separate note: I propose that tshark should at least:
Determine the default log levels for which to do output based upon the prefs (the same way as is done in wireshark).

Since the default g-log levels include "warning" tshark will output at least  *something* when dumpcap outputs a "non-specially-formatted" message when running as a tshark child.

Is there any reason that tshark currently doesn't have warning messages enabled?

Thoughts ? Comments ?

BTW, it might be that if dumpcap doesn't run as root, it can't do a capset() to request the capabilities it wants, so, on Linux, it has to run set-UID root in any case.

>  When I click on Start I receive a popup box that
> states "Child capture process exited: exit status 2".

Fixed inSVN #24446. 

A real error message now appears in a popup box
when there is a permissions problem with the specified
output directory/file.

Note that this problem apparently occurred whenever an output file was specified
which could not be opened for writing (whether or not the 'multiple files' 
option was chosen.

Thanks for your report !