I am trying to get the serial console to function. I have enabled it as secondary console, set the speed as 115200, and have set " Use USB-based serial ports " as enabled.
I then have have joined two USB to serial converter (tripp-lite u209-000-r) with a null modem (https://www.amazon.com/dp/B075XGRLXW/ref=cm_sw_em_r_mt_dp_AH3V8N07GZY398GQJYQA?_encoding=UTF8&psc=1) in the middle. This should work correct?
I my Linux system I then type:
# minicom -b 115200 -D /dev/ttyUSB0
I press the enter key a few times but only have a blank screen. :(
from my Linux host dmesg shows.
[596342.276400] usb 1-2: pl2303 converter now attached to ttyUSB0
dmesg form the OPNsense firewall
ugen0.4: <Prolific Technology Inc. USB-Serial Controller D> at usbus0
uplcom0 on uhub0
uplcom0: <Prolific Technology Inc. USB-Serial Controller D, class 0/0, rev 1.10/3.00, addr 7> on usbus0
OPNsense /etc/ttys shows:
# Serial terminals
# The 'dialup' keyword identifies dialin lines to login, fingerd etc.
ttyU0 "/usr/libexec/getty 3wire.115200" vt100 onifconsole secure
ttyU1 "/usr/libexec/getty 3wire.115200" vt100 onifconsole secure
ttyU2 "/usr/libexec/getty 3wire.115200" vt100 onifconsole secure
ttyU3 "/usr/libexec/getty 3wire.115200" vt100 onifconsole secure
# Dumb console
dcons "/usr/libexec/getty std.9600" vt100 off secure
This is the motherboard in use on the OPNsense firewall and I am running v20.7.2
https://www.asrock.com/MB/Intel/H470M-ITXac/index.asp
Thank you.
Can you print the output of:
# ls /dev/ttyU*
Maybe init needs a bit of a jolt if you plug the USB into a running system:
# kill -HUP 1
Cheers,
Franco
Thank you franco.
# ls /dev/ttyU*
/dev/ttyU0 /dev/ttyU0.init /dev/ttyU0.lock
I have unplugged the USB serial converter and plugged it back on both systems and ran
# kill -HUP 1
on both systems too. ;)
There was no change to the issue.
Here are the minicom settings on the Linux system
+-----------------------------------------------------------------------+
| A - Serial Device : /dev/ttyUSB0 |
| B - Lockfile Location : /var/run |
| C - Callin Program : |
| D - Callout Program : |
| E - Bps/Par/Bits : 115200 8N1 |
| F - Hardware Flow Control : No |
| G - Software Flow Control : No |
| H - RS485 Enable : No |
| I - RS485 Rts On Send : No |
| J - RS485 Rts After Send : No |
| K - RS485 Rx During Tx : No |
| L - RS485 Terminate Bus : No |
| M - RS485 Delay Rts Before: 0 |
| N - RS485 Delay Rts After : 0 |
| |
| Change which setting?
Update
To test the cables I shorted out pins 2 and 3 per:
https://forum.opnsense.org/index.php?topic=15417.msg85417#msg85417
and reference:
https://knowledge.ni.com/KnowledgeArticleDetails?id=kA03q000000YFtECAW&l=en-US
And I was able to see the text I typed, so the cables are not the issue.
Update part 2
I tested on the loopback on the firewall too
# cu -l /dev/ttyU0
Connected
la;as;dfas
I got this working somewhat, I have to change "onifconsole" to "on".
change from:
ttyU0 "/usr/libexec/getty 3wire.115200" vt100 onifconsole secure
change to:
ttyU0 "/usr/libexec/getty 3wire.115200" vt100 on secure
So now I have two questions.
How do I make this persistent so that it survive a reboot?
What does "onifconsole" do vs. "on"?
I actually found another setting to add to the confusion, "onifexists".
Any thought on how to make this persistent across reboots?
How can I make this persistent?
If I change the line that has "ttyU0" in /etc/ttys from "onifconsole" to "on", it works great. But is will not stay if the system is rebooted.
change from:
ttyU0 "/usr/libexec/getty 3wire.115200" vt100 onifconsole secure
to this:
ttyU0 "/usr/libexec/getty 3wire.115200" vt100 on secure
and then restart init:
# kill -HUP 1
You can now see that the console is running:
# ps | grep getty
98163 0 R+ 0:00.00 grep getty
95361 U0 Is+ 0:00.00 /usr/libexec/getty 3wire.115200 ttyU0
Trading a fix for a ticket https://github.com/opnsense/core/issues/new?assignees=&labels=&template=feature_request.md&title=
I don't mind pinning USB console option to "on" instead of "onifconsole".
Cheers,
Franco
Thank you Franco, a ticket has been submitted.
https://github.com/opnsense/core/issues/4849