GNU bug report logs - #25398
stty: bug or feature?

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 25398 in the body.
You can then email your comments to 25398 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Dave B <g8kbv <at> uku.co.uk>
To: bug-coreutils <at> gnu.org
Subject: stty: bug or feature?
Date: Sun, 8 Jan 2017 18:14:48 +0000

Hi.

While arranging to automate the startup and shutdown of my ham radio
station, for safe remote control use, attempting to do as much as
possible with native Linux commands and tools, I found stty has a rather
annoying "feature", or even a bug..

This is on Linux Mint, 17.2 with the Cinamon desktop environment.  Mint
18.x seems to have more serious issues, but I'm not sure if it's the OS,
PC or serial hardware on that system, hence reverting to a 17.x system.

Anyway.

After some hours experimenting, and a lot of Googling, I can see that
many others have come across the same issue, in respect to using Linux
to program and control Arduino devices, where more often than not, the
devices are reset at inapropriate times.

This is all related to the way a serial port DTR control line is
handled.   Arduino's use it as a reset line, my radio uses it as a
"Transmit" command line.

In essence..

a bash script in the form...

#!/bin/bash

stty -F /dev/ttyUSB0 57600 -hupcl crtscts cs8 -cstopb -parity
echo -n 'EX0270001;' > /dev/ttyUSB0
sleep 1s
echo -n 'PS0;' > /dev/ttyUSB0

Would once the port is open, send the command to prevent the radio from
going into transmit, wait for 1s for that to process, then send the
command to power off.   This is does..

But...

Other software that is used to do the real remote control work, PRIOR to
me wanting to shut it all down with that script, obviously sets the
serial port so that the DTR line can be used...

So, when the above script is run, DTR is immediately asserted, DESPITE
"-hupcl" being specified.  (If I try using -cdtrdsr that results
in:-     stty: invalid argument ‘-cdtrdsr’  )

Would it be possible "one day" for stty to parse the command line args,
and only open the port when all the specified parameters are actualy in
force?

Plus, is the cdtrdsr parameter actually allowed to b negated, as
specified in the man pages.

I and many have found, that if you "do something" with the port,
specifying -hucpl, as the system boots, though at that time DTR is
briefly asserted, for subsequent invocations it is not.   Unless, a
third party program or tool sets it to be used again.

Regards.

Dave Baxter.

Message #8 received at 25398 <at> debbugs.gnu.org (full text, mbox):

From: Pádraig Brady <P <at> draigBrady.com>
To: Dave B <g8kbv <at> uku.co.uk>, 25398 <at> debbugs.gnu.org
Subject: Re: bug#25398: stty: bug or feature?
Date: Sun, 8 Jan 2017 20:08:32 +0000

On 08/01/17 18:14, Dave B wrote:
> Hi.
> 
> While arranging to automate the startup and shutdown of my ham radio
> station, for safe remote control use, attempting to do as much as
> possible with native Linux commands and tools, I found stty has a rather
> annoying "feature", or even a bug..
> 
> This is on Linux Mint, 17.2 with the Cinamon desktop environment.  Mint
> 18.x seems to have more serious issues, but I'm not sure if it's the OS,
> PC or serial hardware on that system, hence reverting to a 17.x system.
> 
> Anyway.
> 
> After some hours experimenting, and a lot of Googling, I can see that
> many others have come across the same issue, in respect to using Linux
> to program and control Arduino devices, where more often than not, the
> devices are reset at inapropriate times.
> 
> This is all related to the way a serial port DTR control line is
> handled.   Arduino's use it as a reset line, my radio uses it as a
> "Transmit" command line.
> 
> In essence..
> 
> a bash script in the form...
> 
> #!/bin/bash
> 
> stty -F /dev/ttyUSB0 57600 -hupcl crtscts cs8 -cstopb -parity
> echo -n 'EX0270001;' > /dev/ttyUSB0
> sleep 1s
> echo -n 'PS0;' > /dev/ttyUSB0
> 
> Would once the port is open, send the command to prevent the radio from
> going into transmit, wait for 1s for that to process, then send the
> command to power off.   This is does..
> 
> But...
> 
> Other software that is used to do the real remote control work, PRIOR to
> me wanting to shut it all down with that script, obviously sets the
> serial port so that the DTR line can be used...
> 
> So, when the above script is run, DTR is immediately asserted, DESPITE
> "-hupcl" being specified.  (If I try using -cdtrdsr that results
> in:-     stty: invalid argument ‘-cdtrdsr’  )

