[FreeNX-kNX] Sanity check...

[Ed Warnicke]

I am trying to debug an issue I'm seeing, and I want to
make sure I understand how FreeNX handles 'ssl tunneling'.

From what I can find in the nxserver/nxnode code,
if 'ssl tunneling' is enabled via the ENCRYPTION environment
variable then nxnode will only accept connections from
127.0.0.1 (localhost) and nxserver uses netcat to connect
to the nxagent spawned by nxnode and redirect all of
it's input and output via the ssh connection to nxserver.

It seems that in the case of an encrypted connection,
after the 'NX> 999 Bye' all traffic should then be the
normal chatter between the nxproxy on the client
side and the nxagent on the server side.

I am seeing some issues because in certain
conditions, it seems that nxnode is sending
messages with the 'NX>' prompt *after* the
'NX> 999 Bye' signals the switch over to 
expecting stuff from the nxagent on the
channel.  I think this causes error messages like:

"NXPROXY - Version 1.4.0

Copyright (C) 2001, 2004 NoMachine.
See http://www.nomachine.com/ for more information.

Info: Proxy running in client mode with pid '19704'.
Info: Waiting for connection from any host on port '32792'.
Info: Accepted connection from '127.0.0.1' on port '35123'.
Info: Connection with remote proxy established.
Error: Parse error in remote options string 'NX> '."

Is my understanding of how Freenx 'ssl tunneling' works
and what is causing this error message correct?

I *think* the problem I reported here:
http://developer.berlios.de/bugs/?func=detailbug&bug_id=3603&group_id=2978

where I was getting errors in the C-${sessionid}/session file like:

"Info: Waiting for connection from '127.0.0.1' on port '5015'.
 XIO: fatal IO error 104 (Connection reset by peer) on X server "unix:1015.0"
"
Where from the nxclient closing it's end of the connection due to the 
spurious (from it's point of view) 'NX>', which was causing the nxserver
instance to be killed, which was killing the nc instance, which was
closing the connection to the nxagent, which was then outputing
the XIO error.  Does that sound like a reasonable hypothesis?

If so, we should just have to figure out *why* we are seeing the 
spurious 'NX>' messages to solve the problem?

Ed