I have seen some (safety related!) devices get upset when they receive data which they don't expect so yes: sending random data to a device can lead to damage, injuries and even death.

In that case the designer was incompetent. If a device can cause injuries or death, it should have at least some crc check over thecommunication channels, specially with rs232. Rs232 is well known for possible glitches on the line.Only incompetent engineers send plain and unprotected data via rs232 to a potential dangerous device.

Logged

The difference between theory and practice is less in theory thanthe difference between theory and practice in practice.Expensive tools cannot compensate for lack of experience.

Maybe it is. Maybe it won't actually cause a serious malfunction of a device ever.

What it does cause is damage to people that have nothing to do with it. And I mean really nothing. Like Intel and their Galileo board:https://communities.intel.com/thread/80586A user connected the board to its PC using a USB to serial converter and after some debugging he found the Galileo sending "NON GENUINE DEVICE FOUND!". He thought the Galileo was sending that. And that's fine, who would really consider that the Serial Converter might intentionally alter the data? That's like considering electrons falling out of your device if you hold it upside down...Even the guys at Intel thought there was something wrong with their Galileo board. They opened a support case for this guy to investigate further. Only this one case kept them busy for one month. And it was complete pointless debugging and burning several hours of Intel employees and the user for no reason. And, it would have been completely avoidable if FTDI did it right or even mention "FTDI USB to Srial Converter" in their f**** message.I'm pretty sure thousands of completely innocent developers have to waste lots of hours on debugging because of that...

In that case the designer was incompetent. If a device can cause injuries or death, it should have at least some crc check over thecommunication channels, specially with rs232. Rs232 is well known for possible glitches on the line.Only incompetent engineers send plain and unprotected data via rs232 to a potential dangerous device.

So... All G-Code compliant CNC machines were designed by idiots? G-Code, as far as I know, doesn't specify any type of CRC or error correction. But unexpected movements of CNC machines can be pretty dangerous... And G-Code is just an example here. There might be lots of use cases where you just have to use a given protocol and cannot add security mechanisms to it. That might be dangerous, right, but it's not incompetence!

Edit: With such a product you might be able to accept the risk of 0.001% chance for a corrupted byte being received. But FTDI now raises the chance of data corruption to 99.99% deliberately.

I have seen some (safety related!) devices get upset when they receive data which they don't expect so yes: sending random data to a device can lead to damage, injuries and even death.

In that case the designer was incompetent. If a device can cause injuries or death, it should have at least some crc check over thecommunication channels, specially with rs232. Rs232 is well known for possible glitches on the line.Only incompetent engineers send plain and unprotected data via rs232 to a potential dangerous device.

You are actually aware that CRC is more of a conveniance to avoid glitch than anything else, it's well known that CRC collisione are not only possibile, they are not all that uncommon the only way (for now) to use a hash check to secure a come channel is to use a cryptographic hash function, for example sha2 (there are no collisione found but they are thaught to be close) or more likely sha3

Now sha2 is not known for being resource friendly, try running it on an 8bitter, or even on a low end cm0 or cm0+

Sending random garbage over the channel is really never a good idea no matter how well the system is designed...

If you are writing a custom driver: Before writing a driver for your USB device, determine whether a Microsoft-provided driver meets the device requirements. If a Microsoft-provided driver is not available for the USB device class to which your device belongs, then consider using generic drivers, Winusb.sys or Usbccgp.sys. Write a driver only when necessary.

It might have prevented some funky features like the speed of the D2XX library or MPSSE but for most of the applications it would have worked a treat. Need SPI and JTAG simultaneously? Sure, why not, use the FT2232H. Just need the good 'ol 115200 8N1? Use <generic driver> with <generic usb serial adapter>. Imagine having to install a vendor driver for a mouse or keyboard before being able to use it.

If you are writing a custom driver: Before writing a driver for your USB device, determine whether a Microsoft-provided driver meets the device requirements. If a Microsoft-provided driver is not available for the USB device class to which your device belongs, then consider using generic drivers, Winusb.sys or Usbccgp.sys. Write a driver only when necessary.

It might have prevented some funky features like the speed of the D2XX library or MPSSE but for most of the applications it would have worked a treat. Need SPI and JTAG simultaneously? Sure, why not, use the FT2232H. Just need the good 'ol 115200 8N1? Use <generic driver> with <generic usb serial adapter>. Imagine having to install a vendor driver for a mouse or keyboard before being able to use it.

It was political; Intel/Microsoft didn't want lazy device manufacturers shipping all their devices with generic serial adapter drivers (eliminating the perceived benefits of USB plug&play) so they decided to not ship a standard driver (well sort of did eventually, but requiring the .inf config file). Can't find the source any more though...

