CREAD ignored by almost all USB serial drivers

CREAD ignored by almost all USB serial drivers

[Harald Welte]

[Copied on requst from https://bugzilla.kernel.org/show_bug.cgi?id=205033]

It seems that a lot of Linux kernel USB serial device drivers are
ignoring the CREAD setting of termios.c_cflag.

The man page is quite clear:
       CREAD  Enable receiver.

The glibc man page at
https://ftp.gnu.org/old-gnu/Manuals/glibc-2.2.3/html_chapter/libc_17.html
states:
	"Macro: tcflag_t CREAD
	 If this bit is set, input can be read from the terminal.
	 Otherwise, input is discarded when it arrives."

When I mask this bit and then call tcsetattr(), I'm still receiving
input characters, at least on a pl2303 USB UART.  Looking at the source
code of drivers/usb/serial/, the *only* driver appearing to respect
CREAD is digi_acceleport.c.  All others seem to ignore it.  To the
contrary, most classic serial drivers in drivers/tty/serial seem to
implement it.

In absence of low-level support in individual drivers to actually
disable the receiver in hardware, I would have at least expected the
core tty/serial layer to drop/discard any characters received by the
hardware while CREAD is not set.  But that also doesn't appear to be the
case.

What's even more worrying is that the tcsetattr() call succeeds, i.e. it
is a silent error.  I would expect the kernel to either implement the
functionalty in one way or another, or simply return tcsetattr() with
an error if an unsupported combination (i.e. CFLAG not set) is
configured.

This is not a theoretical issue.  Anyone implementing a half-duplex
protocol with shared Rx and Tx line will face the same issue.

Am I missing something here?  Please don't tell me that I just
discovered something that's broken for some 20-odd years, or at the very
least as far as normal linux.git history reaches back :/

Please keep me in Cc of any responses, I'm not subscribed to linux-usb.

Thanks!

Regards,
	Harald
-- 
- Harald Welte <laforge@gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)

Re: CREAD ignored by almost all USB serial drivers

[Greg KH]

On Sat, Sep 28, 2019 at 10:49:55PM +0200, Harald Welte wrote:
> [Copied on requst from https://bugzilla.kernel.org/show_bug.cgi?id=205033]
> 
> It seems that a lot of Linux kernel USB serial device drivers are
> ignoring the CREAD setting of termios.c_cflag.
> 
> The man page is quite clear:
>        CREAD  Enable receiver.
> 
> The glibc man page at
> https://ftp.gnu.org/old-gnu/Manuals/glibc-2.2.3/html_chapter/libc_17.html
> states:
> 	"Macro: tcflag_t CREAD
> 	 If this bit is set, input can be read from the terminal.
> 	 Otherwise, input is discarded when it arrives."
> 
> When I mask this bit and then call tcsetattr(), I'm still receiving
> input characters, at least on a pl2303 USB UART.  Looking at the source
> code of drivers/usb/serial/, the *only* driver appearing to respect
> CREAD is digi_acceleport.c.  All others seem to ignore it.  To the
> contrary, most classic serial drivers in drivers/tty/serial seem to
> implement it.
> 
> In absence of low-level support in individual drivers to actually
> disable the receiver in hardware, I would have at least expected the
> core tty/serial layer to drop/discard any characters received by the
> hardware while CREAD is not set.  But that also doesn't appear to be the
> case.
> 
> What's even more worrying is that the tcsetattr() call succeeds, i.e. it
> is a silent error.  I would expect the kernel to either implement the
> functionalty in one way or another, or simply return tcsetattr() with
> an error if an unsupported combination (i.e. CFLAG not set) is
> configured.
> 
> This is not a theoretical issue.  Anyone implementing a half-duplex
> protocol with shared Rx and Tx line will face the same issue.
> 
> Am I missing something here?  Please don't tell me that I just
> discovered something that's broken for some 20-odd years, or at the very
> least as far as normal linux.git history reaches back :/

You just discovered something that has been broken since the first
usb-serial driver was written, all those years ago :)

I did add support for this to the digi driver, as you saw, as the
hardware had support for it.  For everything else, they are all just
dumb uarts and do not expose that information to the host computer and I
think everyone just forgot about this option.

Given that you are the first to report it that I can think of, I don't
think very many people use half-duplex protocols with a shared Rx/Tx
(which is crazy anyway...)

> Please keep me in Cc of any responses, I'm not subscribed to linux-usb.

Is there a specific usb-serial driver that you are using that you want
to have this support added to?

thanks,

greg k-h

Re: CREAD ignored by almost all USB serial drivers

[Harald Welte]

Hi Greg,

On Mon, Oct 07, 2019 at 01:06:33PM +0200, Greg KH wrote:
> On Sat, Sep 28, 2019 at 10:49:55PM +0200, Harald Welte wrote:
> > It seems that a lot of Linux kernel USB serial device drivers are
> > ignoring the CREAD setting of termios.c_cflag.
>
> You just discovered something that has been broken since the first
> usb-serial driver was written, all those years ago :)

Amazing and frightening at the same time.  I would have expected
somebody had built something like a hardware test fixture to test those
drivers during all those decades.  Something like a "well-known" serial
device as the tester, attaching to all the handshake etc. lines of the
"device under test" and then running through many of the possible
settings from HW to SW flow control, baud rate, parity, number of stop
bits, break characters, etc.

