Re: Serial Port Issues
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". 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. excellent! :) have fun! :) songbird
Re: Serial Port Issues
On Tue, 07 Apr 2020 08:24:50 -0500 "Martin McCormick" wrote: > deloptes writes: > > 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 > > > > Another possible fly in the ointment could be a hardware > issue. Some RS-232 ports are old-school and aren't happy with > any voltage range other than +12 for one state and -12 for the > other while there are serial ports that can handle state changes > of + or - 3 volts so they safely handle logic-level signals and > also can handle the old-school RS-232 levels. Then there are > some that handle logic-level signals and would figuratively melt > if you hit them with +-12 volts. They're not 'old-school', they're badly designed. The spec says, unequivocally, plus and minus 3V-15V and has done for a great many years. The 'logic' level data, quite common these days, is RS-422 or RS-485. It should not ever be compatible with RS-232. Most serial data originates at logic level (anything from 2.8V to 5V) and ends up at logic level somewhere else, so there is little point in converting to and from RS-232. But things like radio modules often run on 3.3V or lower, so it may be necessary to convert to and from RS-422 levels. Many modern 'RS-232' devices, particularly the really cheap USB-serial modules, in fact use 3.3V/0V or 5V/0V logic levels, as the term 'RS-232' has just come to mean 'low-speed serial' to many people. -- Joe
Re: Fwd: Serial Port Issues
deloptes writes: > 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 Another possible fly in the ointment could be a hardware issue. Some RS-232 ports are old-school and aren't happy with any voltage range other than +12 for one state and -12 for the other while there are serial ports that can handle state changes of + or - 3 volts so they safely handle logic-level signals and also can handle the old-school RS-232 levels. Then there are some that handle logic-level signals and would figuratively melt if you hit them with +-12 volts. Martin
Re: Serial Port Issues
On Mon, 6 Apr 2020 22:53:25 -0700 Chris Rhodin 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
Re: Serial Port Issues
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 Description: Digital signature
Re: Serial Port Issues
Thanks for all the help. Chris On Mon, Apr 6, 2020 at 11:59 PM 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". 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 wrote: > >> >> >> -- Forwarded message ----- >> From: Chris Rhodin >> Date: Mon, Apr 6, 2020 at 7:28 PM >> Subject: Re: Serial Port Issues >> To: >> >> >> 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 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 >>> >>
Re: Serial Port Issues
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 wrote: > > > -- Forwarded message - > From: Chris Rhodin > Date: Mon, Apr 6, 2020 at 7:28 PM > Subject: Re: Serial Port Issues > To: > > > 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 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 >> >
Re: Fwd: Serial Port Issues
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
Fwd: Serial Port Issues
-- Forwarded message - From: Chris Rhodin Date: Mon, Apr 6, 2020 at 7:28 PM Subject: Re: Serial Port Issues To: 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 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 >
Re: Serial Port Issues
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 signature.asc Description: Digital signature
Re: Serial Port Issues
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?
Re: Serial Port Issues
On Mon, 6 Apr 2020 08:32:53 -0400 Greg Wooledge 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
Re: Serial Port Issues
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.
Re: Serial Port Issues
to...@tuxteam.de 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
Re: Serial Port Issues
On Mon, Apr 06, 2020 at 08:38:58AM +0100, Joe wrote: > On Mon, 06 Apr 2020 08:53:05 +0200 > deloptes 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 Description: Digital signature
Re: Serial Port Issues
On Mon, 06 Apr 2020 08:53:05 +0200 deloptes 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
Re: Serial Port Issues
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?
Re: Serial Port Issues
to...@tuxteam.de wrote: > 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
Re: Serial Port Issues
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
Re: Serial Port Issues
to...@tuxteam.de 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
Re: Serial Port Issues
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
Re: Serial Port Issues
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 Description: Digital signature
Serial Port Issues
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
