itguy92075

Forum Replies Created

Viewing 15 posts - 1 through 15 (of 20 total)
  • Author
    Posts
  • in reply to: Floating windows in webplayer #22793
    Avataritguy92075
    Participant

    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.

    in reply to: WebRTC on Version 6.6.8 #22498
    Avataritguy92075
    Participant

    Hi Shoti,

    So far I have had great results with 6.7.6 and found no issues at all.

    Thanks for all your support!

    in reply to: WebRTC on Version 6.6.8 #22476
    Avataritguy92075
    Participant

    Hi Shoti,

    I got the local STUN server working while testing the 6.7.6 release.  In this section:

    Section “STUN”

    Host      127.0.0.1

    Port      3478

    EndSection

     

    I changed 127.0.0.1 to the instance’s public address.

    in reply to: WebRTC on Version 6.6.8 #22384
    Avataritguy92075
    Participant

    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 failing

     

     

    in reply to: WebRTC on Version 6.6.8 #22311
    Avataritguy92075
    Participant

    Hi Shoti,

    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.

    in reply to: WebRTC on Version 6.6.8 #22142
    Avataritguy92075
    Participant

    Hi Shoti,

    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.

     

    in reply to: WebRTC on Version 6.6.8 #22132
    Avataritguy92075
    Participant

    Hi Shoti,

    I will retest and post the results.

    in reply to: WebRTC on Version 6.6.8 #22004
    Avataritguy92075
    Participant

    Hi Shoti,

    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.

    in reply to: Limiting options with ClientMenuConfiguration #21962
    Avataritguy92075
    Participant

    That was the trouble.  I changed the configs on the nodes, not the main server.  Thanks!

    in reply to: Limiting options with ClientMenuConfiguration #21928
    Avataritguy92075
    Participant

    Hello,

    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:
    https://server:port/nxwebplayer?logging=start

    This might be the disconnect. I’m not using nxwebplayer — I’m using Firefox. I’ll try nxwebplayer.

    Thanks!

    in reply to: No sound on Mac Safari #21749
    Avataritguy92075
    Participant

    Hello,

    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.

    in reply to: Web client in AWS #21156
    Avataritguy92075
    Participant

    Hello,

    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

    again:

    # 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

    again:

    # 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.

    in reply to: Web client in AWS #21140
    Avataritguy92075
    Participant

    Hello,

    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.

    in reply to: Web client in AWS #21128
    Avataritguy92075
    Participant

    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/0

    in reply to: NXClientAuthentication fails #20472
    Avataritguy92075
    Participant

    Hello,

    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!

     

Viewing 15 posts - 1 through 15 (of 20 total)