That's because your kernel doesn't carry this patch:
https://lwn.net/Articles/293523/
That is available on RHEL6, though not on Centos 7 (I don't have access to RHEL7).

> Plus, is the cdtrdsr parameter actually allowed to b negated, as
> specified in the man pages.

The man pages (and stty --help) were improved recently
to not mention options not supported on the system

> Would it be possible "one day" for stty to parse the command line args,
> and only open the port when all the specified parameters are actualy in
> force?

That would be better. It's even mentioned as a FIXME:
https://github.com/coreutils/coreutils/blob/229431d/src/stty.c#L1182-L1185

> I and many have found, that if you "do something" with the port,
> specifying -hucpl, as the system boots, though at that time DTR is
> briefly asserted, for subsequent invocations it is not.   Unless, a
> third party program or tool sets it to be used again.

There seems to be some default kernel timing involved here,
which might be controlled with `setserial close_delay ...`.
Another option might be to hack a cable to connect DTR to CTS etc.
to allow using CTS/RTS hardward flow control settings to control things?

cheers,
Pádraig

Message #13 received at 25398-done <at> debbugs.gnu.org (full text, mbox):

From: Pádraig Brady <P <at> draigBrady.com>
To: Dave B <g8kbv <at> uku.co.uk>, 25398-done <at> debbugs.gnu.org
Subject: Re: bug#25398: stty: bug or feature?
Date: Mon, 9 Jan 2017 00:31:59 +0000

[Message part 1 (text/plain, inline)]

On 08/01/17 20:08, Pádraig Brady wrote:
> On 08/01/17 18:14, Dave B wrote:
>> Would it be possible "one day" for stty to parse the command line args,
>> and only open the port when all the specified parameters are actually in
>> force?
> 
> That would be better. It's even mentioned as a FIXME:
> https://github.com/coreutils/coreutils/blob/229431d/src/stty.c#L1182-L1185

Attached patch does that.

cheers,
Pádraig

[stty-validate.patch (text/x-patch, attachment)]

Message #16 received at 25398 <at> debbugs.gnu.org (full text, mbox):

From: Jim Meyering <jim <at> meyering.net>
To: 25398 <at> debbugs.gnu.org, Pádraig Brady <P <at> draigbrady.com>, 
 g8kbv <at> uku.co.uk
Cc: 25398-done <at> debbugs.gnu.org
Subject: Re: bug#25398: stty: bug or feature?
Date: Mon, 9 Jan 2017 05:16:47 +0100

On Mon, Jan 9, 2017 at 1:31 AM, Pádraig Brady <P <at> draigbrady.com> wrote:
> On 08/01/17 20:08, Pádraig Brady wrote:
>> On 08/01/17 18:14, Dave B wrote:
>>> Would it be possible "one day" for stty to parse the command line args,
>>> and only open the port when all the specified parameters are actually in
>>> force?
>>
>> That would be better. It's even mentioned as a FIXME:
>> https://github.com/coreutils/coreutils/blob/229431d/src/stty.c#L1182-L1185
>
> Attached patch does that.

Wondered if that FIXME was mine, and it appear so, from 1998 :-)
Thank you for addressing it!

Message #22 received at 25398 <at> debbugs.gnu.org (full text, mbox):

From: Pádraig Brady <P <at> draigBrady.com>
To: Dave B <g8kbv <at> uku.co.uk>, 25398 <at> debbugs.gnu.org
Subject: Re: bug#25398: stty: bug or feature?
Date: Wed, 11 Jan 2017 11:25:15 +0000

On 11/01/17 10:17, Dave B wrote:
> Any idea what sort of time scale (months/years?) It may take for the fix
> to propagate (if it would do that) through all the various aggregation
> processes so as to appear in the regular system updates for the various
> distributions of Linux?   I'm fairly sure there are lots of Arduino
> users out there who use Linux who would very much appreciate it too,
> assuming it does fix the problem...

It depends.
The fix is isolated and not that risky,
so would be a good candidate to backport in distros.
This would be a standard procedure for them,
so would be a valid request to them.

thanks,
Pádraig

Message #25 received at 25398 <at> debbugs.gnu.org (full text, mbox):

From: Dave B <g8kbv <at> uku.co.uk>
To: Pádraig Brady <P <at> draigBrady.com>, 25398 <at> debbugs.gnu.org
Subject: Re: bug#25398: stty: bug or feature?
Date: Wed, 11 Jan 2017 10:17:27 +0000