You are actually aware that CRC is more of a conveniance to avoid glitch than anything else, ...

Yes, I am. It was just an example of how to make communication more robust.It's true that there's no 100% failsafe solution. But not using any protection because nothing is 100% secure, proves incompetency.You want to use your credit card online via an unencrypted channel? Please do, in the end, nothing is 100% secure... no?

Do you know how Google (and other companies) test and improve their software? By feeding it random data and see what happens.

I repeat my statement. Only incompetent engineers use rs232 in possibly dangerous devices without some protocol to check if the data is valid.

Logged

The difference between theory and practice is less in theory thanthe difference between theory and practice in practice.Expensive tools cannot compensate for lack of experience.

Surprise that you said this. Of course, it is speculation when you have no real body count to prove . Once you have one, it becomes a crisis when something not suppose to happen happens, and people started to ask where are all the planning, thinking, and were the engineers sleeping?

In that case the designer was incompetent. If a device can cause injuries or death, it should have at least some crc check over thecommunication channels, specially with rs232. Rs232 is well known for possible glitches on the line.Only incompetent engineers send plain and unprotected data via rs232 to a potential dangerous device.

So... All G-Code compliant CNC machines were designed by idiots?

Pretty much, yes. G-code was invented sometime last millenium, when CPUs were expensive, so there is some small excuse, but not for the past 30 years.

I've been working in comms and embedded for about 30 years, and anyone doing comms without a robust protocol is definitely incompetent. In a safety critical area, I would expect integrity checking on anything read from disk as well.

Unfortunately, incompetence is quite widespread in the software industry, many people I have worked with are little better than untrained amateurs. The management are usually even more clueless. So it does not surprise me at all.

If your safety critical device fails due to the FTDI data, it was never properly designed or tested, and should never have been certified safe.

Pretty much, yes. G-code was invented sometime last millenium, when CPUs were expensive, so there is some small excuse, but not for the past 30 years.[...]If your safety critical device fails due to the FTDI data, it was never properly designed or tested, and should never have been certified safe.

Okay. So nevertheless, you agree that there actually are lots of devices out there, designed by idiots, that may fail in not the best way if they receive garbage. Right?

I have seen some (safety related!) devices get upset when they receive data which they don't expect so yes: sending random data to a device can lead to damage, injuries and even death.

In that case the designer was incompetent. If a device can cause injuries or death, it should have at least some crc check over the

It is not only about a CRC check but also about buffer overflows. I totally agree about the incompetent designer remark but the fact is those kind of designers are out there and put their software in products which are on the market. We don't live in an ideal world so it is better to be cautious and not send random data to a device.

« Last Edit: February 02, 2016, 11:08:16 pm by nctnico »

Logged

There are small lies, big lies and then there is what is on the screen of your oscilloscope.

I'm not a Windows expert, but I believe those are translation/textual string resources used for the system event log. Messages are logged by code, so there wouldn't be a direct xref there, instead that's a table that maps codes to strings and something inside Windows itself does the mapping - so yeah, they can't use sprintf, this is Windows' dumb design I think? (someone with more Windows knowledge might be able to correct me here). I did find the logging code earlier, and what triggers it, but didn't check if it is indeed logged on my windows box. I just did and yeah, it's there:

The windows event log takes a few fixed parameters, to make sorting/filtering easier, and then a raw string.Apart from a list of standard error codes on the fixed fields you can put whatever you want into the raw section, which is assumed to be human readable text.

The linux drivers are not made by FTDI. They are made by the linux community. That's why they've never had any issues with bricking clones, and will even undo the bricking done by the FTDI drivers.

... and I assume most of the frustration is rooted in the fact that Microsoft never managed to provide a generic USB-Serial device driver.

Starting with Windows 10 you don't need a custom driver or INF file anymore. Still required for Windows 8.1 and older, see here. Maybe in 10 more years, USB will be fully plug-and-play, as promised 20 years ago

I have seen some (safety related!) devices get upset when they receive data which they don't expect so yes: sending random data to a device can lead to damage, injuries and even death.

In that case the designer was incompetent. If a device can cause injuries or death, it should have at least some crc check over the

It is not only about a CRC check but also about buffer overflows. I totally agree about the incompetent designer remark but the fact is those kind of designers are out there and put their software in products which are on the market. We don't live in an ideal world so it is better to be cautious and not send random data to a device.

(EDIT: I forgot to mention that i agree with nctnico. I am rather ranting about the silly implied notion permeating this thread that with this updated FTDI driver a machine like a CNC would become unsafe, and not using this particular FTDI driver would make the same machine safe again. Without stating this explicitly, my somewhat coffein-induced rant might be seen as in disagreement with nctnico, which it is not. I hope )

