Question about visit remote serial in private network.

[atline]

There are 3 pcs here:

10.192.244.21: with labgrid coordinator, labgrid-client
10.192.244.1: with a http proxy: http://10.192.244.1:3128
192.168.1.10: with a labgrid exporter, the ser2net configure also points the same 192.168.1.10

Usually, we could use ProxyCommand corkscrew 10.192.244.1 3128 %h %p to login 192.168.1.10 from 10.192.244.21, but how could labgrid-client -p my_place console could visit the serial inside the private network?

NOTE: I have full control of 10.192.244.21 & 192.168.1.10 , while I have no control for 10.192.244.1 which is a proxy server maintained by IT.

Does -P parameters help? Or any other suggestion? Thanks~

[Emantor]

We assume that all exporters are on the same local network. Currently the proxy feature requires a direct SSH connection to some computer on the exporter network. With the correct SSH configuration you should be able to:

• Switch the exporter into isolated mode using -i/--isolated (this will cause your computer to always connect to the exporter and tunnel network traffic over SSH port forwarding)

Note that this is not per se labgrid issue and you will also run into problems using only plain IP addressing, labgrid expects a working DNS configuration as well.

[atline]

I used your suggestion but looks failed to make it work.

So I want to confirm it again, @Emantor @jluebbe

• 10.192.244.21 has coordinator & labgrid-client
• 192.168.100.114 has the exporter
• From 192.168.100.114 we could directly visit 10.192.244.21 without proxy, but from 10.192.244.21 we need a proxy to visit 192.168.100.114

What I did:

1. Setup .ssh/config with ProxyCommand corkscrew my_proxy_ip 3128 %h %p, also paste the .ssh/id_rsa.pub of 10.192.244.21 to authorized_keys of 192.168.100.114, now on 10.192.244.21, I could directly use ssh 192.168.100.114 to login to that exporter without any password etc.

2. Follow your suggestion, I add -i in exporter with next:

docker run -idt -e LG_CROSSBAR=ws://10.192.244.21:20408/ws \
    --name labgrid-exporter \
    -v `pwd`/exporter.yaml:/opt/conf/exporter.yaml \
    -v /etc/localtime:/etc/localtime \
    labgrid-exporter /entrypoint.sh -i

And I also confirm the PID is next in container:

root@f11ef91fe1ac:/# ps aux
USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
root         1  0.0  0.0   2388   752 pts/0    Ss+  13:59   0:00 /bin/sh /entrypoint.sh -i
root         7  0.0  0.2  51728 38916 pts/0    S+   13:59   0:01 /usr/bin/python3 /usr/local/bin/labgrid-exporter -i /opt/conf/exporter.yaml

NOTE: we directly use next in exporter.yaml, so we no need to add more flags when start container. The serial already predefined with a ser2net configure.

imx8mn-evk-sz07:
  NetworkSerialPort:
    host: 192.168.100.114
    port: 11004
  PDUDaemonPort:
    host: 192.168.100.114
    pdu: 192.168.100.110
    index: 6

3. On 10.192.244.21, use labgrid-client -p my_place lock, it's ok to lock the device, we no need LG_PROXY as client and coordinator in same network.

4. On 10.192.244.21, use labgrid-client -p my_place console, it shows next, then no further output:

connecting to NetworkSerialPort(target=Target(name='imx8mn-evk-sz07', env=None), name='NetworkSerialPort', state=<BindingState.bound: 1>, avail=True, host='192.168.100.114', port=11004, speed=115200, protocol='rfc2217') calling microcom -s 115200 -t 192.168.100.114:11004

Which same as before, won't it should somehow use a ssh tunnel to visit 192.168.100.114? What should the correct situation looks like?

[Emantor]

Which version of labgrid are you running there? I created a local exporter with isolation and a single USBSerialPort:

~/wo…/ptx/labgrid  labgrid-exporter exporter_isolated.yaml -i
crossbar URL: ws://labgrid.discworld.emantor.de:20408/ws
crossbar realm: realm1
exporter name: lordvetinari
exporter hostname: lordvetinari
resource config file: exporter_isolated.yaml

SessionDetails(realm="realm1",
               session=7222977142151123,
               authid="exporter/lordvetinari",
               authrole="public",
               authmethod="ticket",
               authprovider="dynamic",
               authextra={'x_cb_node': 'labgrid.discworld.emantor.de-912', 'x_cb_worker': 'worker001', 'x_cb_peer': 'tcp4:192.168.128.10:38908', 'x_cb_pid': 917},
               serializer="cbor.batched",
               transport="websocket",
               resumed=None,
               resumable=None,
               resume_token=None)
('rendered',
 "keks:\n  USBSerialPort:\n    match:\n      '@ID_SERIAL_SHORT': P-00-03568")
('loaded',
 OrderedDict([('keks',
               OrderedDict([('USBSerialPort',
                             OrderedDict([('match',
                                           OrderedDict([('@ID_SERIAL_SHORT',
                                                         'P-00-03568')]))]))]))]))
