[zorton@whitechapel on ttyp3] [11:41 AM]
[~]which ssh
/sw/bin/ssh
[zorton@whitechapel on ttyp3] [11:41 AM]
[~]ssh -v
OpenSSH_3.9p1, OpenSSL 0.9.7d 17 Mar 2004
usage: ssh [-1246AaCfghkMNnqsTtVvXxY] [-b bind_address] [-c cipher_spec]
           [-D port] [-e escape_char] [-F configfile] [-i identity_file]
           [-L port:host:hostport] [-l login_name] [-m mac_spec] [-o option]
           [-p port] [-R port:host:hostport] [-S ctl] [user@]hostname [command]
[zorton@whitechapel on ttyp3] [11:41 AM]
[~]alias ssh
alias ssh='ssh -A -X'
[zorton@whitechapel on ttyp3] [11:41 AM]
[~]ssh steamroller

[zorton@steamroller on 3] [11:34 AM]
[~]sudo ethereal
The program 'ethereal' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadWindow (invalid Window parameter)'.
  (Details: serial 123 error_code 3 request_code 38 minor_code 0)
  (Note to programmers: normally, X errors are reported asynchronously;
   that is, you will receive the error a while after causing it.
   To debug your program, run it with the --sync command line
   option to change this behavior. You can then get a meaningful
   backtrace from your debugger if you break on the gdk_x_error() function.)
[zorton@steamroller on 3] [11:34 AM]
[~]exit
logout
Connection to steamroller closed.

[zorton@whitechapel on ttyp3] [11:42 AM]
[~]/usr/bin/ssh -X steamroller

[zorton@steamroller on 3] [11:34 AM]
[~]sudo ethereal
[zorton@steamroller on 3] [11:34 AM]
[~]work's just fine

[zorton@steamroller on 2] [11:43 AM]
[~]sudo ethereal
debug1: client_input_channel_open: ctype x11 rchan 3 win 65536 max 16384
debug1: client_request_x11: request from 127.0.0.1 54805
debug2: fd 8 setting O_NONBLOCK
debug3: fd 8 is O_NONBLOCK
debug1: channel 1: new [x11]
debug1: confirm x11
The program 'ethereal' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadWindow (invalid Window parameter)'.
  (Details: serial 123 error_code 3 request_code 38 minor_code 0)
  (Note to programmers: normally, X errors are reported asynchronously;
   that is, you will receive the error a while after causing it.
   To debug your program, run it with the --sync command line
   option to change this behavior. You can then get a meaningful
   backtrace from your debugger if you break on the gdk_x_error() function.)
debug2: channel 1: rcvd eof
debug2: channel 1: output open -> drain
debug2: channel 1: obuf empty
debug2: channel 1: close_write
debug2: channel 1: output drain -> closed
debug1: channel 1: FORCE input drain
debug2: channel 1: ibuf empty
debug2: channel 1: send eof
debug2: channel 1: input drain -> closed
debug2: channel 1: send close
debug3: channel 1: will not send data after close
[zorton@steamroller on 2] [11:44 AM]
[~]debug3: channel 1: will not send data after close
debug2: channel 1: rcvd close
debug3: channel 1: will not send data after close
debug2: channel 1: is dead
debug2: channel 1: garbage collecting
debug1: channel 1: free: x11, nchannels 2
debug3: channel 1: status: The following connections are open:
  #0 client-session (t4 r0 i0/0 o0/0 fd 5/6 cfd -1)
  #1 x11 (t4 r3 i3/0 o3/0 fd 8/8 cfd -1)

debug3: channel 1: close_fds r 8 w 8 e -1 c -1