Aliases take over serial port names about consolepi HOT 5 CLOSED

ConsolePi can handle the alias definition and auto create both the associated udev rule and the ser2net config.

Use the rn option in the menu or consolepi-addconsole. The system defaults stay the same i.e. /dev/ttyUSB0, will still exist, but ConsolePi always reflects the alias name.

I expect the remote launcher is trying to connect to ttyUSB0 because the sshd_config is telling it to. Use /dev/alias-name in the sshd_config.

Ideally let ConsolePi do it as described above. To prevent conflict (if you wanted to use it later).

from consolepi.

That's the thing, once an alias is set, users can't connect to the original device-name ttyUSB0. Users or I would have to manually edit sshd_config to reflect new aliases.
I can probably script something for ourselves that will change sshd_config to reflect either the udev-rule or ser2net config.

An enhancement would be if ConsolePi could set its own "internal" alias (cpi0,1,2...) when it detects new cables. Since udev-rule SYMLINK allows for more than one alias, ConsolePi would still allow user-aliases. 3rd-party scripts or configs like mine would still work using the ConsolePis alias cpi0. I think predictability would increase out of the box for FTDI chips.
I might be able to create this, it would take me some more time as I would have to understand the code better and what it does :)

from consolepi.

I see what's going on. The remote_launcher was designed to facilitate connections from a remote ConsolePi. i.e. ConsolePi-A through mdns, or cloud (gdrive) sync will discover ConsolePi-B and display all of it's connections in it's menu. The adapter detection for all of it (local or remote) uses the aliases if set. Otherwise you would have duplicate entries for the same device in the menu, which obviously wouldn't be desired.

An enhancement would be if ConsolePi could set its own "internal" alias (cpi0,1,2...) when it detects new cables. Since udev-rule SYMLINK allows for more than one alias, ConsolePi would still allow user-aliases. 3rd-party scripts or configs like mine would still work using the ConsolePis alias cpi0. I think predictability would increase out of the box for FTDI chips.

The Predictable Console Ports section of the installer, which is the same as the rn (rename) option in the menu and the consolepi-addconsole convenience command available after the install, are designed for that exact purpose. It's why it comes last in the installer, and defaults to [yes]. You should avoid using /dev/ttyUSB#, /dev/ACM#, /dev/SC#etc... as those are not tied to a specific adapter, and could potentially represent a different adapter after reboot. Also when you create the alias with one of the built in options, you set the baud for that device, otherwise the default baud is used (9600, unless a different one is provided in theOVERRIDESsection of the config. That's why you should use/dev/myaliasin sshd_config vs/dev/ttyUSB#`

So this one I don't think is necessary, once you set the alias via one of the options ConsolePi provides, just reference the adapter by that alias.

It does however potentially make sense to add /etc/sshd_config as part of the consolepi-addconsole / rn (rename) logic, but I need to determine how best to implement that. As it could be done a lot of different ways:

1. A single alternate SSH port where you provide the device name you want to connect to. i.e. ssh consolepi myalias

• currently it evaluates myalias but my intent for that option is to allow you to override any other setting by passing any additional arguments provided directly to picocom. So you could do ssh consolepi myalias -b 115200 if you wanted to use a different baud then what's configured for the alias.

2. By IP directly to the device as you are doing.
3. Then there is the option to create a new user, with limited permissions that launches directly to the device. Similar to how their is the option to have the consolepi user launch directly to the menu. So ssh myalias@consolpi would connect to /dev/myalias automatically. That method would also have the same alternate of a single user for direct remote connections where you use one user for that function, but specify the device. Actually it makes sense to make that an automatic function of having the consolepi user connect directly to the menu. Otherwise consolepi@consolepi launches directly to the menu, and consolepi@consolepi myalias launches directly to /dev/myalias

I also need to sort out how to create a tty on the ConsolePi side so the user doesn't need to provide the -t option to SSH. To rename the sshd_config this should work (not tested) sudo sed -i 's|\dev\ttyUSB0|\dev\myalias|' /etc/sshd_config. Try it without the -i to validate as that will output to stdout without changing the file in-place, and obviously replace the old/new device reference as appropriate.

Also when this is implemented I won't use sshd_config directly, I'll use /etc/ssh/sshd_config.d/consolepi.conf as all .conf files in that directory are read in.

from consolepi.

After looking into it. You can actually launch directly to the default port names when there is an alias. Again, it's still not advisable, but you can.

Using /etc/ConsolePi/src/remote_launcher.py <device-name> Was just some convenience logic I added to remote_launcher to test what could be done with this. I was trying to make it more user friendly, so you just provide <device-name>. remote_launcher looks up the details for the device and plugs the rest of the options in.

When you select a console connection from a remote ConsolePi menu it provides the full command with all flags.

So you could either use: /etc/ConsolePi/src/remote_launcher.py "picocom /dev/ttyUSB0 --baud 115200 --flow n --databits 8 --parity n --stopbits 1" or bypass remote_launcher and call directly to picocom.

One of the functions of remote_launcher is giving you the option to kill a hung session. This can happen if you connect, walk-away and your PC goes to sleep. The picocom session was never terminated, but your SSH session was. So when you try to re-connect to it the port is occupied. remote_launcher will detect that, and ask if you want to kill and reconnect. You could also launch into tmux or byobu (a wrapper for tmux) it runs in a sub-shell, so you can always reconnect and re-attach. Eventually I plan to have the menu auto-launch into byobu/tmux and when you connect to a device have it launch to a new tab.

Still has to be ssh -t I haven't come across a way to get around the need to do that for the tty to be built (impacts how picocom is able to accept the CTRL keys).

from consolepi.

Closing this, nothing to fix in the local adapter detection logic. Previous post describes the options. Will consider adding ssh match rules to part of rename logic.

from consolepi.