Cubieboard or other SBC remote control methods

Leave a reply

* Serial port
* SSH
* SSH + X11
* XDMCP
* X Protocol

Serial port/UART/RS232

If there isn’t network inside U-Boot boot sequence, of for other reason. Connecting using (replace the x by the corresponding number):
* A serial wire between the controling computer and the controled board (as CubieBoard here) and use the /dev/ttySx port.
* A standard USB<=>serial adapter/wire (as PL2303, CH340, FT2232C… compatible) and use then the /dev/ttyUSBx port.

Connecting serial port on Cubieboard

Connecting serial port on Cubieboard

Few possible comands (with terminal) to connect using serial. The examples arguments are with USB-serial wire/adapter (/dev/ttyUSB0), for a serial wire use /dev/tty0 instead

Package             commande                                             (exit)
busybox             busybox microcom -t 5000 -s 115200 /dev/ttyUSB0      (ctrl+x)
minicom             minicom -D /dev/ttyUSB0 -b 115200                    (ctrl+a, then x)
gtkterm-git (AUR)   gtkterm -s 115200 -p /dev/ttyUSB0                    (ctrl+shift+q)
python-pyserial     python -m serial.tools.miniterm /dev/ttyUSB0 115200  (ctrl+])
screen              screen /dev/ttyUSB0 115200                           (ctrl+a, then \)
tinyserial          com /dev/ttyUSB0 115200                              (ctrl+a)
picocom             picocom --baud 115200 /dev/ttyUSB0                   (ctrl+a, then ctrl+x)

Il est possible de changer les paramètre d’un ttyS/ttyUSB à l’aide de la commande stty (voir man stty)

stty -F /dev/ttyUSB0 cs8

The following commands have GUI, here package nameArch Linux (AUR)
* gtkterm-git (AUR)
* easyterm (AUR)

SSH

ssh user@cubieboard

SSH + remote X application display using SSH tunnel

First verify that X11 transfert via SSH is accepted. For this, you need to verify that in /etc/ssh/sshd_config the following variable is set:

X11Forward yes

If it was not the case SSH daemon need to be restarted, then

ssh -X user@cubieboard

If this error is displayed

Xlib:  extension "RANDR" missing on display "localhost:10.0".

Disconnect and try with:

ssh -Y user@cubieboard

If this error is displayed

X11 forwarding request failed on channel 0

Ensure that xorg-xauth package is installed on server side

sudo pacman -S xorg-xauth

Avec cette méthode, concernant les applications 3D :
* Si OpenGL ou OpenGL ES purement logiciel, cela passera (mais lentement).
* Si OpenGL ES accéléré, ça ne marche pas.
Une solution de contournement, utliser LLVMpipe (la plus rapide des implémentations logicielles), Il y aura OpenGL complet mais dont le rendu ne sera fait que par le CPU/SIMD :

LIBGL_ALWAYS_SOFTWARE=1 $application

or

export LIBGL_ALWAYS_SOFTWARE=1
$application

XDMCP

Avec cette méthode à propos des applications 3D :
* OpenGL logiciel ou OpenGL ES (logiciel ou avec accélération matérielle), ne fonctionne pas du tout, du moins en cas de mélange x86 <-> ARM. Il est toujours possible d’utiliser LLVMpipe

Attention XDMCP va écouter sur le port 177 en TCP, penser à le protéger sur un poste nomade ou qui n’est pas derrière un parre-feu

Vous pouvez le protéger comme suit (il faut être root ou le faire en sudo), si vous n’avez pas encore de règle. On définit d’abord l’adresse IP du seul host à autoriser dans la variable HOST_A_AUTORISER (j’ai donné 192.168.0.2 pour l’exemple, il faut le remplacer). Il peut être nécessaire d’autoriser la sortie si vous avec un DROP par défaut (ce que je conseillerais plutôt)

HOST_A_AUTORISER=192.168.0.2
iptables -I INPUT -p tcp --dport 177 -m comment --comment "interdit tout XDMCP" -j DROP
iptables -I INPUT -p tcp --dport 177 -s ${HOST_A_AUTORISER} -m comment --comment "autorise host toto XDMCP" -j ACCEPT

Sur la Cubieboard, ajouter dans /etc/lightdm/lightdm.conf

[XDMCPServer]
enabled=true

puis redémarrer lightdm comme suit :

service lightdm restart

Sur le poste de contrôle :
* Installer le paquet xnest si nécessaire, puis

Xnest :1 -query cubieboard

VNC

Sur la cubieboard. Installer un serveur VNC, par exemple tightvncserver (vnc4server exigera un mot de passe) :

apt-get install tightvncserver

Ajouter dans /etc/lightdm/lightdm.conf :

[VNCServer]
enabled=true

Attention XDMCP va écouter sur le port 177 en TCP, penser à le protéger sur un poste nomade ou qui n’est pas derrière un parre-feu

Vous pouvez le protéger comme suit (il faut être root ou le faire en sudo), si vous n’avez pas encore de règle. On définit d’abord l’adresse IP du seul host à autoriser dans la variable HOST_A_AUTORISER (j’ai donné 192.168.0.2 pour l’exemple, il faut le remplacer). Il peut être nécessaire d’autoriser la sortie si vous avec un DROP par défaut (ce que je conseillerais plutôt)

HOST_A_AUTORISER=192.168.0.2
iptables -I INPUT -p tcp --dport 5900 -m comment --comment "interdit tout VNC" -j DROP
iptables -I INPUT -p tcp --dport 5900 -s ${HOST_A_AUTORISER} -m comment --comment "autorise host toto VNC" -j ACCEPT

puis redémarrer lightdm comme suit :

