Bug 187961

Summary: Ssh-forwarded X11 sessions fail
Product: [Fedora] Fedora Reporter: Otto J. Makela <om>
Component: opensshAssignee: Tomas Mraz <tmraz>
Status: CLOSED CURRENTRELEASE QA Contact: Brian Brock <bbrock>
Severity: medium Docs Contact:
Priority: medium    
Version: 5   
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: ? Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2006-05-28 21:57:49 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
% ssh tigger -vvv > /dev/stdout >& ssh-vvv.txt
none
% ssh tigger -vvv > /dev/stdout >& ssh-vvv.txt none

Description Otto J. Makela 2006-04-04 22:08:16 UTC
Description of problem:
Starting X11 programs on another host from a text session on anoher host
initially work just fine, but after a while fail with magic cookie error.

Version-Release number of selected component (if applicable):
openssh-4.3p2-4

How reproducible:
With time, always.

Steps to Reproduce:
1. Open ssh session with X11 forwarding from x86_64 fc5 machine to another host
(like a i386 linux server)
2. Run software that that will open X11 sessions (like mutt email client using
X11 emacs as the editor)
3. Starting any X11 program will fail after a short while with magic cookie error
  
Actual results:
Error message produced:
Xlib: connection to "localhost:11.0" refused by server
Xlib: Invalid MIT-MAGIC-COOKIE-1 key
emacs: Cannot connect to X server localhost:11.0.
Check the DISPLAY environment variable or use `-d'.
Also use the `xhost' program to verify that it is set to permit
connections from your machine.

Expected results:
Normal X11 program session

Additional info:
Even when X11 forwarding still works, occasionally programs like xemacs fail
with "X11 protocol error" so something is wonky also at this point.

Comment 1 Tomas Mraz 2006-04-05 15:02:26 UTC
I have never seen the first error you mention above. Could you please attach
output from the client when run with -vvv option when the problem happens?
Eventually you could also run the server with -ddd option and attach its output too.

I can occasionally reproduce the second problem however I was never able to
reproduce it when running the client with -vvv options.

I agree that this is really annoying problem but without reproducer it's almost
impossible to fix it.

Also you could try to reproduce it with vanilla openssh compiled yourself and
report it upstream in http://bugzilla.mindrot.org/ if you still can reproduce it.


Comment 2 Otto J. Makela 2006-04-05 23:29:30 UTC
Created attachment 127379 [details]
% ssh tigger -vvv > /dev/stdout >& ssh-vvv.txt

In this session log (stderr from ssh -vvv, interspersed with some stdout
stuff), I open a ssh session from my x86_64 fc5 machine tigger back to itself.
I then start emacs (emacs-21.4-14), the window opens with just the scratch
buffer, I click once on the window and try to paint the default "This buffer is
for notes..." text.
This causes emacs to fail every time with the BadWindow message found in the
log.
I'm beginning to suspect this is actually a X issue?

Comment 3 Otto J. Makela 2006-04-05 23:30:34 UTC
Created attachment 127380 [details]
% ssh tigger -vvv > /dev/stdout >& ssh-vvv.txt

In this session log (stderr from ssh -vvv, interspersed with some stdout
stuff), I open a ssh session from my x86_64 fc5 machine tigger back to itself.
I then start emacs (emacs-21.4-14), the window opens with just the scratch
buffer, I click once on the window and try to paint the default "This buffer is
for notes..." text.
This causes emacs to fail every time with the BadWindow message found in the
log.
I'm beginning to suspect this is actually a X issue?

Comment 4 Otto J. Makela 2006-05-28 21:57:49 UTC
At this time, after the usual fc5 updates, the above error no longer happens!
Wonderful! I think the new xorg-x11 release for x86_64 has fixed this.