FTDIgate 2.0?

[Karel]

You are a real engineer aren't you? If you are a real engineer then you should know it is very bad to send random data to a device. I have come across several devices which lock up when confronted with data the device didn't expect. One of those was actually performing a safety critical function so yes, it is very bad to send random data to a device. I also start to doubt you can read because this has been discusses at length in this same thread so you are trying to create a new infinite loop here so lets leave this subject alone right here. You can read all about it in the previous pages.

Yes, I am. Apparently you aren't otherwise you should know that a safety critical device that can cause seriouse injury because of a glitch on a serial port,
should be taken out of service immediately. There's simply no excuse for that.

In a perfect world But if there's no budget for that, the poorly designed device has to stay. Mr. Manager will tell you that.

So, aim your anger to Mr. Manager. Not to FTDI.

[Bud]

Not that it is wrong but it is useless and will do no job in many use cases where devices use proprietary application level protocols. This message will simply be ignored as noise. FTDI what, thinks that every single use case involves someone stairing at the display and reading the bytestream?

[Karel]

So you're okay with causing harm as long as the people affected can blame someone else? WTF dude?

Show me a documented example where the behaviour of FTDI's driver caused serious injury.

[nctnico]

So you're okay with causing harm as long as the people affected can blame someone else? WTF dude?

Show me a documented example where the behaviour of FTDI's driver caused serious injury.

So people should get hurt or killed before you are convinced? 

[c4757p]

Probably a good idea to just stop now. We're clearly at the "I'll say anything that sounds like it proves my point" stage of the argument.

[Karel]

So you're okay with causing harm as long as the people affected can blame someone else? WTF dude?

Show me a documented example where the behaviour of FTDI's driver caused serious injury.

So people should get hurt or killed before you are convinced? 

No, people shouldn't get hurt, those are your words.

If you really know about a safety critical device that can cause serious injury because of a glitch on the serial port,
than I assume you took the device out of service or at least reported it to the authorities and made sure that they
took it out of service. No risk anymore that something goes wrong.

If not, then you are a hypocrite that wines about FTDI but don't really care about safety.

[Karel]

FTDI what, thinks that every single use case involves someone stairing at the display and reading the bytestream?

The engineer that is investigating the defect device will.

[Karel]

Yes, I am. Apparently you aren't otherwise you should know that a safety critical device that can cause seriouse injury because of a glitch on a serial port,
should be taken out of service immediately. There's simply no excuse for that.

Yes, it should. That is a dangerous machine. But how does that mean that it's okay to screw around with it?

How many dangerous machines have stopped working because of FTDI's driver?

[timb]

Yes, I am. Apparently you aren't otherwise you should know that a safety critical device that can cause seriouse injury because of a glitch on a serial port,
should be taken out of service immediately. There's simply no excuse for that.

Yes, it should. That is a dangerous machine. But how does that mean that it's okay to screw around with it?

How many dangerous machines have stopped working because of FTDI's driver?

Wow. Just wow.

Stop the train. This is where I get off.

[Koen]

So far over 35 pages we've had "what ifs", unsubstantiated claims about counterfeit FTDI chips in regular distribution, unsubstantiated claims about major corporations discontinuing their use of FTDI chips and unsubstantiated claims about safety-critical systems compromised by random serial strings. Should people take your word for it ? Is linking to the related press releases impossible ? Or is it so obscure you can't name the distributor/company/product impacted without being found out ?

How can you try to prove your point without providing any evidence for your claims. This is debating 101.

[nctnico]

So far over 35 pages we've had "what ifs", unsubstantiated claims about counterfeit FTDI chips in regular distribution, unsubstantiated claims about major corporations discontinuing their use of FTDI chips and unsubstantiated claims about safety-critical systems compromised by random serial strings. Should people take your word for it ? Is linking to the related press releases impossible ? Or is it so obscure you can't name the distributor/company/product impacted without being found out ?

How can you try to prove your point without providing any evidence for your claims. This is debating 101.

