lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID:
 <DU0PR02MB7899EC8515D8FF35B4D01465C4292@DU0PR02MB7899.eurprd02.prod.outlook.com>
Date: Thu, 14 Mar 2024 22:13:03 +0000
From: Cameron Williams <cang1@...e.co.uk>
To: linux-usb@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: CH341 RTS/CTS flow control disabled in driver?

Hi all.

I am wondering if anyone knows anything regarding the RTS/CTS lines on the CH341 (maybe CH340 though I have no chip example).
I have two CH341-based devices, both a generic 3V3 uart and also an all-in-one type device with SPI/I2C.

>From my tests, neither of them seem to have RTS/CTS respected, and I don't believe they are fake?

My test procedure is as follows:
1) Have nothing connected except TxD/RxD via a jumper.
2) Open `statserial` to check the status of the lines. On all devices, RTS is set to 1 and CTS is set to 0.
3) Open PuTTY, ttyUSB0, 9600 baud, RTS/CTS flow control. Data should not flow as CTS is not high. Close PuTTY.
4) Open PuTTY again, same settings, but with no flow control. Characters buffered from step 3 should now appear thanks to the loopback in step 1.

Alternatively, for step 3 and 4, set Picocom to use RTS/CTS, send some data, then disable flow control, and the buffered data will now flow.

Using an (albeit fake) FTDI device, and PL2303 based device, they both work as expected.
A CP2102 doesn't like to exit with stuff already in the buffer (just hangs PuTTY), but thats a separate issue, and at least it is respecting CTS/RTS.

However with both CH341 devices I have, on step 3, the data flows regardless. Checking in statserial, CTS is indeed still set to 0.

Is this intended behaviour? Looking through the source I can see RTS/DTR should be supported, but it just doesn't seem to work.

If anyone wants to look at it I'm happy to help debug.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