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 <cprho...@gmail.com> wrote: > > > ---------- Forwarded message --------- > From: Chris Rhodin <cprho...@gmail.com> > Date: Mon, Apr 6, 2020 at 7:28 PM > Subject: Re: Serial Port Issues > To: <to...@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 <to...@tuxteam.de> wrote: > >> On Mon, Apr 06, 2020 at 09:51:15AM -0400, rhkra...@gmail.com wrote: >> > On Monday, April 06, 2020 03:50:59 AM to...@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 >> >
