When it matters if you use a named address versus dotted-decimal address, then “typically” it is the ssh
client itself which is blocking (assuming there is ping). Consider:
- If you can ping, then you are using the ICMP protocol to prove the route itself is working.
ssh
will use TCP. Mostly verification of ICMP implies TCP can work too, but only if no firewall is blocking it, and only if TCP protocol is supported along the route. I’ve never known TCP to not be supported along the route.- This also assumes you are on the same subnet. Going through the DMZ of a router from one device to another within the DMZ will only block if you have a managed switch (mostly limited to larger commercial businesses; it is rare for a home to have a managed switch as they are much more expensive).
- XRDP is a remote desktop protocol. This is not used for
ssh
, but it is used for some remote GUI software. Example: Virtual desktops, e.g., VNC. If XRDP is required, then it might be that you are usingssh
as a tunnel for the XRDP. When using PuTTY I don’t think XRDP would be involved, although an XRDP application could itself use thessh
connection…this in turn implies it isn’t just text-based traffic, but perhaps a GUI. If you are not using PuTTY for only text-based command line connection, then you might add that information (or suggest that you are in fact only using text command line). - It is possible that if you install XRDP somewhere, that this could have an effect on other network settings and indirectly fix or alter existing networking.
You can run a text-based editor over ssh
without anything special. You’d have to know your text editor, and that isn’t always easy. Example: vi
(these days it is vim
). I use vi
a lot, and it does not require a GUI. pico
is another easier to use editor (it doesn’t have much learning curve), but it doesn’t context highlight or have any advanced features.
If you want remote display a GUI application, and if your host PC is Linux (not Windows or Mac), then you can often enable X event forwarding via ssh
and run something like kate
or codeblocks
(or anything GUI). This depends on the ends of the remote and local understanding X events (X client-server model). See:
- https://forums.developer.nvidia.com/t/video-output-does-not-show-up-because-opengl-failed-to-create-x11-window-imagenet-camera-failed-to-create-opengl-display/68681/7
- https://forums.developer.nvidia.com/t/is-it-poossible-to-visit-nx-from-internet/180993/5
To run cross platform GUI with no restrictions implies you must install a remote desktop server on the remote end, and a remote desktop client on the local end. This is beyond what I can help with, but examples are:
- VNC
- TurboVNC
- VirtualGL
- RealVNC
- Vino
(I think latter this is the closest to officially supported, but I don’t know if there is a Windows client for Vino)
If any virtual desktop is not installed correctly, you risk causing graphics to fail (and CUDA). You want to be certain that this desktop works specifically with the Jetson without reverting to software rendering (meaning the GPU driver would no longer load and all work would be on the CPU). I don’t use any virtual desktop, so I am the wrong guy to tell you what works best.
Incidentally, any remote desktop has its own security which is similar to ssh
. Quite often such applications run through an ssh
tunnel, and even if the tunnel works, would still fail if the remote desktop requirements are not met (including security and protocols like XRDP, which is part of a network protocol on top of other protocols).