Look, there is no new kind of dangerous situation posed to CNC machines or their operators.Since their inception, CNC machines had to be designed with safety-relevant problem scenarios in mind. These include, but are not limited to the machine receiving improper parameters exceeding its operating envelope, or plain data garbage. The scenario of a (FTDI) driver sending nonsensical data to the CNC machine is just another flavor of that old scenario.

If a CNC machine cannot deal with such a problem scenario, then it has been designed by idiots. That doesn't mean that i think such machines don't exist. I tend to agree with you that this is not an ideal world. Unscrupulous people/entities are able to peddle their questionable products/services as long as it is dirt-cheap (which nicely leads back to bargain-price counterfeit chips )

Of course, not all improper parameters sent to a CNC machine do exceed its operating envelope. Improper parameters could simply be such that damage/destroy the workpiece or even damage/destroy the tool bit. Obviously, one can imagine a scenario where malevolent software sends the wrong parameters to the machine. But equally, one can imagine a scenario where wrong parameters would be send to the machine simply due to operator error or a bug/glitch in some software module. In terms of safety, there is really no new problem scenario introduced by some FTDI driver sending some bad/garbage data.

With regard to danger to health and life, any CNC machine should have appropriate safety in place. A housing or curtain to protect against flying bits and pieces, guard fences, safety mats, etc... Someone (person/entity) who operates a CNC which is missing critical safety systems (appropriate to the "size" of the machine) is a reckless idiot and there really is no reason or excuse to shift the blame on to a malfunctioning or misbehaving PC (in the broadest sense, including the software and drivers running on it, and also including a communications channel which cannot ensure data integrity by itself) if somebody gets injured...

In my opinion the view that FTDI's driver behavior creates a new safety risk to health and life is quite some hyperbole.

I mean, let's assume for a moment that you have such a machine which reacts allergic and kills everyone in the room if it receives incorrect data.What if you have a com bridge chip which is not from FTDI in your machine?What if that chip and the related driver work properly and do not (willfully or accidentally) produce garbage data?What if the firmware in the machine, or the software running on the controlling PC occasionally produces buggy, glitchy, wrong data that is being sent properly to the machine?What if there are bit-flips occurring during transfer of data from the PC to the machine, which are not detected via parity bit?What if the PC crashes or dies mid-transmission?Will you sleep well in the knowledge that you don't have the abysmal FTDI driver running on the system, and thus health and life are not in danger?

Don't get me wrong. I am not an apologist, and i do not like what FTDI are doing. With regard to economic losses, i would completely understand someone who worries that the behavior of the FTDI driver could lead to unexpected and substantial losses when devices with undiscovered fake FTDI chips are involved in production. This is a by all means a valid and serious concern.

But i don't get why people think that FTDI's driver behavior suddenly creates a new safety hazard that has not been there before. It simply doesn't. It only can trigger a safety hazard that already exists outside of the FTDI driver and (fake) FTDI chip.. Shoot the messenger, i guess...

I also agree that the safety hazzard exists with or without the FTDI driver sending out garbage but still it is better to avoid triggering these safety hazzards. BTW it is not just CNC machines which could cause saftey issues! There are many other scenarios; think along the lines of -for example- a controller for a elevator which is prone to a buffer overflow when it receives bogus data on a diagnostics interface. A while ago a lady walked/fell into an elevator shaft because the doors opened while the elevator wasn't there.

Logged

There are small lies, big lies and then there is what is on the screen of your oscilloscope.

But i don't get why people think that FTDI's driver behavior suddenly creates a new safety hazard that has not been there before. It simply doesn't. It only can trigger a safety hazard that already exists outside of the FTDI driver and (fake) FTDI chip.. Shoot the messenger, i guess...

You're right, it doesn't. But it makes this safety hazard more likely.

Just imagine a device (created by an idiot) where a unknown symbol/command actually causes a malfunction. The chance that a faulty USB to Serial Converter might unintentionally generate a wrong Symbol or a wrong Symbol is read due to a glitch is still pretty low and stays the same throughout its lifetime. With connecting a fake FTDI to it, the chance of causing this device to malfunction actually rises to 100%.

If just 0.0001% of all devices are susceptible to such fault, it's still better if their chance to fail remains 0.001% each instead of 100%

But, don't get me wrong... The main reason I think FTDI does the wrong thing is not because I think they will actually break lots of devices. The main reason because I think it is the wrong way is because most of the users just will have trouble using their device, get frustrated and may never realize what really caused it to fail because there is just no end-user friendly notification...

