With the shift (a while ago) to new access blocks, it appears that the defaultaccess directive in the config block is broken. A quick look at the code implied that the config value is being set, but never actually used during execution. It doesn't look like the -a option works either, which makes sense if the code isn't ever looking at the value.

Recently we have been seeing several: "conserver[22453]: *** buffer overflow detected ***: /usr/sbin/conserver terminated"

I have looked and I note that sprintf ( ) is being used in cutil.c in the functions FileOpenFD( ) FileOpenPipe( ) and FileOpen( ).

I believe using snprintf( ) would prevent this from happening and would be a simple fix.

Please note: I created a merge which I think will fix this, but I do not normally code so it should be check carefully:
#92

I'm considering conserver for an internal IPv6-only network that is only backward compatible with IPv4 on the outside. This is a delightful relaxation in things like address assignment and firewalling. Is it perhaps time to add IPv6 support to conserver?

A basic configuration with a simple task will cause the server to emit the following error message about 50-80% of the time the task is run:

[Wed Apr 29 02:00:24 2020] conserver (1086): ERROR: FileRead(): fd 7: Input/output error

I'm using the 8.2.3 version distributed by Gentoo. I don't think there's anything in 8.2.4 that would fix this, but I can give it a try if necessary. I can reliably reproduce this issue by running the task a few times with the following configuration:

access * {
        trusted localhost;
}

console 1 {
        rw *;
        type device;
        parity none;
        device /dev/ttyS55;
        baud 9600;
        master localhost;
        logfile /tmp/&.log;
        logfilemax 4m;
        tasklist c;
}

task c {
        cmd "/bin/true";
}

The entire output from the server:

[Wed Apr 29 02:00:04 2020] conserver (1085): conserver.com version 8.2.3
[Wed Apr 29 02:00:04 2020] conserver (1085): started as `root' by `root'
[Wed Apr 29 02:00:07 2020] conserver (1086): [1] login root@localhost
[Wed Apr 29 02:00:24 2020] conserver (1086): [1] task started: pid 1095
[Wed Apr 29 02:00:24 2020] conserver (1086): ERROR: FileRead(): fd 7: Input/output error
[Wed Apr 29 02:00:24 2020] conserver (1086): [1] task terminated: pid 1095: exit(0)
[Wed Apr 29 02:03:33 2020] conserver (1086): [1] logout root@localhost

I believe that fd 7 refers to /dev/ptmx in this situation, but I'm not sure how to debug this issue past that. Let me know if I can provide any more information.

After our Identity and Access Management group updated their IPA server to ipa-server-4.9.12-11.module+el8.9.0+20824+f2605038.x86_64 our conservers stopped working with Kerberos authentication.

The OS system still works when using ssh as in 'ssh -AK $FQDN' so the system keytab and kerberos setup is working. However we can only connect via console if kerberos is disabled via 'KRB5_TRACE=/dev/stdout console $ARGS' and supplying the user password each time.

At present we are running:

rpm -qa | grep conserver

conserver-debuginfo-8.2.1-4.3.el7.x86_64
conserver-client-8.2.1-4.3.el7.x86_64
conserver-8.2.1-4.3.el7.x86_64

The server is running:

cat /etc/redhat-release

Red Hat Enterprise Linux Server release 7.9 (Maipo)

Is this something that can be looked at and possible fixed on this end ?

Thanks in Advance.

When trying to build version 8.2.6 with IPv6 support, the build fails with an undefined symbol bindPort:

cc -O2 -pipe  -fstack-protector-strong -fno-strict-aliasing -fstack-protector-strong -o conserver access.o client.o consent.o group.o main.o master.o  readcfg.o fallback.o cutil.o -lbsm -lutil -lcrypt  -lssl -lcrypto  -lwrap -lpam
ld: error: undefined symbol: bindPort
>>> referenced by readcfg.c
>>>               readcfg.o:(ReReadCfg)
>>> referenced by readcfg.c
>>>               readcfg.o:(ReReadCfg)
cc: error: linker command failed with exit code 1 (use -v to see invocation)
*** Error code 1

Stop.
make[3]: stopped in /usr/home/fuz.ports/comms/conserver-com/work/conserver-8.2.6/conserver

This appears to be because main.c doesn't define bindPort when IPv6 support is present, but the code to set the process title still requires the variable. I did not attempt a fix because the code is very convoluted and I don't want to break it.

There also seems to be a problem in another place where the code attempts to use config->primaryport in lieu of bindPort, but then fails to adjust the format string or to apply atoi:

cc -O2 -pipe  -fstack-protector-strong -fno-strict-aliasing -I.. -I.. -I. -DHAVE_CONFIG_H -DSYSCONFDIR=\"/usr/local/etc\" -c -o main.o main.c
main.c:1773:5: warning: format specifies type 'unsigned short' but the argument has type 'char *' [-Wformat]
                         config->primaryport,
                         ^~~~~~~~~~~~~~~~~~~
1 warning generated.

