Red Hat Bugzilla – Full Text Bug Listing
|Summary:||X clients have X protocol errors when connecting to X-org server through openssh|
|Product:||[Fedora] Fedora||Reporter:||Thayne Harbaugh <thayne>|
|Component:||openssh||Assignee:||Nalin Dahyabhai <nalin>|
|Status:||CLOSED NOTABUG||QA Contact:||Brian Brock <bbrock>|
|Version:||rawhide||CC:||chris, gasi, xgl-maint|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2004-11-17 11:38:57 EST||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
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() function.) [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): xorg-x11-6.7.0-7.2 How reproducible: Always 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-188.8.131.523-5, ethereal-0.10.6-1): 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 fine. -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 xorg-x11-6.8.1-12 openssh-3.9p1-7 nedit-5.4-3
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.