Execute arbitrary shell commands on exporter machine

[nvincent-vossloh]

Hello,

I use labgrid to test micro-controller based boards. The board under test is connected through a serial interface and network interface directly to the exporter machine.
The exporter machine has two network interfaces, one towards the board(s), the other towards the LAN + internet, the network connection is shared (board can access the LAN + internet, hosts on LAN cannot access board behind the exporter).

I wish to execute some arbitrary commands on the exporter to communicate with the board (ping <board-ip>, curl http://<board-ip>, ...)
I wish to understand what is the best way to do this. I was thinking of defining on the exporter an SSHDriver to localhost in order to be able to send command but somehow I think I am missing something and believe there is another alternative (which I have not found).

Has someone an idea for this ?

Thanks in advance 🙂

[Bastian-Krause]

Using a driver on something else than the DUT is not the designated way.

If the IP/hostname of the board is (somewhat) static, you could export a NetworkService resource on your exporter. Then you could use the SSHManager to run your command:

from labgrid.util import sshmanager

exporter = networkservice.extra.get("proxy") # exporter host name
ssh = sshmanager.get(exporter)
ssh.run_check(f"ping {networkservice.address}")
ssh.run_check(f"curl http://{networkservice.address}")

Instead of using the NetworkService to retrieve the exporter hostname and the DUT's IP/hostname, you could use hard-coded values alternatively, but this would be less flexible. If this solution is meant to be reusable, you could even export the NetworkService in isolated mode and check for that (networkservice.extra.get("proxy_required")): if it's isolated, use SSHManager, if not, simply use subprocess.run().

[jluebbe]

For re-usability, I'd suggest that, instead of trying to run arbitrary commands from the test cases, you'd write Drivers which expose the necessary functionality in a abstracted way. For example, take a look at the NetworkInterfaceDriver, which allows controlling functionality related to a network interfaces on the exporter which is assigned to a DUT.

[nvincent-vossloh]

Here is what I have done so far, I added a NetworkService resource in the exported.yaml file:

  NetworkService:
    address: boardhostname.local
    username: whatever-there-is-no-ssh-server-at-this-address

Then from the exporter I can:

from labgrid import Environment
from labgrid.resource.networkservice import NetworkService
from labgrid.util import sshmanager
env = Environment('env.yaml')
t = env.get_target('targetname')
ns = t.get_resource(NetworkService)
exporter = ns.extra.get("proxy")
ssh = sshmanager.get(exporter)
ssh.run_check(f"ping -c 1 {ns.address}")

However, when I run this set of commands from another client which is not the exporter itself, the exporter get the hostname of the exporter and there is no DNS entries created for linux machines (sic). I have tried to specify --hostname and --name to labgrid-exporter command but I still get the machine hostname in exporter.

@jluebbe I agree, executing arbitrary commands from the test is not ideal. However I am not sure that adding new drivers for very specific purposes (ping, curl to perform http/api, ...) is ideal. This would require users to install labgrid each time I add a new driver for a command.
Unless it is possible to have labgrid drivers out of tree ?

[jluebbe]

Yes, you can have out of tree drivers. The imports: key in the environment serves that purpose: https://labgrid.readthedocs.io/en/latest/man/device-config.html#imports

[nvincent-vossloh]

Yes, you can have out of tree drivers. The imports: key in the environment serves that purpose: https://labgrid.readthedocs.io/en/latest/man/device-config.html#imports

Thank you so much ! I will look into it.

[nvincent-vossloh]

Hi,

I played with the concepts of labgrid drivers in order to be able to execute requests method from the exporter to the DUT. This works nicely however I am facing an issue related to the management of the python modules installed on the exporter.

When using the exporter as a proxy to execute python code, the module used (requests in my case) is the one installed on the system. How could I control which version to use or even better select a virtual environment at a known location in order to make sure I am using the proper module version.

Here are some more details:
My dut is connected directly to the exporter through an ethernet cable, the dut hosts a web server over https. The uri used to access the dut is https://<hostname>.local, I self-signed a certificate for *.local (which is against good practices, because this is a wildcard top level domain). However, with urllib3 >=2.0 it is not permitted to use a wildcard on a top level domain (.local in my case).

certificate verify failed: Hostname mismatch, certificate is not valid for \'<hostname>.local\'

Note that if the certificate is signed for <hostname>.local instead of *.local, urllib3>=2.0 does not complain.

I have two option to fix this issue:

1. Make sure that the python code executed on the exporter uses an old version of urllib3, and live on with the wildcard on a TLD certificate.
2. redesign hw and sw to be able to load custom certificate for each board.

As you can imagine, solution 2 is clearly on the roadmap but I would like to be able to implement solution 1, at least in order to be able to control the python environment of the exporter.

Thanks.

[jluebbe]

Ah, for the requests use-case, you should be able to use the forward_local context manager on NetworkInterfaceDriver. That way, you're running the HTTP client (requests) locally and there is no need to have special module versions on the exporter. It also better follows labgrid's approach of having most logic on the client.

[nvincent-vossloh]

Ah, for the requests use-case, you should be able to use the forward_local context manager on NetworkInterfaceDriver. That way, you're running the HTTP client (requests) locally and there is no need to have special module versions on the exporter. It also better follows labgrid's approach of having most logic on the client.

Just to make sure, this implies that I cannot test mdns resolution through my http client anymore ? (I use https://.local/ as url). I must provide an url like this https://localhost:localport/ ?

Thanks for your help.