Please fix this, too.

On a recently fresh installation of Rocky Linux I often get disconnected like:

# console n061901
[Enter `^Ec?' for help]
console: FileRead(): SSL error on fd 3
# echo $?
0

This is both the case with 8.2.2-4 provided by EPEL as well as a self-compiled 8.2.6 from a customized SPEC file.

Currently, this version of OpenSSL is installed:

# yum list installed | grep openssl
openssl.x86_64                              1:1.1.1k-5.el8_5                       @baseos       
openssl-devel.x86_64                        1:1.1.1k-5.el8_5                       @baseos-85    
openssl-libs.x86_64                         1:1.1.1k-5.el8_5                       @baseos       
openssl-pkcs11.x86_64                       0.4.10-2.el8                           @baseos

Disabling SSL support during compilation only removes the error message but still disconnects:

# console n061901
[Enter `^Ec?' for help]
# echo $?
0

Any thoughts where to start debugging? If necessary I can share my configuration.

conserver.spec.txt
conserver-nokrb-noopenssl.spec.txt

Hello,

I am running into issues getting a client system running conserver (without serial ports), to reach another conserver (happens to be an RPi with a serial hub). What exactly do I define in the clients conserver config, to have it reach the other conserver with actual serial ports?

If I run console -M (hostname) (console) that works, and if I define the master in "console.cf" that also works as well. The former I could alias in a terminal but I feel there is better way to do this, and for the latter it simply does not scale as I add more conservers into my network.

Thanks,

Ryan

We're having issues connecting to the daemon when a kerberos ticket is available.
This is happening since we upgraded the host running conserver from Centos7 to Centos8Stream, thus moving conserver from 8.2.1 to 8.2.2.

> klist
Ticket cache: FILE:/tmp/krb5cc_3942_So3SEArTmG
Default principal: [email protected]

Valid starting       Expires              Service principal
06/30/2021 08:04:20  07/01/2021 11:45:44  krbtgt/[email protected]
> console -u
console: lost connection
> kdestroy
> console -u
 console1                 up   <none>
 console2                 up   <none>
 console3                 up   <none>
 console4                 up   <none>
[...]

When running the command "./package/make-and-stage-release local" on a Centos 7 machine an error interrupts the execution of the script:
"sed: can't read : No such file or directory"

By sed manual, when using the " -i[SUFFIX] " option there should be no space between the i and the suffix string. Doing so on lines 30 and 31 of the script solves the issue for me.

I think it may be useful to correct it, if it does not cause problems with other systems.

While trying to fix an old wishlist bug for compilation with GSSAPI in Debian (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=826230) I noticed that even with the appropriate gssapi-Headers installed (libkrb5-dev in Debian) it would not enable support for it.

./configure [...] --with-gssapi
[...]
checking gssapi/gssapi.h usability... yes
checking gssapi/gssapi.h presence... yes
checking for gssapi/gssapi.h... yes
checking for gssapi library -lgssapi... no
checking for gssapi library -lgssglue... no
checking for gssapi library -lgss... no
[...]
              GSS-API (--with-gssapi)    : NO

Debugging this I've found an old patch in Fedora from 2013 that tries to link to libgssapi_krb5.

https://src.fedoraproject.org/rpms/conserver/c/753991149a52c7685139f04245573a005c7459a2?branch=master

This patch fixes the issue on Debian as well (renaming the .in to .ac extension in the patch). I have not actually tested GSSAPI, as I don't have the necessary infrastructure in place.

Informational flags: -x, -w, -u, -i do not work on a remote master when a console to filter by is specified.

console -x works as expected:

> console -x
 slot0                    on /dev/cuaU1@localhost             at 115200n
 devpowerctl              on /dev/cuaU0@localhost             at 115200n   

however console -x <console> gives:

> console -x slot0
unknown command  

This is not an issue on the local conserver.

The RunC program is the new method of starting containers. It can do several things with the TTY of each container, including a detached new terminal for which a connection with conserver is not possible. It would be a useful facility to have.

The protocol used is a file descriptor passed as a file handle in ancillary data to a UNIX Domain Socket, which makes sense to cross from the RunC account to that of conserver. The reverse with exec requires the RunC rights in a subprocess of conserver, which is less attractive.

I already started a thread to ask for more descriptive information, like the console/host name (and got a little too excited about other options) but they probably need a use case to support this simple facility. I suppose a conserver with dynamic pickup of arbitrary new TTYs could be such a case.

There have been a few exchanges on the mailing list around clarifying that folks have the right to modify this code (the age of the original code and the license wording used back then was much "looser" than today - ah, the freedom of the original internet). Anyway, we this thread:

https://www.conserver.com/pipermail/users/2019-July/msg00000.html
https://www.conserver.com/pipermail/users/2019-July/msg00001.html
https://www.conserver.com/pipermail/users/2019-July/msg00002.html
https://www.conserver.com/pipermail/users/2020-May/msg00001.html

Time to apply the suggestions in the last email.

I'm running the latest conserver (8.2.6) on a Linux-x86_64 server with nearly 6000 console sessions. Its worked fine literally for years, until yesterday, when it started dying with a buffer overflow error (and signal 6).

The conserver itself is configured as follows:

config * {
    reinitcheck 5;
    initdelay 15;
}
default full {
    rw *;
}
default * {
    logfile /mnt/logs/conserver/&.log;
    logfilemax 2m;
    timestamp 10lab;
    include full;
    port 623;
    options reinitoncc;
    ipmiworkaround checksum;
}

access * {
    trusted 127.0.0.1 ;
    allowed 127.0.0.1 ;
    admin ncotoolsprod,root;
}

All of the individual console sessions are of the following configuration:

console			c001.for002.ix { type ipmi; master	127.0.0.1; host	ipmi.c001.for002.ix; password XXX ; username ABC; }

The only output coming from the conserver when it dies is the following:

[Wed Aug 25 14:30:57 2021] conserver (4773): child pid 17117: signal(6), restarting
*** buffer overflow detected ***: /apps/nco-conserver/sbin/conserver terminated
[Wed Aug 25 14:30:57 2021] conserver (4773): child pid 17118: signal(6), restarting
*** buffer overflow detected ***: /apps/nco-conserver/sbin/conserver terminated
[Wed Aug 25 14:30:57 2021] conserver (4773): child pid 17119: signal(6), restarting
*** buffer overflow detected ***: /apps/nco-conserver/sbin/conserver terminated
[Wed Aug 25 14:30:57 2021] conserver (4773): child pid 17120: signal(6), restarting
*** buffer overflow detected ***: /apps/nco-conserver/sbin/conserver terminated
[Wed Aug 25 14:30:57 2021] conserver (4773): child pid 17121: signal(6), restarting
*** buffer overflow detected ***: /apps/nco-conserver/sbin/conserver terminated
[Wed Aug 25 14:30:57 2021] conserver (4773): child pid 17122: signal(6), restarting
*** buffer overflow detected ***: /apps/nco-conserver/sbin/conserver terminated
[Wed Aug 25 14:30:57 2021] conserver (4773): child pid 17123: signal(6), restarting
*** buffer overflow detected ***: /apps/nco-conserver/sbin/conserver terminated
[Wed Aug 25 14:30:57 2021] conserver (4773): child pid 17124: signal(6), restarting
*** buffer overflow detected ***: /apps/nco-conserver/sbin/conserver terminated
[Wed Aug 25 14:30:57 2021] conserver (4773): child pid 17125: signal(6), restarting
*** buffer overflow detected ***: /apps/nco-conserver/sbin/conserver terminated
[Wed Aug 25 14:30:57 2021] conserver (4773): child pid 17126: signal(6), restarting

If I try stopping the daemon and retarting, it resumes the same sig6 failure behavior. If I reboot the server, then its stable for several hours before descending back into the same mess again.

The server had been up for over a week prior to this problem beginning for the first time.

I'm at a loss where to begin debugging this, and would appreciate any ideas/guidance/assistance.

Just wanted to be the first :-)

