Can't seem to get serial to work

[Polarian]

Hey,

I have spoken about this in #freebsd a few times, but it seems I am
completely incapable of getting it working no matter the responses I
get.

Some background. I wanted serial access through a terminal server (over
SSH) to my servers, because I kept having the tendency to mess up the
firewalling while I was at a conference and being locked out till I
could get back on site to fix it.

Now I do not run server hardware, so I do not have fancy features, my
infra is built on mainly old tech I saved from the landfills.

I originally used two cheap TTL cables soldered together RX-TX TX-RX
and this worked flawlessly, however I also decided to FDE my server and
this can not be decrypted unless you have a "COM" port.

After inspecting the motherboard, I found a JCOM header, this allows me
to connect serial. So I connected a startech plate adapter to it [1]
and then plugged in a nullmodem to it [2] and then connected a through
cable to that.

Server side I see the dmesg log for COM0 [3], and the interfaces. [4]

However whenever I plug the DB9 to USB through cable into any device,
there is no interface which is created, and dmesg shows nothing. I am
honestly clueless of what more I can try.

I am assuming its connected wrongly because the software side of it
looks fine.

Does anyone have ideas?

Thank you,
--
Polarian
Jabber/XMPP: pola...@icebound.dev

[1] https://www.startech.com/en-us/cables/plate9m16
[2] https://www.startech.com/en-us/cables/nm9mf
[3] https://bpa.st/AIIQ
[4] https://bpa.st/KHHA

[void]

Hi,

Have you tried tailing console.log on the *client* when you plug
the cable into it?

Try the above *without* the nullmodem adapter?

I use a serial to usb cable in this situation.
*No* null-modem adapter. It is a usb to RS232 cable.

On the *client* dmesg shows:

ugen0.5: <Prolific Technology Inc. USB-Serial Controller> at usbus0

On Fri, 3 Jul 2026, at 14:28, Polarian wrote:

[Frank Leonhardt]

On 03/07/2026 14:28, Polarian wrote:
> After inspecting the motherboard, I found a JCOM header, this allows me
> to connect serial. So I connected a startech plate adapter to it [1]
> and then plugged in a nullmodem to it [2] and then connected a through
> cable to that.
>
> Server side I see the dmesg log for COM0 [3], and the interfaces. [4]
>
> However whenever I plug the DB9 to USB through cable into any device,
> there is no interface which is created, and dmesg shows nothing. I am
> honestly clueless of what more I can try.

As this has been around for a while...

I don't know exactly what you're doing here, but connecting a terminal
to a serial interface doesn't create a device. If the UART (real or
emulated) is detected, that's as good as you'll get.

You might be hitting hardware flow control problem. However, I can't
figure for certain what the "DB9 to USB through cable" is about. I'm
guessing that on host A you have some kind of serial port breakout which
you believe is COM0. You have connected this to a DB9 IBM-PC style
connector using a Startech passive adapter. Into this you have a null
modem cable connected to a Serial USB adapter on another host.

Does the other hose enumerate the USB->Serial adapter?

Try looping back pins 2+3 on both hosts and see if you get your data
echoed back on each.

Look in /dev for devices /dev/cua*

Note that I think USB serial devices use a capital U; native UARTs uses
a lower case u.

Let's say you find cuau0

Force hardware flow control OFF:

stty -f /dev/cuau0 -crtscts

Connect to it using cu:

cu -l /dev/cuau0 -s 9600

Type something and see if it echos back. (Use ~. on a blank line to exit)

If you don't have a cuau device in /dev/ that's your first problem. If
you don't have echo back then your UART is the problem. If you have echo
back on both then your cross-over cable is the problem. You may need to
loop back the hardware handshaking lines - disabling them in software is
obviously not the answer if they're enabled at power-on.

If you're not getting your USB->Serial converter appearing as
/dev/cuaU[0-9] run usbconfig and see what it finds.

Regards, Frank.

[laszlo vagner]

i always thought you needed to be in the dialer group to open com ports.

[Frank Leonhardt]

On 13/07/2026 11:29, laszlo vagner wrote:
> i always thought you needed to be in the dialer group to open com ports.
>

You need permissions to r/w the device, with by default is the user uucp
or anyone in the dialer group. Or the root user, which is the most
likely if you're debugging hardware. It's also possible that getty may
be waiting on a connect on the serial port. By default it won't be but
we don't know what Polarian has done, so good question.

Most likely the line /etc/ttys will read something like:

ttyu0   "/usr/libexec/getty 3wire"      vt100   onifconsole secure

The onifconsole option enables it IF it's designated as a console (no
kidding!), which it might be given what Polarian is trying to do. If
there's a line in loader.conf saying "console=comconsole" then getty
might lock on to it. Worth checking, but he wasn't complaining about the
lock error.

The reason I say "might" is that getty references the device as
/dev/ttyu? which blocks in open() until it get's DCD. If you hit the
same device as /dev/cuau? it's the call-out version, which doesn't wait
for DCD and because getty 's attempt to open(/dev/ttyu?) will be blocked
then cu will still be able to open it. Unless DCD is pulled active,
depending on the wiring of the cables here. Which is why I asked for a
loopback test before anything else :-)

Regards, Frank.