Forum Replies Created
June 28, 2019 at 07:56 in reply to: Floating windows in webplayer #22793
Looks like I need some help with webplayer floating windows. I have these options in my test .nxs file:
<option key="Command line" value="/usr/bin/startwm.sh" /> <option key="Custom Unix Desktop" value="application" /> <option key="Desktop" value="console" /> <option key="Enable session auto-resize" value="true" /> <option key="Resize the remote screen to the local geometry" value="false" /> <option key="Session resize mode" value="viewport" /> <option key="Session" value="unix" /> <option key="Virtual desktop" value="false" />
The page comes up correctly with all the settings I want, but in a browser tab versus in a detached window. What did I miss?
Thanks.May 31, 2019 at 08:16 in reply to: WebRTC on Version 6.6.8 #22498
So far I have had great results with 6.7.6 and found no issues at all.
Thanks for all your support!May 30, 2019 at 08:04 in reply to: WebRTC on Version 6.6.8 #22476
I got the local STUN server working while testing the 6.7.6 release. In this section:
I changed 127.0.0.1 to the instance’s public address.May 21, 2019 at 08:48 in reply to: WebRTC on Version 6.6.8 #22384
Sorry, I’m afraid this doesn’t work either. The STUN/TURN config is commented out of server.cfg, and I get:
The WebRTC peer-to-peer communication cannot be established. If the remote machine doesn't have a public IP,
please consider to configure your server to use STUN/TURN servers for NAT traversal.
I’m working in AWS which is of course NAT all the way.
To recap, these are my observations:
6.5.6: local STUN server working, remote STUN server working, no STUN server failing
6.6.8: local STUN server failing, remote STUN server working, no STUN server failingMay 14, 2019 at 07:54 in reply to: WebRTC on Version 6.6.8 #22311
I consider this issue unsolved. 6.5.6 works with a local or remote STUN server, 6.6.8 works only with a remote STUN server. Why is that?
Thanks.April 27, 2019 at 21:53 in reply to: WebRTC on Version 6.6.8 #22142
I redeployed 6.6.8 and found the following:
With the STUN server’s host set to 127.0.0.1, neither Firefox nor Chrome work. Changing the IP address to eth0’s address made no difference — neither browser worked.
Commenting out the local STUN server and opting to use Google’s STUN server works for both Firefox and Chrome.April 25, 2019 at 19:22 in reply to: WebRTC on Version 6.6.8 #22132
I will retest and post the results.April 10, 2019 at 17:47 in reply to: WebRTC on Version 6.6.8 #22004
I’ve done both of those; the terminal server is its own STUN server, and it works well when nxserver is version 6.5.6. I upgraded to 6.6.8, changed nothing else, and now WebRTC fails. Nothing in the logs hints at what might be going wrong.April 9, 2019 at 07:51 in reply to: Limiting options with ClientMenuConfiguration #21962
That was the trouble. I changed the configs on the nodes, not the main server. Thanks!April 4, 2019 at 07:55 in reply to: Limiting options with ClientMenuConfiguration #21928
I followed the link to the instructions and saw this:
Step 1 – Point your browser to the webplayer application and run it in debug mode:
This might be the disconnect. I’m not using nxwebplayer — I’m using Firefox. I’ll try nxwebplayer.
Thanks!March 15, 2019 at 09:43 in reply to: No sound on Mac Safari #21749
I saw that link earlier and confirmed NoMachine processes can access the controls.
As far as other audio sources, I was able to hear sound during a webinar earlier in the day.
Thanks.January 24, 2019 at 19:34 in reply to: Web client in AWS #21156
I believe I found the issue, and it comes down to this rule:
UDP 49152-65535 0.0.0.0/0
When I removed this rule, no connection failures, so I ran this command to find the random UDP port associated with connections:
# netstat -nap | grep nxnode.bin | grep ^udp udp 0 0 10.72.4.223:50187 0.0.0.0:* 31680/nxnode.bin
# netstat -nap | grep nxnode.bin | grep ^udp udp 0 0 10.72.4.223:60889 0.0.0.0:* 31680/nxnode.bin
The random port is often below the range specified in the UDP rule:
# netstat -nap | grep nxnode.bin | grep ^udp udp 0 0 10.72.4.223:43287 0.0.0.0:* 31680/nxnode.bin
# netstat -nap | grep nxnode.bin | grep ^udp udp 0 0 10.72.4.223:47949 0.0.0.0:* 31680/nxnode.bin
The lowest port I saw chosen is 35095. After changing the rule’s low-end port from 49152 to 35000 I have not had a connection error.January 24, 2019 at 09:10 in reply to: Web client in AWS #21140
The rules I posted are all inbound. The security group gives unrestricted access outbound. Still, with these rules in place, I get connection failures in about half the attempts.January 23, 2019 at 09:16 in reply to: Web client in AWS #21128
Thanks for your reply. It appears you’re right about the security_group. When I allow everything in, connections seem to never fail. When I apply the rules I found online, connections often fail. Here’s what I have, derived from this page: https://www.nomachine.com/DT06O00143
Proto, Port, Source
TCP 80 0.0.0.0/0
TCP 443 0.0.0.0/0
TCP 3478 0.0.0.0/0
UDP 3478 0.0.0.0/0
TCP 4000 0.0.0.0/0
UDP 4011-4999 0.0.0.0/0
TCP 4080 0.0.0.0/0
TCP 4443 0.0.0.0/0
TCP 4840 0.0.0.0/0
TCP 5041-5051 0.0.0.0/0
TCP 5349 0.0.0.0/0
UDP 5349 0.0.0.0/0
TCP 5473 0.0.0.0/0
TCP 5483 0.0.0.0/0
TCP 7001-7011 0.0.0.0/0
TCP 20000-30000 0.0.0.0/0
UDP 49152-65535 0.0.0.0/0November 15, 2018 at 10:17 in reply to: NXClientAuthentication fails #20472
I followed your suggestion to put the key into to the .nx\cofig folder. At that point, I still could not connect, the error was “Cannot accept key.”
Using the client interface, I reimported the key into my session file, this time using .nx\config\nx_client_rsa_key instead of Downloads\nx_client_rsa_key which I had done previously. This is the working formula — I am able to connect with the keys, no password.
All is well, thanks for your help!