linux-kernel - [SOLVED] Serial buffer corruption [was Re: FTDI usb-serial possible bug]

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: <5486cca80705040138r6ac16e9bp77e4f6217720ea8@mail.gmail.com>
Date:	Fri, 4 May 2007 10:38:10 +0200
From:	"Antonino Ingargiola" <tritemio@...il.com>
To:	linux-usb-users@...ts.sourceforge.net
Cc:	linux-kernel@...r.kernel.org
Subject: [SOLVED] Serial buffer corruption [was Re: FTDI usb-serial possible bug]

Hi,

On 4/14/07, Antonino Ingargiola <tritemio@...il.com> wrote:
> Hi to the list,
>
> I report a problem found with a device that use the FTDI chip to
> communicate data to pc.
>
<summary of snipped problem description>
The scenario is: a serial device streams data continuously toward the
pc. The application requires the data be read once in a while (so not
all data is read). There is a corruption reading the data (old data
mixed with the new one).

The problem is absent in windows (using the same HW device and python code).
<end summary>

I report for reference how I solved the problem.

The problem arises because (while not reading)  the input stream fills
the input buffer. Once filled, the buffer does not accept new data, so
the lost data is the new one not the old.

When one need to read the data he flushes the input buffer, but this
is not sufficient. In fact there is a second (hardware?) buffer in the
chain that, suddenly after the flush, pushes a chunk of old data in to
the input buffer. After this the new data is queued. This result in
data corruption at the edge between the new and the old data in the
buffer.

The problem has been reproduced also with an usb-serial device using
the cdc-acm driver and with two serial port linked by a null-modem
cable (so its not FTDI specific).

To solve the problem we must do a complete flush of all the buffer
chain. I do this flushing the input multiple times with a small pause
between them. In my case 10 flushes separated by a 10ms pause always
empties the whole buffer chain, so I get no corruption anymore. I'ts
not an elegant solution but it works (10 flushes are an overkill but I
want to be _really_ sure to read the correct data).

If someone know a better way to solve the problem is more than welcome
to suggest. Furthermore just a confirmation of my analysis of the
serial buffer behavior would be appreciated.

What puzzled me at first was that on windows the "flush" flushes all
the buffers, so the problem does not arises. Maybe Linux serial stack
works this way because is dictated by the POSIX standard ... I don't
know, just guessing.

Thanks,

  ~ Antonio

PS: For reference, the original report was:
http://marc.info/?l=linux-kernel&m=117683012421931&w=2
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/