Created attachment 671070 [details] Remmina debug window contents Description of problem: Using Remmina to connect to a freenx-server on Fedora 18 and getting a solid gray window. Debug window includes the following: [NX] ncat: invalid option -- 'z' [NX] Ncat: Try `--help' or man(1) ncat for more information, usage options and help. QUITTING. Version-Release number of selected component (if applicable): freenx-server-0.7.3-28.fc18.x86_64 How reproducible: 100% Steps to Reproduce: 1. yum install freenx-server 2. nxsetup --install 3. systemctl start freenx-server.service 4. Attempt to connect Actual results: Solid gray window. Expected results: Working NX session. Additional info:
freenx-server (specifically nxserver) invokes nc with the -z option, which appears to be gone as of nc from the nmap-ncat package -> reassigning to nmap for comments.
Unfortunately, ncat is not completely drop in replacement for old nc. ncat comes from nmap package, which has rich scan possibilities and I doubt nmap upstream will be willing to add port scan features to ncat when they have nmap and are trying to keep other simple tools (ncat, ndiff, nping) simple. Is it possible for nxserver to use nmap instead? nmap some_host -p port(-range) or alternatively if you need exit code to be 0/1: ncat --send-only some_host port </dev/null
Using nmap for this purpose sounds a bit heavyweight to me. > ncat --send-only some_host port </dev/null That doesn't work for me on with the F-17 ncat, I get a "Unable to register IOD #2: Operation not permitted" error. But this seems to work: ncat --recv-only --send-only some_host port Ian, could you try replacing all instances of '$COMMAND_NETCAT -z' with '$COMMAND_NETCAT --recv-only --send-only' in /usr/libexec/nx/nxserver of your server box and see if that works? It seems to work for me on a F-16 freenx server box (with additionally setting COMMAND_NETCAT to ncat).
(In reply to comment #3) > Ian, could you try replacing all instances of '$COMMAND_NETCAT -z' with > '$COMMAND_NETCAT --recv-only --send-only' in /usr/libexec/nx/nxserver of > your server box and see if that works? It seems to work for me on a F-16 > freenx server box (with additionally setting COMMAND_NETCAT to ncat). When I try to connect (using Remmina), I now get a pop-up that says: Server won't say bye to us? The output in the debug window includes: [NX] Ncat: Connection refused.
Created attachment 672136 [details] Contents of Remmina debug window after modifying /usr/libexec/nx/nxserver
My Remmina debug window output is pretty much identical up to the "[NX] NX> 707 SSL tunneling: 1" line, i.e. I get the "[NX] Ncat: Connection refused." message as well but I believe it's normal for that to occur because of the way the port scan is being done. But from there on it reads [NX] NX> 707 SSL tunneling: 1 [NX] NX> 1009 Session status: starting [NX] NX> 710 Session status: running [NX] NX> 1002 Commit [NX] NX> 105 [NX] /usr/libexec/nx/nxserver: line 1585: 19297 Terminated sleep $AGENT_STARTUP_TIMEOUT [NX] NX> 1006 Session status: running [NX] bye [NX] Bye [NX] NX> 999 Bye The only meaningful differences that I can see is that as said my freenx server is a F-16 one and that I'm forcing it to use ncat instead of nc, and that I'm using a GNOME session instead of a KDE one. Apart from restarting the freenx-server service to clean up cruft possibly left behind, I'm out of ideas at the moment. Oh, but is your delete-me user allowed to log in with plain SSH?
After doing some more experimentation, I have found that I am able to connect ... sometimes. The session log of the unsuccessful attempts contains: xrdb: Connection refused xrdb: Can't open display ':2000' $DISPLAY is not set or cannot connect to the X server. I'm not yet 100% sure, but it seems that after the first successful connection, all subsequent attempts succeed. My guess is that the failures occur because the session tries to connect to the X server socket before nxagent has fully started up and created it. Once everything is cached, nxagent starts quickly enough that the socket exists by the time the client programs try to connect. So the change from "-z" to "--recv-only --send-only" seems to work, but I'm encountering some sort of race that may or may not be related.
Do not use --recv-only and --send-only, that combination does not make sense and can produce EINVAL in future. > Unable to register IOD #2: Operation not permitted" that's a bug, seems I did not backport the fix to all fedora branches, will do now for testing, you can use workaround (change default nsock engine - that's also what this bug is all about), just add --nsock-engine select the command will be ncat <host> <port> --send-only --nsock-engine select </dev/null so add the workaround option or wait for fix to reach the updates repository
(In reply to comment #8) > --nsock-engine select The --nsock-engine option doesn't seem to be documented in --help output or the man page, so I'm a bit uncomfortable with using it. I suppose we could ship a patched freenx-server in the same update as your fix, I assume it's this one? https://admin.fedoraproject.org/updates/nmap-6.01-9.fc18
It's documented in man nmap (nsock is their shared library). Yes, that's the fix. ----- What are we going to do with this bug report? There are problems in both packages, but given the original reproducer, the reporter's issue seems to be more freenx-server related. So, do you want to reassign this bug back to your package or clone it or keep it as nmap bug? It does not matter for me. Just mentioning the possibilities for your consideration :)
I don't particularly care which package this issue is filed against. I've built a (hopefully, can't test) fixed/patched freenx-server for F-18: http://koji.fedoraproject.org/koji/buildinfo?buildID=377260 This build won't work with the unfixed ncat, so I think it'd make sense to add this freenx-server build to the nmap-6.01-9.fc18 update so they'll be shipping at the same time. I don't seem to have an option/permissions to do that in bodhi, could you take care of it?
I can't do that either. "mhlavink does not have commit access to freenx-server" so it will have to be two separate updates
freenx-server-0.7.3-29.fc18 has been submitted as an update for Fedora 18. https://admin.fedoraproject.org/updates/freenx-server-0.7.3-29.fc18
Package freenx-server-0.7.3-29.fc18: * should fix your issue, * was pushed to the Fedora 18 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing freenx-server-0.7.3-29.fc18' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2013-0598/freenx-server-0.7.3-29.fc18 then log in and leave karma (feedback).
Ian, could you test the update in comment 14 and report / leave karma how it works for you?
(In reply to comment #15) > Ian, could you test the update in comment 14 and report / leave karma how it > works for you? With freenx-server-0.7.3-29.fc18, the situation is as I described it in comment 7. It takes me many attempts (10+) to connect, but once I get a connection subsequent attempts succeed. I think it makes sense to close this out, as the ncat issue seems to have been solved. The socket/nxagent race(?) can be worked separately, if I ever feel motivated enough to BZ it. (I've managed to get VNC working pretty well, and I just don't have cycles to spend on this right now.)
Thanks. Similar racy behavior has been reported before, at least in bug 666752, but AFAIK nobody has taken a deeper look into it.
freenx-server-0.7.3-29.fc18 has been pushed to the Fedora 18 stable repository. If problems still persist, please make note of it in this bug report.
I've got freenx-server-0.7.3-29.fc18 but I can't for the life of me get a connection to work to my system at work on fedora 18. The same hardware booted into fedora 17 and freenx-server-0.7.3-27.fc17.x86_64 was working perfectly the last time I used fedora 17. I've tried connecting a gazillion times in a row, and I can't get that first connection to work at all. Maybe I'm hitting the race mentioned above all the time? If I run "ss" to look for who is listening for what I do see an nxagent listening on a socket in the /tmp X11 direcory (the exact name of which I don't remember), but it doesn't seem to appear till after nxclient has failed. If I log errors from the script I run to start the session, I see things like: xhost: unable to open display ":2001" xrdb: Connection refused xrdb: Can't open display ':2001' It is like the script is run before the X session is there.
Just want to say "me to" for comment #19 Can't comnect with freenx-server-0.7.3-29.fc18.x86_64 Same messages in the session as comment #19 The detail in the "connection reufused" box ends with: Ncat: Connection refused. NX> 280 Exiting on signal: 15
Please file new bugs for separate issues, thanks.
OK, I have submitted bug 903186 against freexn-server.
(In reply to comment #20) > Just want to say "me to" for comment #19 > > Can't comnect with freenx-server-0.7.3-29.fc18.x86_64 > > Same messages in the session as comment #19 > > The detail in the "connection reufused" box ends with: > > Ncat: Connection refused. > NX> 280 Exiting on signal: 15 Seeing this problem as well. Reverted to using vncserver for the time being.....