Comments (5)
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 the
OVERRIDESsection 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:
- 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 dossh consolepi myalias -b 115200
if you wanted to use a different baud then what's configured for the alias.
- By IP directly to the device as you are doing.
- 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 sshmyalias@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 theconsolepi
user connect directly to the menu. Otherwiseconsolepi@consolepi
launches directly to the menu, andconsolepi@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.
Related Issues (20)
- AttributeError when renaming device HOT 2
- Include drivers for Aruba 9000 Series gateway series HOT 4
- FTDI missing serial numbers HOT 2
- consolepi-mdnsreg failed HOT 6
- Custom baud rates for different serial consoles? HOT 1
- Latest RaspberryPi OS uses incompatible python version HOT 1
- Cannot change Hotspot SSID HOT 2
- Menu will not load HOT 3
- ipv4.ip_forward not persisting HOT 4
- Installation fails on Pi 1B Buster HOT 2
- Integration of serial ports ttySC0 + ttySC1 to local serial adapter list? HOT 4
- zero 2 W Install hung up HOT 2
- Install errors out HOT 3
- Error HASH not match from the requirements file HOT 1
- Hardware-Serial via PCI not detected. HOT 4
- Console-menu issue HOT 2
- Bluetooth connection on Windows 11 HOT 1
- Refactor ESPHome Power Logic to Also Support Home Assistant HOT 2
- AutoHotSpot not working on Raspbian 12? HOT 4
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from consolepi.