ports/52387: XDMCP doesn't work [PATCH]
Joel Ray Holveck
joelh at piqnet.org
Sun May 18 00:20:15 UTC 2003
>Number: 52387
>Category: ports
>Synopsis: XDMCP doesn't work [PATCH]
>Confidential: no
>Severity: serious
>Priority: medium
>Responsible: freebsd-ports-bugs
>State: open
>Quarter:
>Keywords:
>Date-Required:
>Class: sw-bug
>Submitter-Id: current-users
>Arrival-Date: Sat May 17 17:20:13 PDT 2003
>Closed-Date:
>Last-Modified:
>Originator: Joel Ray Holveck
>Release: FreeBSD 5.0-RELEASE-p7 i386
>Organization:
>Environment:
System: FreeBSD thor.piqnet.org 5.0-RELEASE-p7 FreeBSD 5.0-RELEASE-p7 #23: Mon May 12 16:20:56 PDT 2003 root at thor.piqnet.org:/usr/local/src/freebsd/src/sys/i386/compile/THOR i386
>Description:
Using XFree86-4, XDMCP queries don't work. The X server is
immediately declined by xdm (or, as is the case in my tests, kdm), and
exits. In my testing, this affects the ports for XFree86-4-NestServer
(XFree86-NestServer-4.3.0), XFree86-4-Server (XFree86-Server-4.3.0_7),
and XFree86-4-VirtualFramebufferServer
(XFree86-VirtualFramebufferServer-4.3.0_1). It does NOT affect Xvnc
(as installed by tightvnc-1.2.8), presumably because Xvnc is based on
a version of X does not have this bug. You can use Xvnc to see the
correct behavior.
>How-To-Repeat:
Be sure that xdm is running and has xdmcp turned on. 'netstat
-anfinet | grep 177' should list a listener on udp *.177. (I don't
know if xdmcp can be turned on and off for xdm; it may always be on.
For kdm, you need to edit the file /usr/local/share/config/kdm/kdmrc,
set Enable=true, and reset kdm. I don't think a SIGHUP is enough. I
have no idea how gdm is configured, or even if it supports XDMCP.)
Also, you may need to edit your Xaccess file
(/usr/X11R6/lib/X11/xdm/Xaccess for xdm, and
/usr/local/share/config/kdm/Xaccess for kdm). There should be a line
with just a * (and an optional comment). It's okay if other lines
start with a *, just as long as there's one that has just a *. (If
you're not behind a firewall, you may want to replace the * with
'localhost' or your hostname, and use that for the -query and -from
arguments to the X server.)
This example uses Xnest. The same works for X (you'll probably want
to be at a console terminal) or Xvfb.
thor$ Xnest -query localhost :2
Fatal server error:
XDMCP fatal error: Session declined No valid address
The correct behavior would be to display a window with the X gray
background and a login box.
>Fix:
A quick look at the XDMCP Request packet shows the problem. (This is
the third packet of an XDMCP session. Ethereal properly decodes it.)
Frame 3 (122 bytes on wire, 122 bytes captured)
Null/Loopback
Internet Protocol, Src Addr: 66.125.235.59 (66.125.235.59), Dst Addr: 66.125.235.59 (66.125.235.59)
User Datagram Protocol, Src Port: 51112 (51112), Dst Port: xdmcp (177)
X Display Manager Control Protocol
Version: 1
Opcode: Request (0x0007)
Message length: 84
Display number: 3
Connections (0) <<<<<<<<<<<<<<<< THIS IS THE PROBLEM <<<
Authentication name:
Authentication data (0 bytes)
Authorization names (4)
Authorization name: MIT-MAGIC-COOKIE-1
Authorization name: XDM-AUTHORIZATION-1
Authorization name: SUN-DES-1
Authorization name: XC-QUERY-SECURITY-1
Manufacturer display ID:
The "Connections" section describes how XDM is supposed to talk to the
server, for example, to display the login box. From /usr/X11R6/lib/X11/doc/xdmcp.TXT:
Connection Types: ARRAY16
Specifies an array indicating the stream ser-
vices accepted by the display. If the high-
order byte in a particular entry is zero, the
low-order byte corresponds to an X-protocol
host family type.
Connection Addresses: ARRAYofARRAY8
For each connection type in the previous
array, the corresponding entry in this array
indicates the network address of the display
device.
The values used for this are built up by calls to
XdmcpRegisterConnection from DefineSelf, in
programs/Xserver/os/access.c. The code path used by FreeBSD begins at
line 724. The routine loops over the results from getifaddrs, calls
ConvertAddr on each of them, and XdmcpRegisterConnection on the
results (among other things). However, the len argument to
ConvertAddr is not initialized. ConvertAddr only checks the len
argument to ensure that there is a data structure at the appropriate
spot; if len is 0, then ConvertAddr returns FamilyLocal. But the loop
in question ignores FamilyLocal addresses, so XdmcpRegisterConnection
is never called.
The following patch fixes this problem:
--- programs/Xserver/os/access.c.~1~ Sun Jul 7 13:11:52 2002
+++ programs/Xserver/os/access.c Sat May 17 16:50:08 2003
@@ -730,6 +730,7 @@
if (ifr->ifa_addr.sa_family == AF_DECnet)
continue;
#endif /* DNETCONN */
+ len = sizeof(*(ifr->ifa_addr));
family = ConvertAddr(ifr->ifa_addr, &len, (pointer *)&addr);
if (family == -1 || family == FamilyLocal)
continue;
Note that there are some embedded spaces at ends of lines in that;
these may throw off copy/pasting. So here is the patch uuencoded:
begin 666 patch-access.c
M+2TM('!R;V=R86US+UAS97)V97(O;W,O86-C97-S+F,N?C%^"5-U;B!*=6P@
M(#<@,3,Z,3$Z-3(@,C`P, at HK*RL@<')O9W)A;7,O6'-E<G9E<B]O<R]A8V-E
M<W,N8PE3870 at 36%Y(#$W(#$V.C4P.C`X(#(P,#,*0$`@+3<S,"PV("LW,S`L
M-R!`0`H@"6EF("AI9G(M/FEF85]A9&1R+G-A7V9A;6EL>2`]/2!!1E]$14-N
M970I(`H@"2`@("!C;VYT:6YU93L*("-E;F1I9B`O*B!$3D540T].3B`J+PHK
M"6QE;B`]('-I>F5O9B at J*&EF<BT^:69A7V%D9'(I*3L*(`EF86UI;'D@/2!#
M;VYV97)T061D<BAI9G(M/FEF85]A9&1R+"`F;&5N+"`H<&]I;G1E<B`J*29A
M9&1R*3L*(`EI9B`H9F%M:6QY(#T]("TQ('Q\(&9A;6EL>2`]/2!&86UI;'E,
7;V-A;"D@"B`)("`@(&-O;G1I;G5E.PH`
`
end
Note that patches for XFree86-4-VirtualFramebufferServer and
XFree86-4-NestServer are pulled from the files directory for
XFree86-4-libraries rather than their own files directories, so
putting this patch in that directory should do the trick for those
two. I don't see any reason that this patch should affect the X
libraries' build.
Also, the patches for XFree86-4-Server are listed in its Makefile. I
assume that this would need to be listed as well.
I've only tested this patch against Xnest. I haven't yet tested it
against Xserver or Xvfb, but I don't expect them to be any different.
I have verified that the same symptom exists in all three.
>Release-Note:
>Audit-Trail:
>Unformatted:
More information about the freebsd-ports-bugs
mailing list