From owner-freebsd-ports-bugs@FreeBSD.ORG Sat May 17 17:20:15 2003 Return-Path: Delivered-To: freebsd-ports-bugs@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6A97637B401 for ; Sat, 17 May 2003 17:20:15 -0700 (PDT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4A54443F85 for ; Sat, 17 May 2003 17:20:14 -0700 (PDT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.12.9/8.12.9) with ESMTP id h4I0KEUp060004 for ; Sat, 17 May 2003 17:20:14 -0700 (PDT) (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.12.9/8.12.9/Submit) id h4I0KEhK060003; Sat, 17 May 2003 17:20:14 -0700 (PDT) Resent-Date: Sat, 17 May 2003 17:20:14 -0700 (PDT) Resent-Message-Id: <200305180020.h4I0KEhK060003@freefall.freebsd.org> Resent-From: FreeBSD-gnats-submit@FreeBSD.org (GNATS Filer) Resent-To: freebsd-ports-bugs@FreeBSD.org Resent-Reply-To: FreeBSD-gnats-submit@FreeBSD.org, Joel Ray Holveck Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 336C737B401 for ; Sat, 17 May 2003 17:16:22 -0700 (PDT) Received: from thor.piqnet.org (adsl-66-125-235-59.dsl.sntc01.pacbell.net [66.125.235.59]) by mx1.FreeBSD.org (Postfix) with ESMTP id 50A7B43F93 for ; Sat, 17 May 2003 17:16:21 -0700 (PDT) (envelope-from joelh@thor.piqnet.org) Received: from thor.piqnet.org (localhost [127.0.0.1]) by thor.piqnet.org (8.12.6p2/8.12.6) with ESMTP id h4I0GKmT050543 for ; Sat, 17 May 2003 17:16:20 -0700 (PDT) (envelope-from joelh@thor.piqnet.org) Received: (from joelh@localhost) by thor.piqnet.org (8.12.6p2/8.12.6/Submit) id h4I0GJU3050532; Sat, 17 May 2003 17:16:19 -0700 (PDT) (envelope-from joelh) Message-Id: <200305180016.h4I0GJU3050532@thor.piqnet.org> Date: Sat, 17 May 2003 17:16:19 -0700 (PDT) From: Joel Ray Holveck To: FreeBSD-gnats-submit@FreeBSD.org X-Send-Pr-Version: 3.113 Subject: ports/52387: XDMCP doesn't work [PATCH] X-BeenThere: freebsd-ports-bugs@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Joel Ray Holveck List-Id: Ports bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 May 2003 00:20:15 -0000 >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@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,@HK*RL@<')O9W)A;7,O6'-E2`]/2!!1E]$14-N M970I(`H@"2`@("!C;VYT:6YU93L*("-E;F1I9B`O*B!$3D540T].3B`J+PHK M"6QE;B`]('-I>F5O9B@J*&EF2`]/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: