Minicom, How to disable login prompt ?

T

Tridac

Hi,

Running FreeBSD 12, DL360 G8 hardware and trying to get minicom working to use the single com0 serial port, for a general purpose terminal for systems testing etc. Have used minicom without issue for years on other systems, for example, Suse 11.4 on an old laptop, but on FreeBSD, i'm getting a login prompt on the serial line and minicom is not accessing the line for i/p, nor o/p. Have set /etc/ttys all lines to off and console init to none, so what service is responsible for the login prompt and how can it be disabled ?.

Thanks,
Chris
 
Tridac said:
Running FreeBSD 12, DL360 G8 hardware and trying to get minicom working to use the single com0 serial port
Click to expand...

On FreeBSD, serial ports have names like /dev/cuauN, on Linux /dev/ttySN. Do you use the correct device name?
 
Tieks said:
On FreeBSD, serial ports have names like /dev/cuauN, on Linux /dev/ttySN. Do you use the correct device name?
Click to expand...
Thanks. Yes. the device minicom is trying to use is /dev/cuau0 and also associated, in /dev, are the cuau0.init and cuau0.lock files. Not sure why i'm getting a login prompt on the serial port, which may be setting lock ownership of the interface and preventing minicom from accessing it. Hence the question on how to disable that in some way.

Although the serial port outputs a login and password prompt, all input return auth failure and the login prompt respawns every few minutes. This is using a second minicom and null modem cable on a laptop, back to back...
 
Tieks said:
... and the other side is showing a login prompt, correct? Then cuau0 (and ttyu0) is probably configured for login. Please take a look at man ttys for /etc/ttys.
Click to expand...
I tried various combinations with /etc/ttys file, from commenting all entries out to what is the current, below, but same result. Do kill -HUP 1 and even a reboot, but no difference, so what is spawning the login prompt. Perhaps something in the boot process ?...

# console "/usr/libexec/getty std.9600" vt100 off secure
console none unknown off
cuau0 none unknown off
#
ttyv0 none unknown off
#

# Virtual terminals

# ttyv1 "/usr/libexec/getty Pc" xterm off
# ttyv2 "/usr/libexec/getty Pc" xterm off
# ttyv3 "/usr/libexec/getty Pc" xterm off
# ttyv4 "/usr/libexec/getty Pc" xterm off
# ttyv5 "/usr/libexec/getty Pc" xterm off
# ttyv6 "/usr/libexec/getty Pc" xterm off
# ttyv7 "/usr/libexec/getty Pc" xterm off

# ttyv8 "/usr/local/bin/xdm -nodaemon" xterm off

# Serial terminals
# The 'dialup' keyword identifies dialin lines to login, fingerd etc.

ttyu0 none unknown off
# ttyu1 "/usr/libexec/getty 3wire" vt100 off
# ttyu2 "/usr/libexec/getty 3wire" vt100 off
# ttyu3 "/usr/libexec/getty 3wire" vt100 off

I'm pretty sure this all worked in the 11 release, but will verify that on
another old machine. Do a lot of serial rs232 comms work and would
be good find a fix for this...

Update: Just checked on an 11.0 system and it does work, both systems are a generic install
with no kernel rebuild or mods....
 
Tridac said:
Just checked on an 11.0 system and it does work, both systems are a generic install
Click to expand...
In the past I used it too. Strange that it works with v11, not with v12. Looking in my backups I don't see any relevant change in the original /etc/ttys, /etc/gettytab and others between v11 and later. Some added security feature in v12??? Unfortunately, I don't have the hardware to try at the moment. Perhaps later, I like to have the option available too.
 
Mainly embedded systems work here and restoring old Sun and other for fun, where serial rs232 terminal capability is essential for initial test and debug. I don't have the systems internal knowledge to try to debug this at source level, when it may also just be a startup / boot or other configuration issue. /boot/defaults/loader.conf are different on both 11 and 12, but not significantly and nothing that looks related. Could be a bug I guess, but perhaps not that many have need for a serial VT100 style terminal these days, so may not have been noticed thus far. Is it worth reporting this as a potential bug ?...
 
I know cu is a little crusty but I think you best off eliminating minicom as the problem.
cu -s 115200 -l /dev/cuau0
Exiting cu is not very graceful.
Shift+~ then .
 
Phishfry said:
I know cu is a little crusty but I think you best off eliminating minicom as the problem.
cu -s 115200 -l /dev/cuau0
Exiting cu is not very graceful.
Shift+~ then .
Click to expand...

>>> cu -s 9600 -l /dev/cuau0
>>> Connected

Tried above, but that doesn't work either, so does look like it may be a system bug.

Good thing about minicom is that it's been around long enough that it just works on all the unix related systems here and is easy to build from source. Can seem a little clunky to start with, but has no serious issues normally. Will see if there's a different hardware platform here that i can do a quickinstall and check that, to rule out any hardware issues...
 
Here's a pic of what is seen at minicom running on the laptop, other end of the serial cable, null modem connection. Just keeps repeating indefinately, with no acceptance of login or password input, just rubbish echo'd characters...

P1050637-small.jpg
 
Did a quick install of 12 on a mini pc, has serial port and that works fine, rebooted single user and that works as well. Checked out and changed some of the bios setings on the DL360, but still doesn't work, or in single user mode. Looks like there is an issue with the serial port on the machine, as minicom works fine with 12 on a other machines, so looks like we are at dead end for now. Could try a complete reinstall, but the machine is otherwise in final setup, leave it and do some work with it mode. Just a heads up to others who may need that functionality on the DL360 G8...
 
Tridac said:
Just keeps repeating indefinately, with no acceptance of login or password input
Click to expand...
Trying on a FBSD13, I don't have this problem. I can just log in. I am using ttyu4 with these settings in /etc/ttys: ttyu4 "/usr/libexec/getty 3wire" vt100 on.
It looks like the getty on your line dumps and restarts for some reason, you could use # ps -ax | grep getty to see more. It maybe hardware related indeed.
 
You must log in or register to reply here.
Back
Top