Bug 129620 - X clients have X protocol errors when connecting to X-org server through openssh
X clients have X protocol errors when connecting to X-org server through openssh
Product: Fedora
Classification: Fedora
Component: openssh (Show other bugs)
i386 Linux
medium Severity high
: ---
: ---
Assigned To: Nalin Dahyabhai
Brian Brock
Depends On:
  Show dependency treegraph
Reported: 2004-08-10 18:47 EDT by Thayne Harbaugh
Modified: 2007-11-30 17:10 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-11-17 11:38:57 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Thayne Harbaugh 2004-08-10 18:47:20 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7)
Gecko/20040625 Epiphany/1.2.6

Description of problem:
X clients have protocol errors and cannot connect to a remote X-org
X11 6.7.0-7.2 server through openssh.  This might be a bug in gdk
because pure Xaw clients connect fine, however the Xaw clients won't
work with Xclipboard copy/paste and sometimes crash at a later time
with bad X events.

[thayne@tubarao ~]$ ssh blaze
Last login: Tue Aug 10 16:26:23 2004 from tubarao.lnxi.com
[thayne@blaze thayne]$ ethereal
The program 'ethereal' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadAtom (invalid Atom parameter)'.
  (Details: serial 10 error_code 5 request_code 18 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()
[thayne@blaze thayne]$command 

This happens with many more programs than ethereal.  It doesn't seem
to be a problem with the X client side (it can be any
distribution/release) - only with the X server side being the one in
Fedora core development.

You can start up a remote X GNU Emacs and won't be able to paste into
it from X server-side clipboard.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. ssh to remote machine
2. start gnome-terminal, ethereal, various programs
3. observe X protocol errors

Actual Results:  [thayne@tubarao ~]$ ssh blaze
Last login: Tue Aug 10 16:38:21 2004 from tubarao.lnxi.com
[thayne@blaze thayne]$ gnome-terminal
Gdk-ERROR **: BadAtom (invalid Atom parameter)
  serial 39 error_code 5 request_code 18 minor_code 0
Gdk-ERROR **: BadAccess (attempt to access private resource denied)
  serial 50 error_code 10 request_code 102 minor_code 0

Expected Results:  A nice gnome-terminal in my X server.

Additional info:
Comment 1 Bill Nottingham 2004-08-11 00:09:10 EDT
You may want to try turning off X security in SSH.
Comment 2 Thayne Harbaugh 2004-08-11 17:18:31 EDT
I'm not sure what you mean by "X security in SSH."  Are you referring
to X11Forwarding?  If so, then that is enabled.  If it wasn't enabled
then *nothing* could connect to the remote X server (I mentioned that
some pure Xaw programs worked fine but didn't work with Xclipboard).
Comment 3 Chris Kuivenhoven 2004-09-04 18:04:16 EDT
Using current rawhide (openssh-3.9p1-3, xorg-x11-,

When I try running ethereal (the test case), with X11Forwarding (ssh
-X localhost) I receive the same errors that Thayne saw.
Interestingly, when I use ssh -Y localhost, instead, everything works

-Chris Kuivenhoven
Comment 4 Herbert Gasiorowski 2004-11-16 10:08:11 EST
I can confirm this for FC3 final and nedit
(and some other other programs):

..$ ssh -X host nedit
NEdit: Converting .nedit file to 5.4 version.
    To keep, use Preferences -> Save Defaults
X Error of failed request:  BadAtom (invalid Atom parameter)
  Major opcode of failed request:  20 (X_GetProperty)
  Atom id in failed request:  0x69
  Serial number of failed request:  20
  Current serial number in output stream:  20

while "ssh -Y host nedit" works!

...$ rpm -q xorg-x11 openssh nedit
Comment 5 Mike A. Harris 2004-11-16 21:19:01 EST
This isn't a bug at all.  openssh changed the way it works, and you
must now invoke it as "ssh -Y" in order to get the same level of
X11 forwarding that "ssh -X" did in previous releases of openssh.

Reassigning to the openssh component for any final comments.
Comment 6 Thayne Harbaugh 2004-11-17 11:38:57 EST
Yep, "ssh -Y" fixes it.  I wish Bill Nottingham had clarified his
comment from 2004-08-11.

Note You need to log in before you can comment on or make changes to this bug.