Thanks again for conserver: it's changed our lives

root# systemctl reload conserver-server
Failed to reload conserver-server.service: Job type reload is not applicable for unit conserver-server.service.

I realize that this is not built for systems, but it is possible for the init.d script to be built in such a way as to facilitate this though the systemd adaptation process.

Alternatively, for better or worse, systemd is the reality of modern linux(mostly worse IMHO), so developing full-featured systemd support might be the better option.

We upgraded our conserver-server from 8.2.1 to 8.2.4 using the Debian packages and found that previously permitted clients were now refused access:

$ console myhost
10.2.3.4: access from your host refused

I found that the important difference between these two wasn't the source itself, but rather that Debian enabled --with-ipv6 for 8.2.4. Rebuilding 8.2.4 w/o --with-ipv6 restored the previous behavior, allowing clients the impacted clients to connect once again.

Our access block looks like this (with specific IPs/subnets modified for obfuscation):

access * {
       trusted 127.0.0.1,10.2.3.4,10.5.6.0/18,10.6.7.0/18;
       allowed 127.0.0.1,10.2.3.4,10.5.6.0/18,10.6.7.0/18;
}

Tested clients were in one of the /18 networks.

Building on FreeBSD I see:

master.c:566:18: warning: adding 'int' to a string does not append to the string [-Wstring-plus-int]
                                      ":@%s" + iSep, pRC->rhost);
                                      ~~~~~~~^~~~~~
master.c:566:18: note: use array indexing to silence this warning
                                      ":@%s" + iSep, pRC->rhost);
                                             ^
                                      &      [     ]

Clang's suggestion is ":@%s" + iSep -> &":@%s"[iSep]. I'm not entirely sure this is more clear; perhaps this warning ought to be disabled.

So I've been migrating from my old ancient macos desktop to a bright shiny new one running Monterey (12.5.1 at the moment), and in moving conserver I've stumbled on a new error -- the new build of 8.2.4 (from pkgsrc) can't connect to my terminal server:

