bug#25398: stty: bug or feature?

[Dave B]

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)