Thanks for all the help. Chris
On Mon, Apr 6, 2020 at 11:59 PM Chris Rhodin <cprho...@gmail.com> wrote: > 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 >>> >>
