Sharing a DUT

Hardware is expensive, and the people who need it are rarely in the same building as the board. A customer wants to reproduce a bug on your silicon; a partner needs to validate their firmware on your reference design; Linaro support needs to look at a board crash.

The problem is never “how do I let them power-cycle the board”, it is “how do I let them power-cycle the board without putting them on my lab network”.

The LAA answers that by making the DUT reachable through interfaces that are narrower than a network route. There are three of them, from most to least restricted.

Choosing how to share

API token

SSH account

LMS remote access

Grants

Control of the DUT

A shell on the appliance

A shell on the appliance

Reaches your lab network

No

Yes

Yes

Granted by

An appliance admin

An appliance admin

The appliance owner, per session

Revoked by

Deleting the token

Deleting the key

Stopping the session

Suitable for customers

Yes

No

No

Start narrow

If you are unsure, give an API token. It is the only option that lets you hand remote access to your hardware to an untrusted party (a customer, a prospect) while your network stays untouched.

API access (narrowest)

An API token gives its holder the LAA REST API and nothing else. They can drive the DUT completely (power, buttons, USB, serial console, file transfers, USB mass storage emulation) but they cannot run arbitrary commands on the appliance and they cannot reach anything else on your network.

From their side, the experience is the one described in Developing on a DUT: they install laam, register an identity pointing at your appliance, and work.

API access

When granting only API access, you can grant remote access to your hardware to any users, including potential customers, while keeping your local network safe. In fact, the user will only be able to interact with the DUT and nothing else on your network.

To share a DUT this way:

  1. Make sure the appliance is reachable by the remote user, either on a network they can already reach, or exposed deliberately by your IT department. The appliance never opens inbound ports by itself; see Network Requirements.

  2. Create a token on the appliance profile page and send it to them over a channel you trust.

  3. Tell them which DUT is attached and where its wiring is documented — the corresponding page in Devices Overview.

Revoking is a single click: delete the token, and every client using it stops working immediately.

SSH access (full appliance)

Adding an SSH public key authorises a shell on the appliance as the torizon account. That is genuinely useful: it is the only way to run tooling that has to live on the appliance, and the appliance can act as a jump host onto the 198.18.0.0/24 private network to reach the DUT or a BMC, as shown for the Ampere Server Platforms.

It is also much broader than API access:

SSH grants network access

A shell on the appliance means the holder can reach whatever the appliance’s public interface can reach: that is, your lab network. Reserve SSH keys for people you would already trust on that network, and use API tokens for everyone else.

Keys are managed from the appliance web interface or with laam ssh, and removing a key takes effect immediately for new connections, though it does not kill sessions that are already open.

LMS remote access (for Linaro support)

When you need Linaro to look at an appliance, you do not have to open a hole in your firewall. From the LAA page in LMS, the appliance owner starts a remote access session: the appliance opens an outbound, end-to-end encrypted sshx tunnel over HTTPS, and a console becomes available in the browser. A read-only console link is available too, which is the right one to use when you just want someone to watch.

Owner permission

Permissions to use remote access should be granted by the owner prior to any use, and the session should be stopped when the debugging is over. Anyone who knows the session URL can join it: do not share that URL.

Where the boundary actually is

Sharing safely relies on the appliance’s isolation properties, which hold in all three cases:

  • the DUT sits alone with the appliance on a private network and is not routed anywhere: a shared DUT cannot probe your lab even if its user installs whatever they like on it

  • the appliance only ever makes outbound HTTPS connections; no inbound port needs to be opened for LMS, OTA or remote access

  • if the shared DUT needs internet access for a test suite, it goes through the wstunnel tunnel to a restricted set of cloud services: still not through your lab network, and disabled by default

The full picture, including the protocols and destinations involved, is in LAA Overview for IT Departments and LAA & Security.

Getting help yourself

If it is you who needs support rather than your customer, see Support and the Troubleshooting & FAQs. Before opening a ticket, the output of laam system version, laam services list and laam system logs is usually what Linaro will ask for first.