I also agree that the safety hazzard exists with or without the FTDI driver sending out garbage but still it is better to avoid triggering these safety hazzards. BTW it is not just CNC machines which could cause saftey issues! There are many other scenarios; think along the lines of -for example- a controller for a elevator which is prone to a buffer overflow when it receives bogus data on a diagnostics interface. A while ago a lady walked/fell into an elevator shaft because the doors opened while the elevator wasn't there.

Of course, i fully agree to avoid possible trigger conditions. Just being curious about what kind of elevator was involved in that accident? Do you have information or a link i can follow? Usually, elevators should have electrical/mechanical door interlocks (operating independently from the elevator control) which prevent the door from opening when the car is not there (and prevent the car from moving again as long as the doors are open). It seems unusual to me that door interlocks would have a digital controller. Then again, i don't really know since i am not in the elevator business and i don't know what cutting-edge modern-day elevators are made of...

But i don't get why people think that FTDI's driver behavior suddenly creates a new safety hazard that has not been there before. It simply doesn't. It only can trigger a safety hazard that already exists outside of the FTDI driver and (fake) FTDI chip.. Shoot the messenger, i guess...

You're right, it doesn't. But it makes this safety hazard more likely.

I have to agree. Although it worries me a bit thinking about people/entities building, certifying or using safety-critical or safety risk-imposing devices without considering and testing about such possible problem scenarios...

Quote

But, don't get me wrong... The main reason I think FTDI does the wrong thing is not because I think they will actually break lots of devices. The main reason because I think it is the wrong way is because most of the users just will have trouble using their device, get frustrated and may never realize what really caused it to fail because there is just no end-user friendly notification...

I also agree that the safety hazzard exists with or without the FTDI driver sending out garbage but still it is better to avoid triggering these safety hazzards. BTW it is not just CNC machines which could cause saftey issues! There are many other scenarios; think along the lines of -for example- a controller for a elevator which is prone to a buffer overflow when it receives bogus data on a diagnostics interface. A while ago a lady walked/fell into an elevator shaft because the doors opened while the elevator wasn't there.

Of course, i fully agree to avoid possible trigger conditions. Just being curious about what kind of elevator was involved in that accident? Do you have information or a link i can follow?

If you search for 'woman falls in elevator shaft' you'll notice it -shockingly- happens very often! The case I was referring to happened in Germany.

Logged

There are small lies, big lies and then there is what is on the screen of your oscilloscope.

If you search for 'woman falls in elevator shaft' you'll notice it -shockingly- happens very often! The case I was referring to happened in Germany.

Certainly elevator doors fail sometimes, because door interlocks fail sometimes.But i am curious about that specific case you mentioned where a digital controller would be able to open the door although no car was there. I believe that a door interlock is wired directly to the respective elevator door operator (not the elevator controller) and does not rely on digital components (which would also mean that door interlocks would not offer a digital debug interface susceptible to buffer overflows). Either i am wrong in my belief, or the case you mentioned required the cooperation of a failed door interlock or personnel having the key to override/unlock the door interlocks. However, that's going off-topic and something where i can apply my Google-Fu to the usual suspects (Honeywell, Unitec, ThyssenKrupp, Otis, etc...) when i have some more idle time. Anyway, thanks for the feedback.

If you search for 'woman falls in elevator shaft' you'll notice it -shockingly- happens very often! The case I was referring to happened in Germany.

Certainly elevator doors fail sometimes, because door interlocks fail sometimes.But i am curious about that specific case you mentioned where a digital controller would be able to open the door although no car was there.

My example was just a purely hypothetical one extrapolated from my experience with how bad some firmware is written. I just can't divulge too much about those experiences for obvious reasons.

Logged

There are small lies, big lies and then there is what is on the screen of your oscilloscope.

My example was just a purely hypothetical one extrapolated from my experience with how bad some firmware is written. I just can't divulge too much about those experiences for obvious reasons.

And what if somebody plugged a laptop into a rocket on the launchpad to run some diagnostics, and this bogus message caused it to ignite and kill everyone in the vicinity!!! Boycott FTDI!!!

Would we all please stop with these nonsense hypotheticals and discuss the actual facts? So far there is zero proof that there are any counterfeit devices in legitimate supply chains anymore. All we have are a handful of people buying known Chinese knockoff products on eBay/Ali, big woop. Also, if any product could kill somebody because it received the wrong byte over a UART line when plugged into a Windows computer, it was a shit product and was going to kill somebody at some point anyway. Sure you'd be better off not trying to trigger a problem, but you'd also be better off not using a cheap Chinese knockoff converter to run the interface in the first place. These ridiculous hypothetical scenarios don't help either side of the discussion.