[FreeNX-kNX] Sanity check...

[Ed Warnicke]

On Saturday 23 April 2005 07:03 am, Fabian Franz wrote:
> > 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.
>
> Yes, perhaps we can do some magic like:
>
> exec 3>&1 # save stdout
> exec 1>&2 # put all stdout to stderr instead
> netcat >&3 # connect with old stdout
>
> to prevent the effects that _any_ message goes to stdout after the bye
> command.
>
> But this needs testing and evaulation.

That seems like a good first approach ;)

>
> > Info: Connection with remote proxy established.
> > Error: Parse error in remote options string 'NX> '."
>
> I thought it was when nxagent did not start. Then netcat would not be
> started and such the NX> goes to stdout to the proxy ...

I dug into this more after I sent the email.
As it turns out there is a race condition between
nc and the starting of the nxagent by nxnode.
If nxagent isn't ready to accept the connection
from nc when the nc call is made, then nc quietly
exits and you fail in negotiating link parameters.
This failure is partially masked by the 'NX>'
error.  I debuged this with something like

log "netcat started"
netcat [...]
log "netcat finished with exit code $?"

which showed an exit code of 1.  After that 
line you saw the 'NX> [...]" lines associated with
nxagent listening for connections.

Using

log "netcat started"
strace netcat [...] 2>&1 | log_tee
log "netcat finished with exit code $?"

This showed netcat dieing because of
connection refused on it's attempt to 
connect to the  correct port for nxagent.
Subsequent appearance in the log of
'NX> [...]' indicates that nxagent *did* 
start listening for the connection, but to
late.

Trying

sleep 3; netcat [...]

fixed the problem (which for some reason was 
reliably occuring for me last night).  So I am pretty
sure there is a race condition between calling
nc in nxserver and the nxagent started by nxnode
listening.  I don't think a sleep is the right solution
though.  Thoughts?

Ed