I figured it out. It was user error. When I diff'd the output of "stty" from my laptop and server I saw the server had "-crtscts" and laptop had "crtscts". It turns out minicom enables hardware flow control by default and I had changed that default on my laptop somewhere in the past (at least 3 releases of Debain ago). I thought I had checked this on the server but either I didn't or I just missed it. Changing this in minicom made it work.ChrisOn Mon, Apr 6, 2020 at 10:53 PM Chris Rhodin <cprhodin@gmail.com> wrote:---------- Forwarded message ---------
From: Chris Rhodin <cprhodin@gmail.com>
Date: Mon, Apr 6, 2020 at 7:28 PM
Subject: Re: Serial Port Issues
To: <tomas@tuxteam.de>I have two devices I'm trying to connect to, a UPS and a network switch. By default the UPS runs at 2400 baud and the switch runs at 9600 baud. Before connecting them to the server I verified the devices were working on a laptop running Debian. When I attached them to the server and powered them up (with minicom already running) I saw the expected startup messages being output by both devices (this is why I say I can receive serial data). I then started typing commands and but got no response.I started debugging. I tried other cables, I tried USB to serial cables, I reattached the devices to the laptop to verify they hadn't spontaneously and simultaneously stopped working. Next I simplified my test setup. I made a loop back cable that connects Tx to Rx. I tested this cable on the laptop and verified it echoed everything I typed. On the server no echo.Based on responses here I've verified the permissions and tried running as root. I've also checked the flow control as reported by minicom.Q: Is "stty" the right command line tool to check all of a serial ports settings?And finally, last night I burned a Debian live DVD and booted the server with it. After installing the proprietary network drivers and minicom I tried the serial ports again with the same results.Tonight I'll look at the serial port ioctls and see if I can spot a difference there. I also try enabling flow control and fiddling with the signals to see if that unstops it.ChrisR....0On Mon, Apr 6, 2020 at 7:08 AM <tomas@tuxteam.de> wrote:On Mon, Apr 06, 2020 at 09:51:15AM -0400, rhkramer@gmail.com wrote:
> On Monday, April 06, 2020 03:50:59 AM tomas@tuxteam.de wrote:
> > Besides, a wrong baud rate would much less explain that writing is
> > possible, but reading isn't. Not for classical "serials" (i.e. RS-232).
>
> From the OP: " On this system a serial port can only receive data and not
> transmit."
>
> Wouldn't that mean that (from the perspective of a program running on the OP's
> computer) that the serial port can read but not write?
My recollection is the other way around: write but not read.
But hey, I'm old and that.
That (and the fact that another serial over USB showed the same
symptoms) prompted me to (reluctantly) hint at permissions [1],
since, to my knowledge, a honest serial port cannot be configured
to different send and receive speeds. But this seems to be ruled
out.
Another possibility is, of course, the cable :-)
Do we know in which way the port fails to read/write or whatever
it fails at? Error messages?
Cheers
[1] this could be explained by a broken udev script setting
the wrong permissions -- that would, e.g. cover the USB
adapter case. It was such a nice model :-)
-- t