On Tue, 20 Apr 2004, Peter Breitenlohner wrote:
> > > yes, that was it. I have revoked my changes to xc/programs/xdm/xdmcp.c
> > > lines ca. 1420ff (patch-16-IPv6, kludge) and instead fixed the (s/!=/==/)
> > > and this works for us, except on the notebooks without network connection.
> > > When I have some time during the easter hollidays I'll try to figure out
> > > that last problem.
> > OK. Thanks for getting back to me on that.
> Hi Marc,
> meanwhile I did some strace-ing and wrote a small test program and therby
> finally have found out why our notebooks (when off the network) took such a
> long time (ca. 10min) to start xdm.
> This was caused by the IPv6-enabled xdm only insofar as in that case
> `getaddrinfo' is used to resolve hostnames as opposed to `gethostbyname' in
> the IPv6-disabled version. As far as I can see the problem could equally
> have occured if IPv6 were supported by the linux kernel.
> There was an accumulation of several circumstances, some of them particular
> to our setup. I give a somewhat detailed description what happened, because
> other people might encounter similar problems (delays).
> 1. we have a CHOOSER hostlist with 51 unqualified hostnames (we can't use
> "CHOOSER BROADCAST" for various reasons).
> 2. `getaddrinfo("host", NULL, NULL, &ai)' (as used by xdm) produced a 10sec
> timeout, whereas `getaddrinfo("host.domain", NULL, NULL, &ai)' as well as
> `gethostbyname("host")' give an immediate answer.
> 2.1. the glibc-2.[23].x implementation of
> `getaddrinfo("host", NULL, NULL, &ai)'
> first queries the nameserver for "host.domain" and then for "host" (whereas
> `gethostbyname("host")' only queries for "host.domain"). I don't have the
> slightest idea what's the reason for this pecularity (feature or bug) of
> getaddrinfo since from the nameserver's point of view a domainname "host"
> without any dots doesn't make much sense.
> 2.2. the nameserver (ISC bind-9.2.3) on the notebook has forward and
> reverse slave zone files for our domain, but for sure couldn't resolve an
> unqualified hostname. Unfortunately it was configured to forward the request
> to resolve "host" to other namesevers (recursion), thereby producing a bad
> timeout. Disabling this recursion of the slave nameserver has solved all the
> problems we had.
You seem to be implying that "host.domain" isn't resolvable, which doesn't make
much sense.
Marc.
+----------------------------------+-----------------------------------+
| Marc Aurele La France | work: 1-780-492-9310 |
| Computing and Network Services | fax: 1-780-492-1729 |
| 352 General Services Building | email: [EMAIL PROTECTED] |
| University of Alberta +-----------------------------------+
| Edmonton, Alberta | |
| T6G 2H1 | Standard disclaimers apply |
| CANADA | |
+----------------------------------+-----------------------------------+
XFree86 developer and VP. ATI driver and X server internals.
_______________________________________________
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel
