Serial Port Issues

classic Classic list List threaded Threaded
23 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Serial Port Issues

Chris Rhodin-2
Hi All,

I have a rack mount server running a fresh install of Debian buster.  On this system a serial port can only receive data and not transmit.  This is true for both the built in serial port and USB to serial adapters.  I'm testing this with a loop back cable and the command "minicom --baudrate=9600 --device=/dev/ttyXX".  I also have a laptop and desktop running Debian and on these systems the serial adapters and cables work fine with that command.

Has anyone seen this happen before?

I can see how the built in port might have an issue but why do the USB ports do the same thing?

 
Chris


Reply | Threaded
Open this post in threaded view
|

Re: Serial Port Issues

tomas@tuxteam.de
On Sun, Apr 05, 2020 at 06:06:43AM -0700, Chris Rhodin wrote:

> Hi All,
>
> I have a rack mount server running a fresh install of Debian buster.  On
> this system a serial port can only receive data and not transmit.  This is
> true for both the built in serial port and USB to serial adapters.  I'm
> testing this with a loop back cable and the command "minicom
> --baudrate=9600 --device=/dev/ttyXX".  I also have a laptop and desktop
> running Debian and on these systems the serial adapters and cables work
> fine with that command.
>
> Has anyone seen this happen before?
>
> I can see how the built in port might have an issue but why do the USB
> ports do the same thing?
Permissions? (they would have to be a bit funny, write but not read,
but hey, it'd be possible).

Cheers
-- t

signature.asc (205 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Serial Port Issues

songbird
<[hidden email]> wrote:
...
> Permissions? (they would have to be a bit funny, write but not read,
> but hey, it'd be possible).

  that was my first thought too...


  songbird

Reply | Threaded
Open this post in threaded view
|

Re: Serial Port Issues

deloptes-2
In reply to this post by tomas@tuxteam.de
[hidden email] wrote:

> Permissions? (they would have to be a bit funny, write but not read,
> but hey, it'd be possible).

definitely, because it is usually read only for the group by default.

$ ls -al /dev/ttyS1
crw-rw---- 1 root dialout 4, 65 Apr  5 11:40 /dev/ttyS1



Reply | Threaded
Open this post in threaded view
|

Re: Serial Port Issues

john doe-6
In reply to this post by Chris Rhodin-2
On 4/5/2020 3:06 PM, Chris Rhodin wrote:
> Hi All,
>
> I have a rack mount server running a fresh install of Debian buster.  On
> this system a serial port can only receive data and not transmit.  This is
> true for both the built in serial port and USB to serial adapters.  I'm
> testing this with a loop back cable and the command "minicom
> --baudrate=9600 --device=/dev/ttyXX".  I also have a laptop and desktop

Why are you not using '115200n8'?

--
John Doe

Reply | Threaded
Open this post in threaded view
|

Re: Serial Port Issues

Chris Rhodin-2
In reply to this post by Chris Rhodin-2

> Permissions? (they would have to be a bit funny, write but not read,
> but hey, it'd be possible).

I checked the permissions and group memberships but they're already correct.  I also tried executing at root privilege, no luck.

Chris
Reply | Threaded
Open this post in threaded view
|

Re: Serial Port Issues

deloptes-2
Chris Rhodin wrote:

> I checked the permissions and group memberships but they're already
> correct.  I also tried executing at root privilege, no luck.

'R you sure about the baud rate (9600)? It might be something higher ...
also did you setup agetty accordingly?





Reply | Threaded
Open this post in threaded view
|

Re: Serial Port Issues

Joe Rowan
On Mon, 06 Apr 2020 08:53:05 +0200
deloptes <[hidden email]> wrote:

> Chris Rhodin wrote:
>
> > I checked the permissions and group memberships but they're already
> > correct.  I also tried executing at root privilege, no luck.  
>
> 'R you sure about the baud rate (9600)? It might be something higher
> ... also did you setup agetty accordingly?
>
>

I doubt it's that. 9600 is a sort of default these days, and a serial
port which could not use it would be of limited use. The XBee radio
modules, for example, come from the factory running at 9600, though of
course they will go much higher. But the configuration utility must run
at 9600 to begin with.

--
Joe

Reply | Threaded
Open this post in threaded view
|

Re: Serial Port Issues

tomas@tuxteam.de
On Mon, Apr 06, 2020 at 08:38:58AM +0100, Joe wrote:

> On Mon, 06 Apr 2020 08:53:05 +0200
> deloptes <[hidden email]> wrote:
>
> > Chris Rhodin wrote:
> >
> > > I checked the permissions and group memberships but they're already
> > > correct.  I also tried executing at root privilege, no luck.  
> >
> > 'R you sure about the baud rate (9600)? It might be something higher
> > ... also did you setup agetty accordingly?
What has agetty to do with not being able to access a port?

> I doubt it's that. 9600 is a sort of default these days, and a serial
> port which could not use it would be of limited use. The XBee radio
> modules, for example, come from the factory running at 9600, though of
> course they will go much higher. But the configuration utility must run
> at 9600 to begin with.

Besides, the wrong baud rate wouldn't preclude a program from *reading*
from a serial interface. It would just get garbage, that's all.

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).

Cheers
-- t

signature.asc (205 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Serial Port Issues

deloptes-2
[hidden email] wrote:

> What has agetty to do with not being able to access a port?
>
>> I doubt it's that. 9600 is a sort of default these days, and a serial
>> port which could not use it would be of limited use. The XBee radio
>> modules, for example, come from the factory running at 9600, though of
>> course they will go much higher. But the configuration utility must run
>> at 9600 to begin with.
>
> Besides, the wrong baud rate wouldn't preclude a program from *reading*
> from a serial interface. It would just get garbage, that's all.
>
> 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).

Well, I must admit you are right (once again). I don't agree with Joes
statement that 9600 is default.

I just now have a memory enlight. I was also not able to write on the RPIs
UART port until I disabled the hardware flow control. Found out that for
the UART it doesn't matter if soft/hard is enabled or not.

[   | F - Hardware Flow Control : No
[   | G - Software Flow Control : No

it is worth checking

Reply | Threaded
Open this post in threaded view
|

Re: Serial Port Issues

Greg Wooledge
In reply to this post by Joe Rowan
On Mon, Apr 06, 2020 at 08:38:58AM +0100, Joe wrote:
> I doubt it's that. 9600 is a sort of default these days [...]

... 25 years ago.

Reply | Threaded
Open this post in threaded view
|

Re: Serial Port Issues

Joe Rowan
On Mon, 6 Apr 2020 08:32:53 -0400
Greg Wooledge <[hidden email]> wrote:

> On Mon, Apr 06, 2020 at 08:38:58AM +0100, Joe wrote:
> > I doubt it's that. 9600 is a sort of default these days [...]  
>
> ... 25 years ago.
>

You'd be surprised how much serial stuff there is around. A lot of it
is based around low-power CPUs, PCs moved away from bare serial many
years ago (though Bluetooth is still widely used). The XBee is quite
commonly used for communication, and as I said, it comes set to 9600. So
did the serial-Ethernet converters I used a few years ago. So do the
Sony block camera modules, and other manufacturers of small cameras
have followed. This product:
https://www.lensadaptor.com/mtf-effect-control-unit-3-kit
uses 38400, but the XBees inside didn't come set that way.

--
Joe

Reply | Threaded
Open this post in threaded view
|

Re: Serial Port Issues

rhkramer
In reply to this post by tomas@tuxteam.de
On Monday, April 06, 2020 03:50:59 AM [hidden email] 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?

Reply | Threaded
Open this post in threaded view
|

Re: Serial Port Issues

tomas@tuxteam.de
On Mon, Apr 06, 2020 at 09:51:15AM -0400, [hidden email] wrote:
> On Monday, April 06, 2020 03:50:59 AM [hidden email] 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

signature.asc (205 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Fwd: Serial Port Issues

Chris Rhodin-2


---------- Forwarded message ---------
From: Chris Rhodin <[hidden email]>
Date: Mon, Apr 6, 2020 at 7:28 PM
Subject: Re: Serial Port Issues
To: <[hidden email]>


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 <[hidden email]> wrote:
On Mon, Apr 06, 2020 at 09:51:15AM -0400, [hidden email] wrote:
> On Monday, April 06, 2020 03:50:59 AM [hidden email] 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
Reply | Threaded
Open this post in threaded view
|

Re: Fwd: Serial Port Issues

deloptes-2
Chris Rhodin wrote:

> 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.

Are you sure that this is enabled in the BIOS, also some serial ports like
HP have special connectors and layouts.
Best would be to look at the manual first.

I have attached a USB to the server. From there I can log in to the
firewall. I can not use the same port in the opposite direction.

However it is strange that you do get the connection only in one direction.
It could be some kind of special connector

Otherwise I used those to enable the service

https://wiki.debian.org/systemd#Virtual_and_serial_console_changes

https://www.thegeekdiary.com/centos-rhel-7-how-to-configure-serial-getty-with-systemd/
https://wiki.archlinux.org/index.php/Working_with_the_serial_console




Reply | Threaded
Open this post in threaded view
|

Re: Serial Port Issues

Chris Rhodin-2
In reply to this post by Chris Rhodin-2
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 <[hidden email]> wrote:


---------- Forwarded message ---------
From: Chris Rhodin <[hidden email]>
Date: Mon, Apr 6, 2020 at 7:28 PM
Subject: Re: Serial Port Issues
To: <[hidden email]>


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 <[hidden email]> wrote:
On Mon, Apr 06, 2020 at 09:51:15AM -0400, [hidden email] wrote:
> On Monday, April 06, 2020 03:50:59 AM [hidden email] 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
Reply | Threaded
Open this post in threaded view
|

Re: Serial Port Issues

Chris Rhodin-2
Thanks for all the help.

Chris

On Mon, Apr 6, 2020 at 11:59 PM Chris Rhodin <[hidden email]> 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 <[hidden email]> wrote:


---------- Forwarded message ---------
From: Chris Rhodin <[hidden email]>
Date: Mon, Apr 6, 2020 at 7:28 PM
Subject: Re: Serial Port Issues
To: <[hidden email]>


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 <[hidden email]> wrote:
On Mon, Apr 06, 2020 at 09:51:15AM -0400, [hidden email] wrote:
> On Monday, April 06, 2020 03:50:59 AM [hidden email] 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
Reply | Threaded
Open this post in threaded view
|

Re: Serial Port Issues

tomas@tuxteam.de
In reply to this post by Chris Rhodin-2
On Mon, Apr 06, 2020 at 11:59:14PM -0700, Chris Rhodin 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" [...]

Ah... I see.

Thanks for posting the resolution, much appreciated :-)

Cheers
-- tomás

signature.asc (205 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Serial Port Issues

Joe Rowan
In reply to this post by Chris Rhodin-2
On Mon, 6 Apr 2020 22:53:25 -0700
Chris Rhodin <[hidden email]> wrote:


>
> Q: Is "stty" the right command line tool to check all of a serial
> ports settings?
>
It Works For Me.

I had a very simple serial requirement recently, and this did the job.

Oh, as to 9600 Baud, if you plug a USB serial port into stretch or
unstable, the stty status shows the default as.... 9600.

--
Joe

12