service lightdm restart

Sur le poste de contrôle :
* Installer le paquet xvncviewer si nécessaire, puis

xvncviewer cubieboard

X Protocol

Il est également possible de lancer une application à distance via le protocol X, c’est un peu comme le tunnel X11 SSH mais en plus direct, sur un test glxgears LLVMpipe on passe de 17fps en tunnel SSH à 20fps en direct. C’est une des méthodes les plus complexes à mettre en place. Il ne faut l’utiliser que si le poste est protégé par un routeur en mode NAT avec un par feu limitant les adresses IP autorisées, sur un réseau local, ou éventuellement au travers d’un tunnel encrypté du genre VPN, mais avec bon chiffrement, car peut être très dangereux.

Par défaut, le protocole tcp X est désactivé sur le serveur X des distributions récentes. Pour l’activer, il faut modifier la ligne de /etc/X11/xinit/xserverrc en retirant la directive -nolisten tcp, à faire sur le serveur X (donc le poste client qui affichera l’application). Cela donnera quelque chose comme ça (attention, cela ne marche pas avec systemd) :

#!/bin/sh
#exec /usr/bin/X -nolisten tcp "$@"
exec /usr/bin/X "$@"

Attention XDMCP va écouter sur le port 6000 en TCP, penser à le protéger sur un poste nomade ou qui n’est pas derrière un parre-feu

Vous pouvez le protéger comme suit (il faut être root ou le faire en sudo), si vous n’avez pas encore de règle. On définit d’abord l’adresse IP du seul host à autoriser dans la variable HOST_A_AUTORISER (j’ai donné 192.168.0.2 pour l’exemple, il faut le remplacer). Il peut être nécessaire d’autoriser la sortie si vous avec un DROP par défaut (ce que je conseillerais plutôt)

HOST_A_AUTORISER=192.168.0.2
iptables -I INPUT -p tcp --dport 6000 -m comment --comment "interdit tout X11" -j DROP
iptables -I INPUT -p tcp --dport 6000 -s ${HOST_A_AUTORISER} -m comment --comment "autorise host toto X11" -j accept

Il faut ensuite relancer le serveur X.

Puis sur le poste client contenant le serveur X, il faut autoriser le serveur d’application à accéder à X :

xhost + $serveur_application

Et ajouter les règles d’autorisation de pare-feu. Par exemple, sur un poste utilisant le noyau Linux (interface locale est typiquement eth1 ou autre à déterminer :

iptables -I INPUT -s $serveur_application -d $serveur_X -i $interface_locale -p tcp -m tcp --dport 6000 -j ACCEPT -m comment --comment --comment "connexions X"
iptables -I OUTPUT -d $serveur_application -s $serveur_X -o $interface_locale -p tcp -m tcp --sport 6000 -j ACCEPT -m comment --comment "connexions X"

Sur le serveur d’application c’est le contraire :

iptables -I OUTPUT -s $serveur_application -d $serveur_X -o $interface_locale -p tcp -m tcp --dport 6000 -j ACCEPT -m comment --comment "connexions X"
iptables -I INPUT -d $serveur_application -s $serveur_X -i $interface_locale -p tcp -m tcp --sport 6000 --dport 1024: -j ACCEPT -m comment --comment "connexions X"

Sur le serveur d’application, il faut alors définir le client. Typiquement, sous bash :

export DISPLAY $serveur_X:0

Pour des raisons de sécurité et séparation des interfaces il est possible de l’afficher sur une session X différente de celle utiliser pour les travaux locaux (il faut dans ce cas tout préparer) :

export DISPLAY $serveur_X:1

Tester avec une commande de base xterm, xclock ou autre. Si ça fonctionne bien, cela devrait fonctionner avec n’importe quelle application.

Serial port (UART)

If there isn’t network, for the u-boot sequence, and in some other cases. Connect using (replace the x by the good number):
* A serial cable between the controling computer and cubieboad and use the /dev/ttySx port.
* A standard (PL2303 compatible) USB<=>serial cable/adapter and use, on the controling computer, the /dev/ttyUSBx port.

SSH

ssh user@cubieboard

SSH + remote X application using SSH tunnel

SSH X11 forwarding shoud be authorized for this. In /etc/ssh/sshd_config, the following line should be here:

X11Forward yes

If that was not the case, sshd must be restarted to activate this option.

With this method, about 3D applications:
* If only software OpenGL or OpenGL ES, this work, but really slow.
* If hardware accelerated OpenGL ES, this doesn’t work at all.
A solution is to use LLVMpipe (fastest pure software OpenGL implementation), there will then be full OpenGL, with remote display, but purely CPU/SIMD rendered :

LIBGL_ALWAYS_SOFTWARE=1 $application

or

export LIBGL_ALWAYS_SOFTWARE=1
$application

ssh -X user@cubieboard

XDMCP

With this method, about 3D applications:
* Software OpenGL and software or hardware accelerated OpenGL ES don’t work at all (at least in a x86<->arm mix environment), you can still use LLVMpipe.

On Cubieboard, in /etc/lightdm/lightdm.conf

[XDMCPServer]
enabled=true

Then restart lightdm like this:

service lightdm restart

On the controling computer :
Install xnest package if needed then:

Xnest :1 -query cubieboard

VNC

On the cubieboard. Install a VNC serveur, for example tightvncserver (vnc4server want a password by default) :

apt-get install tightvncserver

Add in /etc/lightdm/lightdm.conf

[VNCServer]
enabled=true

Then restart lightdm as follow:

service lightdm restart

On the controling computer
* Install xvncviewer package (for example) if needed, then

xvncviewer cubieboard

Leave a Reply