Public bug reported:
Binary package hint: gdm
1) $ lsb_release -rd
Description: Ubuntu 8.04.1
Release: 8.04
2) $ apt-cache policy gdm
gdm:
Installed: 2.20.7-0ubuntu1.1
Candidate: 2.20.7-0ubuntu1.1
Version table:
*** 2.20.7-0ubuntu1.1 0
500 http://fi.archive.ubuntu.com hardy-updates/main Packages
100 /var/lib/dpkg/status
2.20.5-0ubuntu3 0
500 http://fi.archive.ubuntu.com hardy/main Packages
3) What you expected to happen
- enabled remote logins using gdmsetup, no other changes. (seems to default to
gdmgreeter) (NB: This might make
your remote session vulnerable to attacks, don't do it if you don't understand
the consequences)
- expected to be able login from a remote Xserver running XDMCP
4) What happened instead
Login screen was not displayed on remote Xserver
My debugging gave the following explanation
When talking to an X server supporting RandR v1.1 (instead of the
current v1.2) gdmgreeter exits before displaying anything. There is no
error message to the user.
With gdm [debug] Enable=True only 2 lines are found in syslog, which
might be related to the problem
gdm[6110]: DEBUG: close_if_needed: Got G_IO_HUP on 9
gdm[6110]: DEBUG: close_if_needed: Got error on 9
However, these lines didn't tell me anything.
Using strace I found that gdmgreeter seems to be culprit:
write(2, "The program \'gdmgreeter\' receive"..., 583) = 583
However fd 2 seems to be /dev/null and I didn't find any information how
to turn on logging.
open("/dev/null", O_RDWR) = 2
Using tcpdump/wireshark I found that the last request sent to the X server is
RandR opcode 8. My X server replies with BadRequest. The Xserver is correct,
because it supports only RandR v1.1 and opcode 8 was added for protocol version
1.2 (see
http://gitweb.freedesktop.org/?p=xorg/proto/randrproto.git;f=randrproto.txt;a=blob)
Actually gdmgreeter queries the RandR version just before the bad
request, but obviously it does not use the version information
appropriately.
I'm not sure how common RandR v1.1 is these days. If the full support
for the old protocol doesn't seem to be worth the effort, some better
logging should be added. Alternatively, could gdmgreeter "fall back" to
gdmlogin if the server supports only the old RandR protocol version?
Workaround: switch to gdmlogin. (Called "plain with facebrowser" in
gdmsetup)
** Affects: gdm (Ubuntu)
Importance: Undecided
Status: New
** Description changed:
Binary package hint: gdm
1) $ lsb_release -rd
Description: Ubuntu 8.04.1
Release: 8.04
2) $ apt-cache policy gdm
gdm:
Installed: 2.20.7-0ubuntu1.1
Candidate: 2.20.7-0ubuntu1.1
Version table:
*** 2.20.7-0ubuntu1.1 0
500 http://fi.archive.ubuntu.com hardy-updates/main Packages
100 /var/lib/dpkg/status
2.20.5-0ubuntu3 0
500 http://fi.archive.ubuntu.com hardy/main Packages
3) What you expected to happen
- enabled remote logins using gdmsetup, no other changes. (seems to default
to gdmgreeter) (NB: This might make
your remote session vulnerable to attacks, don't do it if you don't
understand the consequences)
- expected to be able login from a remote Xserver running XDMCP
4) What happened instead
Login screen was not displayed on remote Xserver
My debugging gave the following explanation
When talking to an X server supporting RandR v1.1 (instead of the
current v1.2) gdmgreeter exits before displaying anything. There is no
error message to the user.
With gdm [debug] Enable=True only 2 lines are found in syslog, which
might be related to the problem
gdm[6110]: DEBUG: close_if_needed: Got G_IO_HUP on 9
gdm[6110]: DEBUG: close_if_needed: Got error on 9
However, these lines didn't tell me anything.
- Using strace if found that gdmgreeter seems to be culprit:
+ Using strace I found that gdmgreeter seems to be culprit:
write(2, "The program \'gdmgreeter\' receive"..., 583) = 583
However fd 2 seems to be /dev/null and I didn't find any information how
to turn on logging.
open("/dev/null", O_RDWR) = 2
Using tcpdump/wireshark I found that the last request sent to X server is
RandR opcode 8. My X server replies with BadRequest. The Xserver is correct,
because it supports only RandR v1.1 and opcode 8 was added for protocol version
1.2 (see
http://gitweb.freedesktop.org/?p=xorg/proto/randrproto.git;f=randrproto.txt;a=blob)
- Actually gdmgreet queries the RandR version just before the bad request,
- but obviously it does not use the version information appropriately.
+ Actually gdmgreeter queries the RandR version just before the bad
+ request, but obviously it does not use the version information
+ appropriately.
I'm not sure how common RandR v1.1 is these days. If the full support
for the old protocol doesn't seem to be worth the effort, some better
logging should be added. Alternatively, could gdmgreeter "fall back" to
gdmlogin if the server supports only the old RandR protocol version?
Workaround: switch to gdmlogin. (Called "plain with facebrwoser" in
gdmsetup)
** Description changed:
Binary package hint: gdm
1) $ lsb_release -rd
Description: Ubuntu 8.04.1
Release: 8.04
2) $ apt-cache policy gdm
gdm:
Installed: 2.20.7-0ubuntu1.1
Candidate: 2.20.7-0ubuntu1.1
Version table:
*** 2.20.7-0ubuntu1.1 0
500 http://fi.archive.ubuntu.com hardy-updates/main Packages
100 /var/lib/dpkg/status
2.20.5-0ubuntu3 0
500 http://fi.archive.ubuntu.com hardy/main Packages
3) What you expected to happen
- enabled remote logins using gdmsetup, no other changes. (seems to default
to gdmgreeter) (NB: This might make
your remote session vulnerable to attacks, don't do it if you don't
understand the consequences)
- expected to be able login from a remote Xserver running XDMCP
4) What happened instead
Login screen was not displayed on remote Xserver
My debugging gave the following explanation
When talking to an X server supporting RandR v1.1 (instead of the
current v1.2) gdmgreeter exits before displaying anything. There is no
error message to the user.
With gdm [debug] Enable=True only 2 lines are found in syslog, which
might be related to the problem
gdm[6110]: DEBUG: close_if_needed: Got G_IO_HUP on 9
gdm[6110]: DEBUG: close_if_needed: Got error on 9
However, these lines didn't tell me anything.
Using strace I found that gdmgreeter seems to be culprit:
write(2, "The program \'gdmgreeter\' receive"..., 583) = 583
However fd 2 seems to be /dev/null and I didn't find any information how
to turn on logging.
open("/dev/null", O_RDWR) = 2
Using tcpdump/wireshark I found that the last request sent to X server is
RandR opcode 8. My X server replies with BadRequest. The Xserver is correct,
because it supports only RandR v1.1 and opcode 8 was added for protocol version
1.2 (see
http://gitweb.freedesktop.org/?p=xorg/proto/randrproto.git;f=randrproto.txt;a=blob)
Actually gdmgreeter queries the RandR version just before the bad
request, but obviously it does not use the version information
appropriately.
I'm not sure how common RandR v1.1 is these days. If the full support
for the old protocol doesn't seem to be worth the effort, some better
logging should be added. Alternatively, could gdmgreeter "fall back" to
gdmlogin if the server supports only the old RandR protocol version?
- Workaround: switch to gdmlogin. (Called "plain with facebrwoser" in
+ Workaround: switch to gdmlogin. (Called "plain with facebrowser" in
gdmsetup)
** Description changed:
Binary package hint: gdm
1) $ lsb_release -rd
Description: Ubuntu 8.04.1
Release: 8.04
2) $ apt-cache policy gdm
gdm:
Installed: 2.20.7-0ubuntu1.1
Candidate: 2.20.7-0ubuntu1.1
Version table:
*** 2.20.7-0ubuntu1.1 0
500 http://fi.archive.ubuntu.com hardy-updates/main Packages
100 /var/lib/dpkg/status
2.20.5-0ubuntu3 0
500 http://fi.archive.ubuntu.com hardy/main Packages
3) What you expected to happen
- enabled remote logins using gdmsetup, no other changes. (seems to default
to gdmgreeter) (NB: This might make
your remote session vulnerable to attacks, don't do it if you don't
understand the consequences)
- expected to be able login from a remote Xserver running XDMCP
4) What happened instead
Login screen was not displayed on remote Xserver
My debugging gave the following explanation
When talking to an X server supporting RandR v1.1 (instead of the
current v1.2) gdmgreeter exits before displaying anything. There is no
error message to the user.
With gdm [debug] Enable=True only 2 lines are found in syslog, which
might be related to the problem
gdm[6110]: DEBUG: close_if_needed: Got G_IO_HUP on 9
gdm[6110]: DEBUG: close_if_needed: Got error on 9
However, these lines didn't tell me anything.
Using strace I found that gdmgreeter seems to be culprit:
write(2, "The program \'gdmgreeter\' receive"..., 583) = 583
However fd 2 seems to be /dev/null and I didn't find any information how
to turn on logging.
open("/dev/null", O_RDWR) = 2
- Using tcpdump/wireshark I found that the last request sent to X server is
RandR opcode 8. My X server replies with BadRequest. The Xserver is correct,
because it supports only RandR v1.1 and opcode 8 was added for protocol version
+ Using tcpdump/wireshark I found that the last request sent to the X server is
RandR opcode 8. My X server replies with BadRequest. The Xserver is correct,
because it supports only RandR v1.1 and opcode 8 was added for protocol version
1.2 (see
http://gitweb.freedesktop.org/?p=xorg/proto/randrproto.git;f=randrproto.txt;a=blob)
Actually gdmgreeter queries the RandR version just before the bad
request, but obviously it does not use the version information
appropriately.
I'm not sure how common RandR v1.1 is these days. If the full support
for the old protocol doesn't seem to be worth the effort, some better
logging should be added. Alternatively, could gdmgreeter "fall back" to
gdmlogin if the server supports only the old RandR protocol version?
Workaround: switch to gdmlogin. (Called "plain with facebrowser" in
gdmsetup)
--
gdmgreeter exits on RandR v1.1
https://bugs.launchpad.net/bugs/296127
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
