Bug 891109 - freenx-server broken by nmap-ncat?
Summary: freenx-server broken by nmap-ncat?
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: nmap
Version: 18
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Michal Hlavinka
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-01-01 18:45 UTC by Ian Pilcher
Modified: 2013-01-23 17:17 UTC (History)
10 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2013-01-23 01:37:44 UTC


Attachments (Terms of Use)
Remmina debug window contents (2.06 KB, text/x-log)
2013-01-01 18:45 UTC, Ian Pilcher
no flags Details
Contents of Remmina debug window after modifying /usr/libexec/nx/nxserver (2.21 KB, text/plain)
2013-01-03 17:30 UTC, Ian Pilcher
no flags Details

Description Ian Pilcher 2013-01-01 18:45:34 UTC
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:

Comment 1 Ville Skyttä 2013-01-01 22:16:31 UTC
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.

Comment 2 Michal Hlavinka 2013-01-03 13:57:03 UTC
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

Comment 3 Ville Skyttä 2013-01-03 16:22:10 UTC
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).

Comment 4 Ian Pilcher 2013-01-03 17:28:45 UTC
(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.

Comment 5 Ian Pilcher 2013-01-03 17:30:30 UTC
Created attachment 672136 [details]
Contents of Remmina debug window after modifying /usr/libexec/nx/nxserver

Comment 6 Ville Skyttä 2013-01-03 20:09:48 UTC
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?

Comment 7 Ian Pilcher 2013-01-03 23:41:33 UTC
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.

Comment 8 Michal Hlavinka 2013-01-04 10:35:24 UTC
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

Comment 9 Ville Skyttä 2013-01-04 18:20:54 UTC
(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

Comment 10 Michal Hlavinka 2013-01-07 13:28:06 UTC
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 :)

Comment 11 Ville Skyttä 2013-01-09 22:10:39 UTC
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?

Comment 12 Michal Hlavinka 2013-01-10 11:19:16 UTC
I can't do that either. "mhlavink does not have commit access to freenx-server" so it will have to be two separate updates

Comment 13 Fedora Update System 2013-01-10 11:25:00 UTC
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

Comment 14 Fedora Update System 2013-01-10 21:32:49 UTC
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).

Comment 15 Ville Skyttä 2013-01-18 08:34:59 UTC
Ian, could you test the update in comment 14 and report / leave karma how it works for you?

Comment 16 Ian Pilcher 2013-01-19 20:55:39 UTC
(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.)

Comment 17 Ville Skyttä 2013-01-20 11:51:24 UTC
Thanks. Similar racy behavior has been reported before, at least in bug 666752, but AFAIK nobody has taken a deeper look into it.

Comment 18 Fedora Update System 2013-01-23 01:37:46 UTC
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.

Comment 19 Tom Horsley 2013-01-23 02:01:31 UTC
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.

Comment 20 Norman Gaywood 2013-01-23 07:39:47 UTC
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

Comment 21 Ville Skyttä 2013-01-23 08:00:57 UTC
Please file new bugs for separate issues, thanks.

Comment 22 Tom Horsley 2013-01-23 12:30:57 UTC
OK, I have submitted bug 903186 against freexn-server.

Comment 23 Boyd 2013-01-23 17:17:27 UTC
(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.....


Note You need to log in before you can comment on or make changes to this bug.