| commit | dc0eec8db7df0fe88c16c381f69ba25ab0a2d18e | [log] [tgz] |
|---|---|---|
| author | Andrew Geissler <geissonator@yahoo.com> | Tue Nov 02 12:28:11 2021 -0500 |
| committer | Andrew Geissler <geissonator@yahoo.com> | Tue Nov 02 12:36:05 2021 -0500 |
| tree | bd9f07978a147838960e9d1a8942d01731aa4e30 | |
| parent | 2e93a03dafe195c90b60fc3e8c279d7dc925cefc [diff] |
ssh-console: introduce reasonable timeout values The obmc-console design is that it must successfully send its data to all connected clients before it will process any new data. This guarantees there are no data losses to clients. The drawback to this design is that if a single client stops responding or gets hung up in some way, all clients get hung up. At IBM, our test teams utilize some fairly extensive perl/expect based test suites that utilize the host virtual console extensively. We continue to see intermittent issues when running these test suites where the virtual console to our hypervisor becomes unusable. If we log in and start to kill dropbear ssh console sessions, we eventually find the right one and the console starts working again. This commit introduces some parameters to dropbear to drop the bad client connection if it becomes unresponsive: -I <idle_timeout> -K <keepalive> For idle_timeout, it seems reasonable to give the client 30 minutes (1800 seconds) of inactivity. For keepalive, it seems reasonable to assume that a client connection can be verified within 10 seconds. Tested: - The issue is somewhat difficult to recreate but we did patch a system which was having this issue and we were unable to recreate the problem with this change. The test suite appears to recover if it senses it has a dropped connection. Signed-off-by: Andrew Geissler <geissonator@yahoo.com> Change-Id: Iaa1182d52fb75762c47e515e43f1fc6352b5bdd1
Note: In addition to a toolchain and autoconf tools, this requires autotools-archive to be installed.
To build this project, run the following shell commands:
./bootstrap.sh
./configure ${CONFIGURE_FLAGS}
make
To fully clean the repository, run:
./bootstrap.sh clean
Running the server requires a serial port (e.g. /dev/ttyS0):
touch obmc-console.conf ./obmc-console-server --config obmc-console.conf ttyS0
To connect to the server, simply run the client:
./obmc-console-client
To disconnect the client, use the standard ~. combination.
This shows how the host UART connection is abstracted within the BMC as a Unix domain socket.
+--------------------------------------------------------------------------------------------+
| |
| obmc-console-client unix domain socket obmc-console-server |
| |
| +---------------------+ +------------------------+ |
| | client.2200.conf | +---------------------+ | server.ttyVUART0.conf | |
+---+--+ +---------------------+ | | +------------------------+ +--------+-------+
Network | 2200 +--> +->+ @obmc-console.host0 +<-+ <--+ /dev/ttyVUART0 | UARTs
+---+--+ | socket-id = "host0" | | | | socket-id = "host0" | +--------+-------+
| | | +---------------------+ | | |
| +---------------------+ +------------------------+ |
| |
| |
| |
+--------------------------------------------------------------------------------------------+
This supports multiple independent consoles. The socket-id is a unique portion for the unix domain socket created by the obmc-console-server instance. The server needs to know this because it needs to know what to name the pipe; the client needs to know it as it needs to form the abstract socket name to which to connect.