RE: [Helix Beta] Re: gdm indirect XDMCP - anyone got working OK?

[Paul Jenner <p jenner eim surrey ac uk>]

	Sorry for the delay everyone but I re-tested this and got full debug
during a scheduled downtime.

	I can definitely confirm a reliable bug in that gdm-2.0beta4 crashes
on receiving XDMCP packets via an indirect xdm host whereas gdm-2.0beta2
does not.

	Full info is:

	I install gdm-2.0beta4.  I set a separate xdm box up as an indirect
xdm hosts pointing clients at the gdm box.  I boot around 30 X-terminals
which point at the indirect xdm box.  gdm "dies mysteriously" (no core dump
that I can see).  With debug set, gdm logs via syslog:

Dec  3 16:01:37 molniya gdm[698]: gdm_main: Here we go...
Dec  3 16:01:37 molniya gdm[698]: Start up on host molniya.ee.surrey.ac.uk,
port 177
Dec  3 16:01:37 molniya gdm[698]: Accepting XDMCP connections...
Dec  3 16:20:52 molniya gdm[698]: gdm_xdmcp_decode: Received opcode
FORWARD_QUERY from client 131.227.8.10
Dec  3 16:20:52 molniya gdm[698]: gdm_xdmcp_handle_forward_query:
ForwardQuery from 131.227.8.10
Dec  3 16:20:52 molniya gdm[698]: gdm_xdmcp_handle_forward_query: Got
FORWARD_QUERY from display: 131.227.8.74, port 2395
Dec  3 16:20:52 molniya gdm[698]: gdm_xdmcp_send_willing: Sending WILLING to
131.227.8.74

	then it dies without any further logging.  No log files are opened
in /var/gdm.

	If I re-install gdm-2.0beta2 everything works fine.  In the same
situation as above, all the X-terminals get their queries answered and gdm
with debug on logs via syslog:

Dec  3 16:35:08 molniya gdm[1183]: gdm_main: Here we go...
Dec  3 16:35:08 molniya gdm[1183]: Start up on host molniya.ee.surrey.ac.uk,
port 177
Dec  3 16:35:08 molniya gdm[1183]: Accepting XDMCP connections...
Dec  3 16:35:15 molniya gdm[1183]: Received opcode FORWARD_QUERY from client
131.227.8.10
Dec  3 16:35:15 molniya gdm[1183]: gdm_xdmcp_handle_forward_query:
ForwardQuery from 131.227.8.10
Dec  3 16:35:15 molniya gdm[1183]: gdm_xdmcp_handle_forward_query: Got
FORWARD_QUERY from display: 131.227.8.65, port 1243
Dec  3 16:35:15 molniya gdm[1183]: gdm_xdmcp_send_willing: Sending WILLING
to 131.227.8.65
Dec  3 16:35:16 molniya gdm[1183]: Received opcode FORWARD_QUERY from client
131.227.8.10
Dec  3 16:35:16 molniya gdm[1183]: gdm_xdmcp_handle_forward_query:
ForwardQuery from 131.227.8.10
Dec  3 16:35:16 molniya gdm[1183]: gdm_xdmcp_handle_forward_query: Got
FORWARD_QUERY from display: 131.227.8.68, port 3318
Dec  3 16:35:16 molniya gdm[1183]: gdm_xdmcp_send_willing: Sending WILLING
to 131.227.8.68

	etc.  Note the debug looks the same except it starts to send willing
responses to all X-terminals instaed of dying after the first.

	I will start looking at the code changes between 2.0beta2 and
2.0beta4 when I get a bit of time but are there any thoughts upfront?

	Thanks,

	Paul

   -----------------------------------------------------------------------
        Paul S Jenner
        UNIX Systems Administrator
        Surrey Satellite Technology Limited

        E-mail:   P Jenner eim surrey ac uk

        UNSOLICITED COMMERCIAL E-MAIL IS NOT WELCOME AT THIS ADDRESS
   -----------------------------------------------------------------------

> -----Original Message-----
> From: Martin K. Petersen [mailto:mkp mkp net]
> Sent: 21 November 2000 13:32
> To: Paul Jenner
> Cc: 'beta helixcode com'; 'gdm sunsite auc dk'
> Subject: Re: [Helix Beta] Re: gdm indirect XDMCP - anyone got working OK?
>
> Paul> Sorry to be obvious about the symptom.  I have looked at the
> Paul> logs for info (both gdm log files and syslog messages from gdm
> Paul> when running with debug on) but could not find anything
> Paul> definite.  
> 
> Please mail me the debug output of an XDMCP transaction.  You need to
> configure your syslogd to capture daemon.debug for that to work.
> 
> >> Which means you'll keep running beta2...
> 
> Paul> Doesn't appear that way Martin.  If I upgrade whilst the gdm
> Paul> process is running, the original listener spawned by init is
> Paul> beta2 - thus it listens OK to the indirect queries passed via
> Paul> the xdm host.  However when someone actually requests a banner,
> Paul> the listener process spawns a child gdm process to handle it.
> Paul> As the gdm binary installed at this point is beta4, it spawns a
> Paul> Helix beta4 gdm child session.  
> 
> Nonono.  The running gdm daemon *forks* a child session, it doesn't
> execute a new process from disk.  Your process will still be a beta2.
> 
> The greeter window will be beta4, but that's irrelevant.
> 
> Paul> On the subject of the Red Hat patches, they also have the
> Paul> problem.  Red Hat beta2 works but Red Hat beta4 (via their
> Paul> updated package) fails like the Helix one.  The problem was
> Paul> definitely introduced between beta2 and beta4.
> 
> Well.  It works with a pristine beta4 tree here.