[Fri Nov 25 17:42:25 2022] conserver (68114): DEBUG: [consent.c:916] [xenful]: trying hostname=controlling.local, ip=10.0.1.240, port=2003
[Fri Nov 25 17:42:25 2022] conserver (68114): ERROR: [xenful]: Unable to connect to 10.0.1.240:2003 Operation now in progress

On the new system:

$ conserver -V
conserver: conserver.com version 8.2.4
conserver: default access type `r'
conserver: default escape sequence `^Ec'
conserver: default configuration in `/etc/conserver.cf'
conserver: default password in `/etc/conserver.passwd'
conserver: default logfile is `/var/log/conserver'
conserver: default pidfile is `/var/run/conserver.pid'
conserver: default limit is 16 members per group
conserver: default primary port referenced as `782'
conserver: default secondary base port referenced as `0'
conserver: options: libwrap, openssl
conserver: openssl version: OpenSSL 1.1.1n  15 Mar 2022
conserver: built with `./configure --sysconfdir=/etc --with-master=localhost --with-port=782 --with-libwrap=/opt/pkg --with-logfile=/var/log/conserver --with-ipv6 --with-openssl=/opt/pkg --enable-static --enable-shared --disable-dependency-tracking --prefix=/opt/pkg --build=x86_64-apple-darwin21 --host=x86_64-apple-darwin21 --sysconfdir=/etc --localstatedir=/var --mandir=/opt/pkg/share/man --enable-option-checking=yes'

On the old system this binary is working fine:

$ /usr/local/sbin/conserver -V
conserver: conserver.com version 8.2.0
conserver: default access type `r'
conserver: default escape sequence `^Ec'
conserver: default configuration in `/usr/local/etc/conserver.cf'
conserver: default password in `/usr/local/etc/conserver.passwd'
conserver: default logfile is `/var/log/conserver'
conserver: default pidfile is `/var/run/conserver.pid'
conserver: default limit is 16 members per group
conserver: default primary port referenced as `782'
conserver: default secondary base port referenced as `0'
conserver: options: openssl
conserver: openssl version: OpenSSL 1.0.2p  14 Aug 2018
conserver: built with `./configure --with-master=localhost --with-port=782 --with-logfile=/var/log/conserver --with-openssl=/opt/pkg --prefix=/usr/local'

I'll do some more debugging as soon as I get a chance, but this has me mystified.

Note that GNU Telnet (also built using pkgsrc) has no trouble connecting to the terminal server:

$ telnet -V
telnet (GNU inetutils) 1.9.4
Copyright (C) 2015 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Written by many authors.
19:00 [523] $ telnet controlling.local 2003
Trying 10.0.1.240...
Connected to controlling.local.
Escape character is '^]'.

xenful# 
telnet> q
Connection closed.

For entries that exec a process with ondemand semantics such as the following:

console sm2-bmc {
        type exec;
        options ondemand;
        exec /usr/local/bin/ipmitool -I lanplus -H sm2-ipmi shell;
}

console-x prints "(null)" because pCE->execSlave is NULL:

$ console -x |grep bmc
 tyan1-bmc                on (null)                           at   Local 
 sm3-bmc                  on (null)                           at   Local 
 sm2-bmc                  on (null)                           at   Local 
 sm1-bmc                  on (null)                           at   Local 
 gw-bmc                   on (null)                           at   Local 
 freenas2-bmc             on (null)                           at   Local 
 freenas1-bmc             on (null)                           at   Local 

When the console is opened the correct pty device is shown. However, once the console is closes it continues to show the pty device which is no longer in use.

The following simple patch fixes this problem, although what to print when the console is inactive is debatable (e.g., I could see the new parens potentially causing grief for someone trying to machine parse the output):

diff --git a/conserver/consent.c b/conserver/consent.c
index 8d9b8e1..2b7eaa7 100644
--- a/conserver/consent.c
+++ b/conserver/consent.c
@@ -798,6 +798,8 @@ ConsDown(CONSENT *pCE, FLAG downHard, FLAG force)
     if (pCE->type == EXEC && pCE->execSlaveFD != 0) {
 	close(pCE->execSlaveFD);
 	pCE->execSlaveFD = 0;
+	free(pCE->execSlave);
+	pCE->execSlave = NULL;
     }
     pCE->fup = 0;
     pCE->nolog = 0;
