I have two machines running Gentoo. Ob both, there is a fershly compiled xfree-4.3.0-r5. aterm is v0.4.2-r8, eterm is v When I ssh from one machine to there other (with X11-Forwarding enabled) and start an aterm or xterm, all is well until I try to copy and paste from the terminal to a local running one: $ aterm aterm: XError: Request: 18 . 0, Error: 5 xterm dies like this: $ xterm xterm: warning, error event received: X Error of failed request: BadAtom (invalid Atom parameter) Major opcode of failed request: 18 (X_ChangeProperty) Atom id in failed request: 0x1a3 Serial number of failed request: 140 Current serial number in output stream: 142 $ Pasting *into* such a terminal simply does not work, i.e. nothing it pasted but the terminal keeps running. I've tried recompiling stuff (including xfree and gtk+) to no avail. I'm pretty much out of ideas. emerge info: machine that's running X (from which I ssh) Portage 2.0.50-r1 (default-x86-1.4, gcc-3.3.3, glibc-2.3.3_pre20040207-r0, 2.6.3 ) ================================================================= System uname: 2.6.3 i686 Pentium III (Coppermine) Gentoo Base System version 1.4.3.13p1 Autoconf: sys-devel/autoconf-2.59-r3 Automake: sys-devel/automake-1.8.2 ACCEPT_KEYWORDS="x86 ~x86" AUTOCLEAN="yes" CFLAGS="-march=pentium3 -O3 -pipe" CHOST="i686-pc-linux-gnu" COMPILER="gcc3" CONFIG_PROTECT="/etc /usr/X11R6/lib/X11/xkb /usr/kde/2/share/config /usr/kde/3/s hare/config /usr/lib/mozilla/defaults/pref /usr/share/config /usr/share/texmf/dv ipdfm/config/ /usr/share/texmf/dvips/config/ /usr/share/texmf/tex/generic/config / /usr/share/texmf/tex/platex/config/ /usr/share/texmf/xdvi/ /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/env.d" CXXFLAGS="-march=pentium3 -O3 -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="autoaddcvs ccache sandbox" GENTOO_MIRRORS="http://ftp.freenet.de/pub/ftp.snt.utwente.nl/pub/os/linux/gentoo http://gentoo.tiscali.nl/gentoo/ http://gyroscope.acm.cs.rpi.edu/gentoo/" MAKEOPTS="-j1" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync5.de.gentoo.org/gentoo-portage/" USE="X aalib alsa apm avi berkdb crypt cups dga dvd encode esd exif foomaticdb g dbm gif gnome gphoto2 gpm gtk gtk2 imap imlib java jpeg libg++ libwww mad mikmod mmx motif mozilla moznocompose moznoirc moznomail mpeg mysql ncurses nls oggvor bis opengl oss pam pdflib perl png postgres python quicktime readline sdl slang spell ssl svga tcltk tcpd tetex truetype x86 xml2 xmms xv zlib" Machine running aterm/xterm/eterm (to which I ssh): Portage 2.0.50-r1 (default-x86-1.4, gcc-3.3.3, glibc-2.3.3_pre20040207-r0, 2.6.3) ================================================================= System uname: 2.6.3 i686 Pentium III (Katmai) Gentoo Base System version 1.4.3.13p1 distcc 2.12.1 i686-pc-linux-gnu (protocols 1 and 2) (default port 3632) [enabled] Autoconf: sys-devel/autoconf-2.59-r3 Automake: sys-devel/automake-1.8.2 ACCEPT_KEYWORDS="x86 ~x86" AUTOCLEAN="yes" CFLAGS="-O3 -march=pentium3 -pipe" CHOST="i686-pc-linux-gnu" COMPILER="gcc3" CONFIG_PROTECT="/etc /usr/X11R6/lib/X11/xkb /usr/kde/2/share/config /usr/kde/3/share/config /usr/share/config /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/env.d" CXXFLAGS="-O3 -march=pentium3 -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="autoaddcvs ccache distcc sandbox userpriv usersandbox" GENTOO_MIRRORS="http://ftp.freenet.de/pub/ftp.snt.utwente.nl/pub/os/linux/gentoo/ http://ftp.ibiblio.org/pub/Linux/distributions/gentoo/ http://mirrors.sec.informatik.tu-darmstadt.de/gentoo/" MAKEOPTS="-j5" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync5.de.gentoo.org/gentoo-portage" USE="acpi apache2 apm berkdb crypt cscope cups curl encode exiscan-acl gdbm gif gpm gtk gtk2 idea imap imlib imlib2 java jpeg kde libg++ libwww mad maildir mbox mikmod mng motif moznocompose moznoirc moznomail mpeg mpeg4 mpi mysql ncurses nls oggvorbis openssh pam parse-clocks pcap pdflib pear-db perl php plotutils png python readline skey slang spell sse ssl svga tcpd tiff truetype type1 vanilla vim-with-x x86 xchatnogtk xchattext xml2 zlib" I can provide straces or core files if needed.
Few questions, wether they are relevent or not Im not too sure... 1) Can you produce the same problems when copy/pasting to and from any set of local and remote X11 applications? Or is the problem specific to the terminals? If only terms does this only happen on aterm and xterm or can you produce this on any terminal emulator? 2) Are you using the Middle-Click method for pasting? (does this work locally on both X11 systems? It can be disabled and perhaps there is a mismatch.)
After a little googling... can your strace sshd (manual run is a pain I know but try it please).
First off, your questions: Regarding 1): Pasting *from* any terminal (xterm, eterm, aterm) always yields this error, the destination application, be it another term or Galeons URL bar, does not matter, as far as I was able to find out. I just tried the following: localmachine $ ssh remotemachine remotemachine $ xmessage bla (then marking the "bla" and trying to paste it elsewhere) X Error of failed request: BadAtom (invalid Atom parameter) Major opcode of failed request: 18 (X_ChangeProperty) Atom id in failed request: 0x16d Serial number of failed request: 145 Current serial number in output stream: 147 Seems independent of the application. As for question 2): Yes, C&P works locally on both systems. It used to work across ssh sometime in the past, too. Taking your trace request for sshd as a hint: yes, it might be that updating to 3.8_p1 is the point in time where the trouble started. As far as the trace is concerned, I'd rather not have it lingering in the web (just in case I forgot to delete some pricy-relevant stuff like passwords), I'll send it (compressed) to your e-mail address if you don't mind.
Well I cannot reproduce this error. I Tried several different terminals, and the xmessage test both worked successfully, Im digging my way through the strace, but I havent seen anything obvious yet...
I've just backdated openssh (to 3.7.1_p2-r2) on the remote machine and lo and the remains. Interestingly enough, I have a machine with xfree-4.3.0-r4 and openssh 3.8_p1 which has the same error, so it wasn't introduced r4->r5. As a logical next step, I backdated openssh, too, so I had an older xfree and an older openssh on the remote machine: bug is still there. The next thing, backdating the local xfree, I'll defer until tomorrow, as the compilation takes nearly an hour (I'll let it run while at work). As a last measure of backdating, I'll go to 3.7.1_p2-r2 on the local machine, too. So obviously, this is a bug introduced with 3.8_p1, not one of xfree86 (which wasn't changed during the course of testing).
I just found out that I can't backdate xfree because there is no ebuild available that's older than 4.3.0-r5 except 4.2.1-r4.
I've backdated both remote and local openssh to 3.7.1p2. Lo and behold, the bug is gone. Then I updated the remote (sshd) side to 3.8. Still no error. Update the client to 3.8p1, too: bang. Error is here. Thus, I think digging through that sshd trace might be unfruitful. If you'd like, I'll send you a trace of the client program.
ssh issue, removing xfree from this.
No clue how this one got here, but reassigning to my favorite OpenSSH dude
*** Bug 45169 has been marked as a duplicate of this bug. ***
openssh-3.8.1_p1 (released recently) has the same bug
I had the same problem that forwarded X programms do not work any more since openssh-3.8. Did you tried the hint from "Mark R" in bug 45169 to enable "ForwardX11Trusted yes" in your ssh_config? For me it solved the problem with forwarded X applications.
Yes, that option fixed it for me, thanks a lot. There's still the question as to why non-trutsed forwarding makes *term go wild, but as far as I am practically concerned, this bug is fixed.
.
Just note: I run into this "feature" now (Wed Mar 23 13:24:05 CET 2005). Have anyone some idea how to simplify solution-finding for other users ? BTW, that idea about using untrusted clients sounds good. What a shame it can't be really used .... maybee some copy&paste update to more-secure way is needed.