I have no shortage of projects to work on, but if somebody else was
interested to host a physical setup with many different [USB] serial
ports and some CI around, I might be tempted to build the actual tester
hardware and some test suite software for it.

> I did add support for this to the digi driver, as you saw, as the
> hardware had support for it.  For everything else, they are all just
> dumb uarts and do not expose that information to the host computer and I
> think everyone just forgot about this option.

I am aware that many USB serial adapters are rather "dumb", hence my suggestion
to add a related option to the core usb-serial, or even to the core tty/serial
layer: If the driver doesn't process CREAD, simply discard the received bytes
at this common/shared layer.

> Given that you are the first to report it that I can think of, I don't
> think very many people use half-duplex protocols with a shared Rx/Tx
> (which is crazy anyway...)

Every smart card interface [1] on this planet, including every SIM card in every
mobile phone uses such a setup: asynchronous half-duplex communication with
shared Rx/Tx.  Sure, not many people attach something like that to a USB-Serial
adapter (as oppose to a USB-CCID reader), but I just wanted to clarify
it's not as obscure as one may think.  You can actually buy
ultra-low-cost SIM card readers built that way.

Also, I would assume that RS-485 is still used in lots of technology,
including e.g. DMX and industrial control systems.  Unless you go for a
rather obscure 4-wire RS-485, then you have the same half-duplex
operation on shared medium.  Please note that USB-RS485 adapters exist,
using a variety of USB-serial chipsets.

> > Please keep me in Cc of any responses, I'm not subscribed to linux-usb.
> 
> Is there a specific usb-serial driver that you are using that you want
> to have this support added to?

I'm typically using cp2102 or FTDI based devices, though of
course in terms of "market footprint", PL2303 probably beats all of the
others.  However, as indicated, maybe the "catch-all fall-back" in the
core is an easy way to adhere termios rules about CREAD without having
to hack up every driver individually?

Thanks,
	Harald

[1] well, not every, but most smart cards follow ISO 7816-3, which is
    what I'm talking about
-- 
- Harald Welte <laforge@gnumunks.org>            http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)

Re: CREAD ignored by almost all USB serial drivers

[Greg KH]

On Mon, Oct 07, 2019 at 03:18:52PM +0200, Harald Welte wrote:
> Hi Greg,
> 
> On Mon, Oct 07, 2019 at 01:06:33PM +0200, Greg KH wrote:
> > On Sat, Sep 28, 2019 at 10:49:55PM +0200, Harald Welte wrote:
> > > It seems that a lot of Linux kernel USB serial device drivers are
> > > ignoring the CREAD setting of termios.c_cflag.
> >
> > You just discovered something that has been broken since the first
> > usb-serial driver was written, all those years ago :)
> 
> Amazing and frightening at the same time.  I would have expected
> somebody had built something like a hardware test fixture to test those
> drivers during all those decades.  Something like a "well-known" serial
> device as the tester, attaching to all the handshake etc. lines of the
> "device under test" and then running through many of the possible
> settings from HW to SW flow control, baud rate, parity, number of stop
> bits, break characters, etc.

I had a tester that was just a loopback device.  Amazing what just a
simple device like that found over time, these things barely work :)

Anyway, yes, a "real" test setup like this would be great to have, I
don't know of one around anywhere, and if you use it, I am sure you will
find lots of issues.  Turns out almost all usb-serial devices are used
for "basic" rx/tx stuff, all of the "fancy" serial things just are not
all that common anymore given that serial is not the primary way data is
transferred anymore.

> I have no shortage of projects to work on, but if somebody else was
> interested to host a physical setup with many different [USB] serial
> ports and some CI around, I might be tempted to build the actual tester
> hardware and some test suite software for it.

Would be nice to see :)

> > I did add support for this to the digi driver, as you saw, as the
> > hardware had support for it.  For everything else, they are all just
> > dumb uarts and do not expose that information to the host computer and I
> > think everyone just forgot about this option.
> 
> I am aware that many USB serial adapters are rather "dumb", hence my suggestion
> to add a related option to the core usb-serial, or even to the core tty/serial
> layer: If the driver doesn't process CREAD, simply discard the received bytes
> at this common/shared layer.

Yes, that could be done in the usb-serial core probably.

> > Given that you are the first to report it that I can think of, I don't
> > think very many people use half-duplex protocols with a shared Rx/Tx
> > (which is crazy anyway...)
> 
> Every smart card interface [1] on this planet, including every SIM card in every
> mobile phone uses such a setup: asynchronous half-duplex communication with
> shared Rx/Tx.  Sure, not many people attach something like that to a USB-Serial
> adapter (as oppose to a USB-CCID reader), but I just wanted to clarify
> it's not as obscure as one may think.  You can actually buy
> ultra-low-cost SIM card readers built that way.
> 
> Also, I would assume that RS-485 is still used in lots of technology,
> including e.g. DMX and industrial control systems.  Unless you go for a
> rather obscure 4-wire RS-485, then you have the same half-duplex
> operation on shared medium.  Please note that USB-RS485 adapters exist,
> using a variety of USB-serial chipsets.

485 just got added to some tty drivers recently, so yes, it is used, but
not all that common it seems.  Or maybe it is and everyone "knows" to
buy the one good device that supports it.

thanks,

greg k-h