Bug 12607

Summary:	Plugwise stick (FTDI USB Serial Device) no longer working
Product:	Mageia	Reporter:	Martin Ward <martin>
Component:	RPM Packages	Assignee:	Mageia Bug Squad <bugsquad>
Status:	RESOLVED INVALID	QA Contact:
Severity:	major
Priority:	Normal	CC:	martin, tmb
Version:	4
Target Milestone:	---
Hardware:	x86_64
OS:	Linux
Whiteboard:
Source RPM:		CVE:
Status comment:

Description Martin Ward 2014-02-05 13:03:12 CET

I have a Plugwise USB stick which presents itself as an FTDI USB Serial Device
when plugged in (Product: FT232R USB UART) and creating the device file
/dev/ttyUSB0

After running:

stty -F /dev/ttyUSB0 ispeed 115200 ospeed 115200 cs8 -parenb raw

on Mageia 3 I can open the device file, write commands to it and read
the results back (using a perl script with sysopen, sysread, syswrite etc.)
The commands and responses are a mixture of binary and ASCII text,
for example the "init" command is \x05\x05\x03\x03000AB43C\r\n
and produces a response of \x05\x05\x03\x03000001BD00C1B681\r\n
Each command and each reply should start with the initialisation string
(four binary characters) and end with \r\n (carriage return, newline).

However, with Mageia 4 I only get error responses and the responses
do not contain the initial string of four binary characters
\x05\x05\x03\x03 and have \n\n instead of \r\n.

I have compiled perl from source and tested the perl script with the same
executable on both Mageia 3 and 4: so I know that perl isn't the culprit.

Is there something in the way tty devices are handled which has changed
with the new Linux kernel?

Manuel Hiebel 2014-02-05 18:30:38 CET

CC: (none) => tmb

Comment 1 Martin Ward 2014-02-05 20:11:46 CET

After adding "raw" to the stty command, the 

Is there a way to "sniff" the characters actually sent and received by the serial port to see if they are being corrupted?

My machine is set up to dual boot between Mageia 3 and 4, so testing should be easy.

After booting to Mageia 4 I ran a couple of tests and got these results:
The string in parentheses after "write_line" is what is sent to the USB stick,
the string after "buffer=nnn" is what is read back.

Initialising serial port...
init_stick()
write_cmd(000A)
write_line(\x05\x05\x03\x03000AB43C\r\n)
  buffer=0 want 22 bytes 9.11.2
  buffer=22 (\x05\x05\x03\x030000000100C1FEED\r\n)
  Response OK, seq = 1
  buffer=0 want 60 bytes 8.6.8.6.6.11.12.3
  buffer=60 (\x05\x05\x03\x0300110001000D6F0000C3CAD301011B0D6F0000995323881BFF014F\r\n)
  Online status = 01
  Network code  = 1B0D6F0000995323
  Network id    = 881B
Stick MAC = 000D6F0000C3CAD3, Circle+ MAC = 000D6F0000995323

Initialising serial port...
init_stick()
write_cmd(000A)
write_line(\x05\x05\x03\x03000AB43C\r\n)
  buffer=0 want 22 bytes 10.12
  buffer=22 (\x05\x05\x03\x030000000000C264DF\r\n)
---- Got 00C2 error response: restarting...
write_line(\x05\x05\x03\x030008005049\r\n)
  buffer=18 want 38 bytes 1.4.12.3
  buffer=38 (0000000000C264DF\r\n\x83\x05\x05\x03\x030000000000C264D)
Unexpected result from restart:
0000000000C264DF\r\n\x83\x05\x05\x03\x030000000000C264D

The first command succeeded, but the next (and subsequent) commands fail.
An 00C2 error usually means that the command is malformed.

After rebooting back to Mageia 3, the first command fails with an error
(perhaps there was garbage left in the stick's input buffer?)
but the second and subsequent commands succeed:

Initialising serial port...
init_stick()
write_cmd(000A)
write_line(\x05\x05\x03\x03000AB43C\r\n)
  buffer=0 want 22 bytes 5.11.6
  buffer=22 (\x05\x05\x03\x030000000000C264DF\r\n)
---- Got 00C2 error response: restarting...
write_line(\x05\x05\x03\x030008005049\r\n)
  buffer=18 want 38 bytes 1.11.8
  buffer=38 (0000000000C264DF\r\n\x83\x05\x05\x03\x030000000100C1FEE)
Unexpected result from restart:
0000000000C264DF\r\n\x83\x05\x05\x03\x030000000100C1FEE

Initialising serial port...
init_stick()
write_cmd(000A)
write_line(\x05\x05\x03\x03000AB43C\r\n)
  buffer=0 want 22 bytes 8.12.2
  buffer=22 (\x05\x05\x03\x030000000200C1103F\r\n)
  Response OK, seq = 2
  buffer=0 want 60 bytes 8.12.11.12.12.5
  buffer=60 (\x05\x05\x03\x0300110002000D6F0000C3CAD301011B0D6F0000995323881BFFBED1\r\n)
  Online status = 01
  Network code  = 1B0D6F0000995323
  Network id    = 881B
Stick MAC = 000D6F0000C3CAD3, Circle+ MAC = 000D6F0000995323

Martin Ward 2014-02-05 20:13:00 CET

CC: (none) => martin

Comment 2 Martin Ward 2014-02-06 12:02:08 CET

More information:

After adding "raw" to the initial stty command, the binary characters
appear to be returned from the stick correctly and the first command
to the stick works, but all subsequent commands fail.
The stty options I use are:

stty -F /dev/ttyUSB0 ispeed 115200 ospeed 115200 cs8 -parenb raw

I tried booting Mageia 4 using the Mageia 3 kernel (3.10.24-desktop-2.mga3)
and the problem still appeared: so its not the kernel.

Unplugging and re-plugging the stick enables it to work for just one command:
after which every command gives an error. So this suggests that the
"end of command" string \r\n is being garbled. However, I have not been
able to reproduce the "Mageia 4" behaviour on Mageia 3 (first command
works, all later ones fail) by sending garbled data.

Comment 3 Martin Ward 2014-02-13 21:47:38 CET

After further investigation it appears that the problem can be fixed by adding
some extra options to the stty command:

stty ispeed 115200 ospeed 115200 cs8 -parenb raw -iexten -echo -echoe -echok -echoctl -echoke < /dev/ttyUSB0

It seems that at some point the default settings for a tty have changed.

Its not really a bug, however, since a program using a tty should not assume
anything about the settings, so I am marking this as RESOLVED.

Status: NEW => RESOLVED
Resolution: (none) => INVALID