diff --git a/conserver/group.c b/conserver/group.c
index 0c5435b..b73ac06 100644
--- a/conserver/group.c
+++ b/conserver/group.c
@@ -2175,7 +2175,7 @@ CommandExamine(GRPENT *pGE, CONSCLIENT *pCLServing, CONSENT *pCEServing,
 	char p = '\000';
 	switch (pCE->type) {
 	    case EXEC:
-		d = pCE->execSlave;
+		d = (pCE->execSlaveFD > 0) ? pCE->execSlave : "(inactive)";
 		b = "Local";
 		p = ' ';
 		break;

With the above patch and console freenas1-bmc open we see the following:

console -x |grep bmc
 tyan1-bmc                on (inactive)                       at   Local 
 sm3-bmc                  on (inactive)                       at   Local 
 sm2-bmc                  on (inactive)                       at   Local 
 sm1-bmc                  on (inactive)                       at   Local 
 gw-bmc                   on (inactive)                       at   Local 
 freenas2-bmc             on (inactive)                       at   Local 
 freenas1-bmc             on /dev/pts/27                      at   Local 

When the freenas1-bmc console is closed the entry returns to "(inactive)".

This was tested on:

commit f6f39994376e57bb0a661084524937ac8f1c4a96 (HEAD -> master, origin/master, origin/HEAD)
Merge: 47c232b 13c1365
Author: Bryan Stansell <[email protected]>
Date:   Fri Mar 22 21:53:44 2024 -0700
 
    Merge pull request #83 from saproj/master
    
    Fix failure of out-of-tree build
 

I can generate a merge request if this is acceptable, just not sure what the process is for this project.
Thoughts?

I've used conserver for over a decade and have found it incredibly useful. One tiny thing that has always bothered me is that it's difficult to tell from the help output that the ^Eco and ^Ecd are symmetric operations:

d       down a console
o       (re)open the tty and log file

While it's ingrained in my muscle memory now, I find new users tend to have a similar issue. Perhaps it'd be easier understand if the verbs were obviously symmetric - down/up, (re)open/close or even disconnect/connect, and if the targets were both console or both tty and log file. One option, trying to retain as much of the mnemonics as possible:

d       down connection to console
o       up/(re)open connection to console

I'm new to conserver so I must be doing something wrong.

I have conserver connected to a couple of serial consoles. It seems that the '/r' control character used in process bars is messing up my clients. By that I mean that scrolling no longer works properly and only the last line of the terminal is updated. If that makes any sense :-) I then have to disconnect, reset the terminal and reconnect.

Is this a config issue on the server? Or do I need to supply some argument to the client?

In our lab, we have ~30 consoles defined in our conserver.cf. We recently observed that when some of those consoles' exec() calls error out as conserver tries to bring them up, many of the other consoles will not be brought up either.

I created
a dummy conserver.cf using cat in place of our successful consoles and (exit 1 || sleep 10) in place of the failing ones to replicate this behavior, and consistently, upon restarting conserver, I observe that only 10 of the consoles are brought up by conserver.

On the contrary, when I change these failing exec()s to sleep 10\; exit 1, all of the consoles come up as expected on their own after about a minute.

This behavior leads me to believe this issue is only present when some consoles error out immediately.

I have some templates setting up ipmi consoles with ipmitool.

task 1 {
    description "Power on a machine via ipmi";
    cmd "ipmitool -I lanplus -H % R chassis power on";
    subst %=hs,R=rs;
    confirm no;
}

task 2 {
    description "Power off a machine via ipmi";
    cmd "ipmitool -I lanplus -H % R chassis power off";
    subst %=hs,R=rs;
    confirm yes;
}

task 0 {
    description "Reset a machine via ipmi";
    cmd "ipmitool -I lanplus -H % R chassis power reset";
    subst %=hs,R=rs;
    confirm yes;
}

task q {
    description "View chassis power status";
    cmd "ipmitool -I lanplus -H % R chassis power status";
    subst %=hs,R=rs;
    confirm no;
}

default ipmi-sol {
    exec "ipmitool -I lanplus -H % R sol deactivate || true ; exec ipmitool -I lanplus -H % R sol activate usesolkeepalive";
    break 4;
    type exec;
    # % is substituted by the hostname
    # r is substituded by credentails arguments
    execsubst %=hs,R=rs;
    # add power tasks
    tasklist 1,2,0,q;
    motd "Plain serial port connected through ipmitool
break = ^e c l0";
}

default ipmi-sol-ADMIN {
    include ipmi-sol;
    replstring "-U ADMIN -P ADMIN";
}

default ipmi-sol-ADMIN-no-usesolkeepalive {
    include ipmi-sol-ADMIN;
    exec  "ipmitool -I lanplus -H % R sol deactivate || true ; exec ipmitool -I lanplus -H % R sol activate";
}

console X.intern {
    master Y.intern;
    include ipmi-sol-ADMIN-no-usesolkeepalive;
    host X-ipmi.intern;
}

The config is more complex than that but the issue can be reproduced with only that.

After some time, when running the console and trying to run a task I just get:

[task `q' started]
Password: Error: Unable to establish IPMI v2 / RMCP+ session
[task terminated: exit(1)]

After applying some strace to the relevant conserver process i see:

# strace -s 4096 -e execve -fp 3913
strace: Process 3913 attached
strace: Process 8460 attached
[pid  8460] execve("/bin/sh", ["/bin/sh", "-ce", "ipmitool -I lanplus -H X-ipmi.intern * chassis power off"], 0x7fff379fe210 /* 9 vars */) = 0
strace: Process 8461 attached
[pid  8461] execve("/usr/bin/ipmitool", ["ipmitool", "-I", "lanplus", "-H", "X-ipmi.intern", "bin", "boot", "dev", (truncated away the rest of directories in / ), "chassis", "power", "off"], 0x558911105868 /* 10 vars */) = 0
[pid  8461] +++ exited with 1 +++
[pid  8460] --- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=8461, si_uid=114, si_status=1, si_utime=0, si_stime=0} ---
[pid  8460] +++ exited with 1 +++
--- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=8460, si_uid=114, si_status=1, si_utime=0, si_stime=0} ---
^Cstrace: Process 3913 detached

Somewhere in memory my replstring got replaced by a "*"

I have a setup where i'm running conserver on a raspberry pi which is connected to several devices over consoles. I have no issue running console client application on the raspberry pi and attaching to the different devices through conserver.

But when connecting to conserver from console over port forwarding I have an issue with listing consoles with "-u" argument.

Tested with the following versions of conserver:
8.2.6
8.2.1

The raspberry pi is connected to a server and is not accessible from the network it self. So I have enabled port forwarding on the server the following ports:

3109 (primaryport)
62000 (secondaryport)

When I connect with console from my laptop attaching to a console everything works fine:

command: console -D -M 10.2.83.240

Debug log from the session:

console dut-a (works)

➜ console -D -M 10.2.83.240 dut-b
console: DEBUG: [cutil.c:299] AllocString(): 0x55e8e8a536a0 created string #3
console: DEBUG: [cutil.c:2610] ReadCfg(): got keyword 'config' [/etc/conserver/console.cf:1]
console: DEBUG: [readconf.c:114] ConfigBegin(*) [/etc/conserver/console.cf:3]
console: DEBUG: [cutil.c:299] AllocString(): 0x55e8e8a547a0 created string #4
console: DEBUG: [cutil.c:2693] got keyword 'sslenabled' [/etc/conserver/console.cf:3]
console: DEBUG: [readconf.c:495] ConfigItemSslenabled(off) [/etc/conserver/console.cf:4]
console: DEBUG: [cutil.c:2693] got keyword 'master' [/etc/conserver/console.cf:4]
console: DEBUG: [readconf.c:337] ConfigItemMaster(localhost) [/etc/conserver/console.cf:5]
console: DEBUG: [cutil.c:2693] got keyword 'port' [/etc/conserver/console.cf:5]
console: DEBUG: [readconf.c:377] ConfigItemPort(3109) [/etc/conserver/console.cf:6]
console: DEBUG: [readconf.c:132] ConfigEnd() [/etc/conserver/console.cf:6]
console: DEBUG: [readconf.c:165] ConfigDestroy() [/etc/conserver/console.cf:7]
console: DEBUG: [readconf.c:291] TerminalDestroy() [/etc/conserver/console.cf:7]
console: DEBUG: [readconf.c:696] pConfig->username = (null)
console: DEBUG: [readconf.c:698] pConfig->master = localhost
console: DEBUG: [readconf.c:699] pConfig->port = 3109
console: DEBUG: [readconf.c:700] pConfig->escape = (null)
console: DEBUG: [readconf.c:701] pConfig->striphigh = unset
console: DEBUG: [readconf.c:703] pConfig->replay = 0
console: DEBUG: [readconf.c:704] pConfig->playback = 0
console: DEBUG: [readconf.c:706] pConfig->sslcredentials = (null)
console: DEBUG: [readconf.c:708] pConfig->sslcacertificatefile = (null)
console: DEBUG: [readconf.c:710] pConfig->sslcacertificatepath = (null)
console: DEBUG: [readconf.c:712] pConfig->sslrequired = unset
console: DEBUG: [readconf.c:714] pConfig->sslenabled = false
console: DEBUG: [readconf.c:717] pTerm->attach = (null)
console: DEBUG: [readconf.c:718] pTerm->attachsubst = (null)
console: DEBUG: [readconf.c:720] pTerm->detach = (null)
console: DEBUG: [readconf.c:721] pTerm->detachsubst = (null)
console: DEBUG: [cutil.c:299] AllocString(): 0x55e8e8a536d0 created string #5
console: DEBUG: [cutil.c:299] AllocString(): 0x55e8e8a537d0 created string #6
console: DEBUG: [cutil.c:299] AllocString(): 0x55e8e8a53850 created string #7
console: DEBUG: [console.c:2479] cmds[1] = call
console: DEBUG: [console.c:2479] cmds[0] = attach
console: DEBUG: [console.c:558] GetPort: hostname=10.2.83.240, ip=10.2.83.240, port=3109
console: DEBUG: [cutil.c:299] AllocString(): 0x55e8e8b0d9f0 created string #8
console: DEBUG: [cutil.c:299] AllocString(): 0x55e8e8b0da20 created string #9
console: DEBUG: [cutil.c:299] AllocString(): 0x55e8e8b0da50 created string #10
console: DEBUG: [cutil.c:299] AllocString(): 0x55e8e8b0db20 created string #11
console: DEBUG: [console.c:787] ReadReply: `ok^M^J'
console: DEBUG: [cutil.c:299] AllocString(): 0x55e8e8b07370 created string #12
console: DEBUG: [cutil.c:299] AllocString(): 0x55e8e8b131b0 created string #13
console: DEBUG: [cutil.c:299] AllocString(): 0x55e8e8b132d0 created string #14
console: DEBUG: [console.c:787] ReadReply: `ok^M^J'
console: DEBUG: [console.c:787] ReadReply: `62000^M^J'
console: DEBUG: [console.c:787] ReadReply: `goodbye^M^J'
console: DEBUG: [cutil.c:276] DestroyString(): 0x55e8e8b0d9f0 string destroyed (count==13)
console: DEBUG: [console.c:558] GetPort: hostname=10.2.83.240, ip=10.2.83.240, port=62000
console: DEBUG: [cutil.c:299] AllocString(): 0x55e8e8b0cdd0 created string #14
console: DEBUG: [console.c:787] ReadReply: `ok^M^J'
console: DEBUG: [console.c:787] ReadReply: `ok^M^J'
console: DEBUG: [console.c:787] ReadReply: `[attached]^M^J'
console: DEBUG: [console.c:787] ReadReply: `[up]^M^J'
console: DEBUG: [console.c:787] ReadReply: `[8002006]^M^J'
[Enter `^Ec?' for help]
console: DEBUG: [console.c:787] ReadReply: `[-- MOTD --]^M^J'
console: DEBUG: [console.c:787] ReadReply: `[connected]^M^J'

D2:/#>

But when I want to list all available consoles with the following command:

console -D -M 10.2.83.240 -u

It fails!

Debug session log:

console -u (not working)

➜ console -D -M 10.2.83.240 -u
console: DEBUG: [cutil.c:299] AllocString(): 0x55876a0f16a0 created string #3
console: DEBUG: [cutil.c:2610] ReadCfg(): got keyword 'config' [/etc/conserver/console.cf:1]
console: DEBUG: [readconf.c:114] ConfigBegin(*) [/etc/conserver/console.cf:3]
console: DEBUG: [cutil.c:299] AllocString(): 0x55876a0f27a0 created string #4
console: DEBUG: [cutil.c:2693] got keyword 'sslenabled' [/etc/conserver/console.cf:3]
console: DEBUG: [readconf.c:495] ConfigItemSslenabled(off) [/etc/conserver/console.cf:4]
console: DEBUG: [cutil.c:2693] got keyword 'master' [/etc/conserver/console.cf:4]
console: DEBUG: [readconf.c:337] ConfigItemMaster(localhost) [/etc/conserver/console.cf:5]
console: DEBUG: [cutil.c:2693] got keyword 'port' [/etc/conserver/console.cf:5]
console: DEBUG: [readconf.c:377] ConfigItemPort(3109) [/etc/conserver/console.cf:6]
console: DEBUG: [readconf.c:132] ConfigEnd() [/etc/conserver/console.cf:6]
console: DEBUG: [readconf.c:165] ConfigDestroy() [/etc/conserver/console.cf:7]
console: DEBUG: [readconf.c:291] TerminalDestroy() [/etc/conserver/console.cf:7]
console: DEBUG: [readconf.c:696] pConfig->username = (null)
console: DEBUG: [readconf.c:698] pConfig->master = localhost
console: DEBUG: [readconf.c:699] pConfig->port = 3109
console: DEBUG: [readconf.c:700] pConfig->escape = (null)
console: DEBUG: [readconf.c:701] pConfig->striphigh = unset
console: DEBUG: [readconf.c:703] pConfig->replay = 0
console: DEBUG: [readconf.c:704] pConfig->playback = 0
console: DEBUG: [readconf.c:706] pConfig->sslcredentials = (null)
console: DEBUG: [readconf.c:708] pConfig->sslcacertificatefile = (null)
console: DEBUG: [readconf.c:710] pConfig->sslcacertificatepath = (null)
console: DEBUG: [readconf.c:712] pConfig->sslrequired = unset
console: DEBUG: [readconf.c:714] pConfig->sslenabled = false
console: DEBUG: [readconf.c:717] pTerm->attach = (null)
console: DEBUG: [readconf.c:718] pTerm->attachsubst = (null)
console: DEBUG: [readconf.c:720] pTerm->detach = (null)
console: DEBUG: [readconf.c:721] pTerm->detachsubst = (null)
console: DEBUG: [cutil.c:299] AllocString(): 0x55876a0f16d0 created string #5
console: DEBUG: [cutil.c:299] AllocString(): 0x55876a0f17b0 created string #6
console: DEBUG: [cutil.c:299] AllocString(): 0x55876a0f1830 created string #7
console: DEBUG: [console.c:2479] cmds[2] = master
console: DEBUG: [console.c:2479] cmds[1] = groups
console: DEBUG: [console.c:2479] cmds[0] = hosts
console: DEBUG: [console.c:558] GetPort: hostname=10.2.83.240, ip=10.2.83.240, port=3109
console: DEBUG: [cutil.c:299] AllocString(): 0x55876a1ab9d0 created string #8
console: DEBUG: [cutil.c:299] AllocString(): 0x55876a1aba00 created string #9
console: DEBUG: [cutil.c:299] AllocString(): 0x55876a1aba30 created string #10
console: DEBUG: [cutil.c:299] AllocString(): 0x55876a1abb00 created string #11
console: DEBUG: [console.c:787] ReadReply: `ok^M^J'
console: DEBUG: [cutil.c:299] AllocString(): 0x55876a1a5350 created string #12
console: DEBUG: [cutil.c:299] AllocString(): 0x55876a1b1190 created string #13
console: DEBUG: [cutil.c:299] AllocString(): 0x55876a1b12b0 created string #14
console: DEBUG: [console.c:787] ReadReply: `ok^M^J'
console: DEBUG: [console.c:787] ReadReply: `@198.18.121.10^M^J'
console: DEBUG: [console.c:787] ReadReply: `goodbye^M^J'
console: DEBUG: [cutil.c:276] DestroyString(): 0x55876a1ab9d0 string destroyed (count==13)
console: DEBUG: [console.c:558] GetPort: hostname=198.18.121.10, ip=198.18.121.10, port=3109
console: Unable to connect to 198.18.121.10:3109
console: DEBUG: [cutil.c:276] DestroyString(): 0x55876a0f1830 string destroyed (count==12)
console: DEBUG: [cutil.c:276] DestroyString(): 0x55876a1b12b0 string destroyed (count==11)
console: DEBUG: [cutil.c:276] DestroyString(): 0x55876a1b1190 string destroyed (count==10)
console: DEBUG: [cutil.c:276] DestroyString(): 0x55876a1a5350 string destroyed (count==9)
console: DEBUG: [cutil.c:276] DestroyString(): 0x55876a1abb00 string destroyed (count==8)
console: DEBUG: [cutil.c:276] DestroyString(): 0x55876a1aba30 string destroyed (count==7)
console: DEBUG: [cutil.c:276] DestroyString(): 0x55876a1aba00 string destroyed (count==6)
console: DEBUG: [cutil.c:276] DestroyString(): 0x55876a0f17b0 string destroyed (count==5)
console: DEBUG: [cutil.c:276] DestroyString(): 0x55876a0f16d0 string destroyed (count==4)
console: DEBUG: [cutil.c:276] DestroyString(): 0x55876a0f27a0 string destroyed (count==3)
console: DEBUG: [cutil.c:276] DestroyString(): 0x55876a0f16a0 string destroyed (count==2)
console: DEBUG: [cutil.c:276] DestroyString(): 0x55876a0f12d0 string destroyed (count==1)
console: DEBUG: [cutil.c:276] DestroyString(): 0x55876a0f12a0 string destroyed (count==0)

When you compare the two different logs you can see from the log for the "-u" command it says incorrectly ip 198.18.121.10 and it can not reach that address of the raspberry pi since it is sitting behind the server.

But when attaching to the console (working example) you can see from the log that you don't get that incorrect IP so I wonder why.

Anyone have any ideas, could it be an issue with conserver/console?

Best regards
Thomas

The quick install instructions metion I should start with ./configure
But that command is not yet present.

I have been away from installing from sources too long it seems so I need some guidance. What should be the next step after the git clone command?

1. If client 1 attaches in spy mode to a console, and subsequently client 2 attaches rw to the same console, then when client 2 disconnects client 1 remains in spy mode.

2. However, if client 1 attaches rw to a console, and subsequently client 2 attaches deliberately in spy mode to the same console (i.e., console -s victim), then when client 1 disconnects client 2 is promoted to write mode. These behaviors are inconsistent, surprising, and is potentially hazardous.

The problem is that in the second case (2) the "wantwr" flag is enabled for the spy mode client via a direct call to ClientWantsWrite(), which appears to be unnecessary, as the console client will analyze the messages returned from the server and issue the correct escape sequence to put the client into the desired mode.

For example, in case (2), if client 2 tries to attach rw then it will automatically be put into spy mode and the console client will issue/followup with an attach command. The attach will fail but will enable the "wantwr" bit such that when client 1 disconnects then client 2 will be correctly promoted to console writer.

I have a patch that fixes issue (2) for which I'll create an PR: #108

Most Linux daemons have adopted an include-file approach like /etc/conserver.d/*.cf which can load files installed by various packages that are independently installed. In a containerised use case, the equivalent could be container descriptions that are independently configured with a TTY.

Apologies for the small burst of Feature Requests. They are of course related, but may be easier to you to consider separately. I looked into offering pull requests but got stuck in autotools, for which I found no explanation or bootstrapping script.