add resource keks/USBSerialPort: USBSerialPort/OrderedDict([('match', OrderedDict([('@ID_SERIAL_SHORT', 'P-00-03568')]))])
{'cls': 'NetworkSerialPort', 'params': OrderedDict(), 'acquired': None, 'avail': False}
{'cls': 'NetworkSerialPort', 'params': OrderedDict([('host', 'lordvetinari'), ('port', None), ('speed', 115200), ('extra', {'path': '/dev/ttyUSB0', 'proxy_required': True, 'proxy': 'lordvetinari.discworld.emantor.de'})]), 'acquired': None, 'avail': True}
2021-11-12T09:13:00 Starting ser2net with: /run/current-system/sw/bin/ser2net -d -n -Y connection: &con01#  accepter: telnet(rfc2217,mode=server),58859 -Y   connector: serialdev(nouucplock=true),/dev/ttyUSB0,115200n81,local
2021-11-12T09:13:00 started ser2net for /dev/ttyUSB0 on port 58859
{'cls': 'NetworkSerialPort', 'params': OrderedDict([('host', 'lordvetinari'), ('port', 58859), ('speed', 115200), ('extra', {'path': '/dev/ttyUSB0', 'proxy_required': True, 'proxy': 'lordvetinari.discworld.emantor.de'})]), 'acquired': 'tac', 'avail': True}

This gets locked to a place named tac:

 ~  lgc -p tac lock                                                                   ✔  09:12
acquired place tac

Connecting to the serial via labgrid-client:

  DEBUG: expanded remote resources for place tac: [NetworkSerialPort(target=Target(name='tac', env=None), name='USBSerialPort', state=<BindingState.bound: 1>, avail=True, host='lordvetinari', port=58
859, speed=115200, protocol='rfc2217')]
  DEBUG: Creating SSHConnection for lordvetinari.discworld.emantor.de
  DEBUG: No existing control socket found
  DEBUG: ControlSocket: /tmp/labgrid-connection-4ockvlwk/control-lordvetinari.discworld.emantor.de
  DEBUG: Master Start command: ssh -x -o LogLevel=ERROR -o PasswordAuthentication=no -n -MN -o ConnectTimeout=30 -o ControlPersist=300 -o ControlMaster=yes -o ControlPath=/tmp/labgrid-connection-4ock
vlwk/control-lordvetinari.discworld.emantor.de -o StrictHostKeyChecking=yes lordvetinari.discworld.emantor.de
  DEBUG: Connected to lordvetinari.discworld.emantor.de
   INFO: Created new SSH connection to lordvetinari.discworld.emantor.de
  DEBUG: Started keepalive for lordvetinari.discworld.emantor.de
  DEBUG: Running control command: ssh -x -o LogLevel=ERROR -o PasswordAuthentication=no -o ControlMaster=no -o ControlPath=/tmp/labgrid-connection-4ockvlwk/control-lordvetinari.discworld.emantor.de -
O forward -L39421:lordvetinari:58859 lordvetinari.discworld.emantor.de
connecting to NetworkSerialPort(target=Target(name='tac', env=None), name='USBSerialPort', state=<BindingState.bound: 1>, avail=True, host='lordvetinari', port=58859, speed=115200, protocol='rfc2217'
) calling microcom -s 115200 -t localhost:39421
connected to ::1 (port 39421)
Escape character: Ctrl-\

With the debug output you can clearly see that the isolation mode works correctly, It first creates an SSH connection to the exporter and than microcom connects to the forwarded port on localhost.

[atline]

I checked, this is because not all the resource in the scope of so called "isolated", here, NetworkSerialPort won't set proxy_required, so it could work after we change to RawSerialPort, so some question here:

1. Why you make NetworkSerialPort config in exporter.yaml not benifit from isolated?

2. The same things happens on PDUDaemonPort. Although I could make it work by directly export http_proxy to make it work (this use requests library), I still want to confirm why exporter can't make it isolated, then user no need to do an additional action of http_proxy export?

3. Why this commit here? 57e4b7e
   You mentioned:

We shouldn't disable the checks configured in the normal SSH config for connections to exporters.

But with explicit StrictHostKeyChecking=yes, you still not respect the user config in ~/.ssh/config if user clearly set no in his config, why not directly delete this line?

4. The isolated exporter will directly use FQDN as the proxy, if possible let user specify it in exporter with a IP?

5. The client will use something like -L42163:cake:55945 cake, besides the second cake here which I mentioned in item4, if possible the first cake could also use a IP? Why labgrid force to use fqdn, as without labgrid, ssh tunnel could works well with IP.

[Emantor]

1. Why you make `NetworkSerialPort` config in `exporter.yaml` not benifit from `isolated`?

We do, thats why I was asking for your version. This was recently fixed in e3180cb, but hasn't made it into a stable release yet.

2. The same things happens on `PDUDaemonPort`. Although I could make it work by directly export `http_proxy` to make it work (this use requests library), I still want to confirm why exporter can't make it isolated, then user no need to do an additional action of http_proxy export?

See above.

3. Why this commit here? [57e4b7e](https://github.com/labgrid-project/labgrid/commit/57e4b7e278ad5f8176c76ee81ec3a0e5c8b6f307)
   You mentioned:

We shouldn't disable the checks configured in the normal SSH config for connections to exporters.

But with explicit StrictHostKeyChecking=yes, you still not respect the user config in ~/.ssh/config if user clearly set no in his config, why not directly delete this line?

If the user is connecting to the exporter for the first time, we can't handle the prompt, so we fail the connection, expect the user to connect once manually, confirm the hostkey and afterwards connections will work fine.

1. The isolated exporter will directly use FQDN as the proxy, if possible let user specify it in exporter with a IP?

As I said above, labgrid expects a fully working DNS setup with resolvable hostnames. You can kind of work around this by setting the exporter hostname explicitly to the IP address, but I encourage you to instead set up a working DNS for you network.

2. The client will use something like `-L42163:cake:55945 cake`, besides the `second cake` here which I mentioned in item4, if possible the `first cake` could also use a IP? Why labgrid force to use fqdn, as without labgrid, ssh tunnel could works well with IP.

See above.

[atline]

Thanks, I use 0.4.0, after apply above patch it's ok now.

[Emantor]

FYI, I just released 0.4.1 containing the fix.