There are documented cases that counterfeit components found their way into military devices. Google that. Also a simple data conversion problem can cause a rocket intended for launching satellites into space to fail ( http://sunnyday.mit.edu/accidents/Ariane5accidentreport.html ) due to feeding random data into a system which doesn't suspect it. It shouldn't need much thinking to understand that it is a bad idea in general to feed random data into any system.

Quote from the report:
Part of these data at that time did not contain proper flight data, but showed a diagnostic bit pattern of the computer of the SRI 2, which was interpreted as flight data.

IOW: The 'what ifs' aren't about pinpointing existing cases but doing solid engineering and the steps to take / processes to follow in order to minimize the risk on designing a (potential) problem into a product which can cause a customer problems at some point. I have been dealing with customers for over 25 years already and I have learned that a simple problem from an engineering perspective can be perceived as a huge problem by a customer. So by all means: get rid of any potential source of problems!

[Karel]

There are documented cases that counterfeit components found their way into military devices.

Lets say, it's better that a (militairy) device doesn't want to start because of a driver update,
than starting fine and during it's service it malfunctions unexpectedly because the counterfeit chip is a bit out of spec.

[f4eru]

So far, in this whole thread, nobody has made a valid point why it's wrong to send a string that contains "not a genuine chip".

Bullshit. It's injecting corrupt data in a data stream you know nothing about.

Tampering for any reason a random data stream is  simply dangerous. it's not acceptable from every point of view.
it's Malware.

[Koen]

I'll take your point about Ariane 5 first launch but for future readers, I'll add this quote from the report :

f) Approx. 0.05 seconds later the active inertial reference system, identical to the back-up system in hardware and software, failed for the same reason. Since the back-up inertial system was already inoperative, correct guidance and attitude information could no longer be obtained and loss of the mission was inevitable.

It isn't solely unexpected data but irrecoverable instruments.

[dadler]

My favorite (uh, wrong word here) story like this is the Therac-25:

https://en.m.wikipedia.org/wiki/Therac-25

[Karel]

It's injecting corrupt data in a data stream you know nothing about.

As far as I know, it isn't. The original data never arrives. The host will only receive the string "not a genuine chip".

[cdev]

there should be a generic fallback mode where all usb-uart or usb-serial converters maintain basic functionality, using some generic fallback code thats community developed.

[bingo600]

Just use Linux 
FTDI got the finger  when trying to implement their "changes" to the linux ftdi driver.

And ear/eye plugs against Mr. K
We should be able to select a "hide posts" from  , in our settings.

/Bingo

[edavid]

And ear/eye plugs against Mr. K
We should be able to select a "hide posts" from  , in our settings.

The forum does have an ignore list feature:

https://www.eevblog.com/forum/profile/?area=lists;sa=ignore;

[CJay]

Out of all the unsubstantiated what if scenarios and other such in this thread, I take the following:

1. Good system design should preclude malfunction from 'random' or corrupted (intentionally or not) data.

I agree wholeheartedly, a no brainer, but we all know there's that one in a million, billion, whatever, combination of input that can cause an issue. Sadly software is rarely 100% verifiably bug free.

2. No system can be entirely fault free unless it's so simple it's possible to prove operation for every single possible instance of presented data along with every possible environmental influence.

My take on this:

The nature of my job means that I can be many miles from home at stupid times of day and night, thus I have been in situations many times where I've needed to buy random pieces of computer hardware from vendors I would not normally use to perform job function, on at least a couple of occasions I've had to buy USB-Serial adapters (things go faulty, get mechanically damaged, lost, etc.).

When I'm two hundred miles from home at three AM in the morning with people in positions of genuine, government mandated, authority asking me how long something is going to take to repair, I do not want to explain that my serial dongle doesn't work because of someone acting like a 2 year old and having a hissy fit which may or may not render the USB dongle bought from their local 24 hour supermarket unusable.

So, I avoid FTDI unless it's absolutely unavoidable (I.E. built in to a larger product).

Not a huge loss for FTDI, not even the price of a sandwich at lunch time but the tiny drip drip of water erodes much larger mountains than FTDI.

Shortsighted and childish of them.

[Gyro]

Noooh!    After two weeks of peace too! 

EDIT: I suggest reading through all 36 pages of this thread to check that anything you're planning to say hasn't been said several times already!

[janoc]

Perhaps I am blind but I really do miss the possibility to hide/ignore certain thread from the unread posts ...

 

[edavid]

Perhaps I am blind but I really do miss the possibility to hide/ignore certain thread from the unread posts ...

You have to enable the feature:

https://www.eevblog.com/forum/chat/forum-update-new-ignore-topics-feature/msg651768/#msg651768

[rsjsouza]

Perhaps I am blind but I really do miss the possibility to hide/ignore certain thread from the unread posts ...

You have to enable the feature:

https://www.eevblog.com/forum/chat/forum-update-new-ignore-topics-feature/msg651768/#msg651768

Thanks a bunch for this! I have been meaning to ignore several threads for a while.

[miguelvp]

At least they didn't include control characters in the infamous string. You know the 0-31 values that include things like AKC.

If a serial protocol is not robust enough then any cross talk on the wire will be more dangerous than the canned string FTDI decided to use.

I don't even think they use carriage return or line feed for that matter.

As for using an USB-UART cable when you are on a bind, how do you know it even has the FTDI chip? I guess you can research it, but if it's the only one available on the store, will you forgo and just delay the diagnosis?

"What if" someone open a putty terminal and pasted some random things to the serial port? You'll think whoever designed the protocol would not just talk to a plain port without verifying the system talking to the device is using  the right format and protocol.