On 08/01/17 20:08, Pádraig Brady wrote:
> On 08/01/17 18:14, Dave B wrote:
>> Hi.
>>
>> While arranging to automate the startup and shutdown of my ham radio
>> station, for safe remote control use, attempting to do as much as
>> possible with native Linux commands and tools, I found stty has a rather
>> annoying "feature", or even a bug..
>>
>> This is on Linux Mint, 17.2 with the Cinamon desktop environment.  Mint
>> 18.x seems to have more serious issues, but I'm not sure if it's the OS,
>> PC or serial hardware on that system, hence reverting to a 17.x system.
>>
>> Anyway.
>>
>> After some hours experimenting, and a lot of Googling, I can see that
>> many others have come across the same issue, in respect to using Linux
>> to program and control Arduino devices, where more often than not, the
>> devices are reset at inapropriate times.
>>
>> This is all related to the way a serial port DTR control line is
>> handled.   Arduino's use it as a reset line, my radio uses it as a
>> "Transmit" command line.
>>
>> In essence..
>>
>> a bash script in the form...
>>
>> #!/bin/bash
>>
>> stty -F /dev/ttyUSB0 57600 -hupcl crtscts cs8 -cstopb -parity
>> echo -n 'EX0270001;' > /dev/ttyUSB0
>> sleep 1s
>> echo -n 'PS0;' > /dev/ttyUSB0
>>
>> Would once the port is open, send the command to prevent the radio from
>> going into transmit, wait for 1s for that to process, then send the
>> command to power off.   This is does..
>>
>> But...
>>
>> Other software that is used to do the real remote control work, PRIOR to
>> me wanting to shut it all down with that script, obviously sets the
>> serial port so that the DTR line can be used...
>>
>> So, when the above script is run, DTR is immediately asserted, DESPITE
>> "-hupcl" being specified.  (If I try using -cdtrdsr that results
>> in:-     stty: invalid argument ‘-cdtrdsr’  )
> That's because your kernel doesn't carry this patch:
> https://lwn.net/Articles/293523/
> That is available on RHEL6, though not on Centos 7 (I don't have access to RHEL7).
>
>> Plus, is the cdtrdsr parameter actually allowed to b negated, as
>> specified in the man pages.
> The man pages (and stty --help) were improved recently
> to not mention options not supported on the system
>
>> Would it be possible "one day" for stty to parse the command line args,
>> and only open the port when all the specified parameters are actualy in
>> force?
> That would be better. It's even mentioned as a FIXME:
> https://github.com/coreutils/coreutils/blob/229431d/src/stty.c#L1182-L1185
>
>> I and many have found, that if you "do something" with the port,
>> specifying -hucpl, as the system boots, though at that time DTR is
>> briefly asserted, for subsequent invocations it is not.   Unless, a
>> third party program or tool sets it to be used again.
> There seems to be some default kernel timing involved here,
> which might be controlled with `setserial close_delay ...`.
> Another option might be to hack a cable to connect DTR to CTS etc.
> to allow using CTS/RTS hardward flow control settings to control things?
>
> cheers,
> Pádraig
Hi.

Just catching up with this.

Thanks for the prompt replies everybody, much appreciated and good to
know that there is a possible fix.

However, from a plain user aspect, who's had his fingers burnt trying
this in the past.  I'm reluctant to process patches on a working system,
mainly because I haven’t a clue know how to go about doing that safely,
with a get out of jail card for when it goes bad, as in a bricked OS etc.

I've managed to brick things in the past trying to apply patches in the
past...  That, and I don't have an anyway near enough identical system
to experiment on (where, when I break it, it doesn’t matter etc) to test
it...   Much as I'd like to.

Any idea what sort of time scale (months/years?) It may take for the fix
to propagate (if it would do that) through all the various aggregation
processes so as to appear in the regular system updates for the various
distributions of Linux?   I'm fairly sure there are lots of Arduino
users out there who use Linux who would very much appreciate it too,
assuming it does fix the problem...

Anyway, thanks again.   As before, much appreciated, not that I can do
much with it just now.

Best Regards All.

Dave Baxter (G0WBX)

Message #28 received at 25398 <at> debbugs.gnu.org (full text, mbox):

From: Bernhard Voelker <mail <at> bernhard-voelker.de>
To: Dave B <g8kbv <at> uku.co.uk>, Pádraig Brady
 <P <at> draigBrady.com>, 25398 <at> debbugs.gnu.org
Subject: Re: bug#25398: stty: bug or feature?
Date: Wed, 11 Jan 2017 20:38:50 +0100

On 01/11/2017 11:17 AM, Dave B wrote:
> Any idea what sort of time scale (months/years?) It may take for the fix
> to propagate (if it would do that) through all the various aggregation
> processes so as to appear in the regular system updates for the various
> distributions of Linux?

The regular way of getting this as part of a new version into a new
release of your distribution greatly depends on the release cycle.
Some distributions have a rolling release, some have an annual release
cycle, and some even more seldom; so it could take up to ~ 2years.
To get this into your distribution as a bug fix as fast as possible,
you should simply open a bug report there, and point to this discussion.

Have a nice day,
Berny

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.