Re: Serial Port Issues

[Chris Rhodin <cprhodin@gmail.com>]

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.

Chris

On 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

....0

On 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