FTDI Driver Breaks Hardware Again (eevblog.com) 268
janoc writes: It seems that the infamous FTDI driver that got famous by intentionally bricking counterfeit chips [NOTE: that driver was later removed] has got a new update that injects garbage data ('NON GENUINE DEVICE FOUND!') into the serial data. This was apparently going on for a while, but only now is the driver being pushed as an automatic update through Windows Update, thus many more people stand to be affected by this.
Let's hope that nobody dies in an industrial accident when a tech connects their cheap USB-to-serial cable to a piece of machinery and the controller misinterprets the garbage data.
Let's hope that nobody dies in an industrial accident when a tech connects their cheap USB-to-serial cable to a piece of machinery and the controller misinterprets the garbage data.
First PoNON GENUINE DEVICE FOUND (Score:5, Funny)
...
FTDI is malware (Score:5, Informative)
FTDI is malware.
Use Linux.
use MCP2221.
Re: (Score:3)
this is why all the arduinos (nanos and other shield style boards) are moving away from ftdi and onto ch340, pl2303 (not great) or other usb/serial chips.
ch340 has been fine for me, so far. no driver problems, and so far not caring about fakes vs real ones (if there is such a thing for ch340).
ftdi can go fuck themselves. I think I need to send more notices to my corp (who does arduino stuff; at least in some groups) and we should stop patronizing ftdi.
Keeping me happy for disabling auto-updates (Score:4, Insightful)
I think I'll keep my Windows computers with updates disabled, as all the updates have been detrimental to the user, lately.
Checking the eevblog thread, though [eevblog.com] it seems it affects Windows 10, which I also elected not to touch.
Re:Keeping me happy for disabling auto-updates (Score:5, Informative)
I don't know why this is happening to USB to Serial drivers, of all things, because even worse shit happens with Prolific chipsets. Prolific did a hardware refresh and then instantly obsoleted all of the previous generation chips. Otherwise not a problem, except if you use Windows 8 or newer then the fucking driver they issue causes a code 10 hardware. If you use an older on 8 or newer then they work fine, but stupid Windows Update keeps replacing it with the bad driver unless you use a bit of ini file hackery.
What makes this worse than the FTDI situation is that Prolific is doing it to their own hardware to force you to buy a new one.
Re: (Score:2)
What makes this worse than the FTDI situation is that Prolific is doing it to their own hardware to force you to buy a new one.
So this is not a problem on win7? because I am having problems with a pl2303
Re: Keeping me happy for disabling auto-updates (Score:2)
No open source driver available? All these problems are easily solved if you can just handle your own devices.
Re: Keeping me happy for disabling auto-updates (Score:2)
Plus the prolific drivers suck and are generally buggy. I only use ftdi on Windows.
Re: (Score:2)
I do know i have ftdi chip in my mega board and few other devices
How can you be sure?
Re: (Score:3)
It's best to avoid custom drivers for USB to serial adapters. There is a standard for them called CDC. All major operating systems support it, including Windows and Linux.
The reason that FTDI and the like provide a custom driver, apart from to screw users, is that the Windows driver has a few flaws. The only big one is that it doesn't handle disconnection. Apparently Windows 10 fixes it.
Use the genetic OS driver for CDC. Don't get screwed by the manufacturer.
Re: (Score:3)
it's possible the driver actually choose to cause BSOD, there's no way to know.
Stop there and don't pretend to be providing analysis. That is very knowable. Not knowing is no excuse to pretend it is not knowable, and that people just have to wave their hands and guess.
People don't care if their hardware is genuine, they care if they use a thing with that brand on the label, is it likely to work or not. They expect the vendor to punish the people counterfeiting, if they can, not the end user who correctly read the label. It is their own nose they cut.
Re: (Score:2)
Re:Keeping me happy for disabling auto-updates (Score:5, Informative)
So, your problem may well be that you have a counterfeit "Prolific" chip that Prolific's driver no longer plays nice with.
No, that's not the problem at all. You can read yourself from Prolific's website:
http://www.prolific.com.tw/US/... [prolific.com.tw]
Note on that page how they no longer support "EOL chipsets" even though they work fine in windows 8 and 10 if you simply use an older driver that doesn't care about what OS version you have. If you use a newer one though, the driver throws a code 10 error so it won't work, unless of course, it detects a non-EOL chipset.
Re: Keeping me happy for disabling auto-updates (Score:2)
Leave it to a hardware manufactured to make their system unsecurable. Designing it with a little processor and shipping them with a cryptographic key would have probably cost less than the amount of money they are losing to counterfeits. Hindsight is 20/20.
Re: (Score:2)
I have had multiple issues with drivers from Windows Update on Windows XP and 7. If the device was working already and there was an update it was about a 50/50 chance the new driver would cause issues and have to be rolled back.
Re: (Score:2, Interesting)
Potentially compromised and working or not working.
Damned if you do, damned if you don't.
Supply chains (Score:5, Insightful)
Thanks to the reality of supply chains, companies intending to buy the real deal can accidentally buy the knockoffs. Anyone willing to do this(or their previous actions, like bricking devices) is someone I intend to never purchase from, real deal or not.
There are now plenty of competitors to FTDI. Don't buy FTDI- even if you think you're buying the real deal, reality can intervene.
Re: (Score:2)
There are now plenty of competitors to FTDI. Don't buy FTDI- even if you think you're buying the real deal, reality can intervene.
So who makes a serial interface chip even half as good as FTDI's? That's the only reason there even are knockoffs — it's the chip everyone wants.
Re:Supply chains (Score:5, Informative)
MCP2221, CH340G, etc. Just see:
http://www.eevblog.com/forum/r... [eevblog.com]
Re: (Score:2)
I skimmed a bit of that link and it seems that a number of those interfaces are disappointments. The question is whether any of them were as good as the FTDI chip, not whether other serial interfaces exist.
Re: (Score:3)
Tested them all. The only USB to serial devices that worked flawlessly are FTDI based adapters and some from Tripp-Lite (USA-19HS). The advantage of FTDI devices is they work without additional drivers on Linux and MacOS. And unlike the Tripp-Lite adapters, they work with MacOS hosted virtual machines. For some reason the Tripp-Lite driver can not switch between host and client operating systems when hosted by MacOS.
The FTDI devices are by far the easiest devices to get working and support. Send sup
Re: (Score:2)
It's a serial interface. Just how fucking "good" does it need to be?
Well, it has to work, and a lot of them don't. They have weird timing issues, DTR doesn't work right, there are all kinds of problems with most of the cheap serial interfaces. As it turns out, a lot of hardware that works great when attached to a real classic UART will have communications errors when talking to a cheap USB to serial interface.
Re: Supply chains (Score:5, Interesting)
The problem I've found with a LOT of USB things even the FTDI ones is that they're only putting out a stepped up 12V or even just 5V while classically the serial port was a bit above 12V.
Although the spec allows for +3V/-3V at the lowest end, most stuff just won't work well. Also the stepped up voltages seem to have a lot of noise and variation, again something the spec allows but "back in the day" few allowed for those.
Also, the USB data bus frequency leaks noise into the serial bus portion, sometimes visibly on a scope or definitely noticeable on a spectrum analyzer. The problem probably being poor design and shielding on modern computers. I've also had some issues with ground loops but that is only in very specific circumstances.
For critical applications, I've found the Ethernet serial servers are more reliable. Even running commands through an Arduino will do better in a pinch. But those cheap USB adapters are good enough for setting up a switch or uploading a firmware when the device is out of order anyway but are not intended to be permanently attached.
Re: (Score:2)
Sounds good, except that a lot of computers only put out 5V already.
Even just an RS-232 inline breakout debugger can drop the level too far for full speed communication between computers. If you're plugging into an external modem, then that side is full power but more importantly it can read down to 3V. The 5V computer RS-232 implementations rarely survive under 4.0V.
12V is plenty and I say that as somebody who has had this problem.
Arduinos have the same exact range of USB chips as the serial converters.
Re: (Score:2)
The FTDI chips don't put out 12V or 5V. Most serial chips rely on a chip like a MAX232 to bump up the voltage to +/- 12V. The MAX232 and derivatives do not need an external 12v supply.
CH340 works just FINE! (Score:4, Interesting)
The chip has now been replaced with the CH340 - which even though it lacks some of the FTDI features, is a bang up chip that gets the job done - even at really high Serial speeds, I've yet to see one of them fail on me (I use Linux, where CH340 runs right out of the box, windows needs a driver).
I've not even heard of the FTDI before all of this came up.
Re: (Score:2)
Well, that's good to hear. I have a CH340 coming which specifically fits nicely up with the ESP-01 programmer I've got without cables. (The -01 is fine for lighting projects, of which I currently have several...)
Re: (Score:3)
Re: (Score:2)
Not only are their competitors, but many of those competitors don't pay Microsoft to get their proprietary drivers included, and so you get generic USBSerial drivers. This is a huge advantage to the user, because no installation is required, and the drivers don't get updated over time, so shipped units will continue working.
FTDI wishes they were pushing me away from cheap knockoffs onto their brand, but they're pushing me away from their brand (because I have to buy through a regular supply chain, I can onl
Re:Supply chains (Score:5, Insightful)
And why is this the end-user's fault, again? Why do they feel that they need to cause it to malfunction or (in the case of a year ago), brick the device with an official driver from microsoft that gets pushed on the end user without them asking for it (or agreeing to their onerous T&C)?
Why punish the end user who doesn't even know what FTDI is or what a USB chipset even does for buying a product?
Re: (Score:3)
Re: (Score:2)
Well, a lawyer might help you if you're a distributor who bought enough units to make it worth suing FTDI for contract interference. :)
If it isn't their chip, they don't have the legal right to harm it. They could try to counter-sue you, but then they'd find out you're not responsible for their supply chain woes; you're only responsible for buying from a reputable reseller and doing related diligence. You sue them, they have to sue your supplier.
Re:Supply chains (Score:5, Interesting)
But you sure as fuck won't be sure you're getting ACTUAL FTDI components. FTDI WILL NOT GUARANTEE that a chip is real unless it is purchased directly from them. This includes chips purchased THROUGH THEIR DISTRIBUTORS.
They can't police their own fucking distributors, dude. Get a fucking grip.
Microsoft's responsibility and WHQL (Score:4, Interesting)
What is Microsoft's responsibility here?
They are pushing out drivers that bricks hardware through their Windows Update service?
How the hell did this pass their WHQL?
Re: Microsoft's responsibility and WHQL (Score:5, Insightful)
Yep, Microsoft should revoke WHQL on future driver versions and refuse to certify FTDI drivers in the future.
This is a blatant violation of trust; end users have no way to know if the FTDI chips in their devices are genuine.
Re: Microsoft's responsibility and WHQL (Score:4, Insightful)
Why do you expect this of all the things in Windows 10 to be in the interest of the end user? Why should this be the odd man out?
Re: (Score:2)
If it does what it should, why should I care who made it?
Re: Microsoft's responsibility and WHQL (Score:5, Interesting)
Yep, Microsoft should revoke WHQL on future driver versions and refuse to certify FTDI drivers in the future.
This is a blatant violation of trust; end users have no way to know if the FTDI chips in their devices are genuine.
This would be how I'd handle it.
1) After you login you see a message from windows. Automatic update of FTDI serial driver has failed. FTDI serial driver reports non genuine hardware. Warning the use of counterfeit hardware may cause system instability or other undesirable behaviour. Wouuld you like to disable the previous driver, or continue using it and mark it as non upgradeable? A non upgradeable driver may have bugs and other issues that could, in time, expose your system to threats. Long term use is not recommended.
Re: (Score:3)
In my opinion, this is worse. The previous driver corrupted the chip, but did not do anything else and the chip could be repaired in Linux. However, inserting fake data in the stream is much worse because of how the device might react to it, for example, if such a thing happened with a USB-to-serial converter connected to an APC UPS, it would cause the UPS to run battery calibration discharging the battery. This may not be that bad unless power failed soon after, but if the system is left unattended, the UP
Re:Microsoft's responsibility and WHQL (Score:4, Insightful)
Re: (Score:2)
Re:Microsoft's responsibility and WHQL (Score:5, Insightful)
If Whipslash is reading this - one thing that would be a REALLY interesting addition to Slashdot would be to go find someone from the company to speak to these issues, if possible. Something of an immediate Q&A to either clear up the news or confirm that the situation is as crummy as it appears.
I don't think that /. will every be able to work like that. Compare /. with Ars. Ars actually employs genuine technical minded journalists and produce long form stories of their own. When appropriate they do reach out to all parties to get comment from both sides. /. on th either hand is really just a news aggregator with a fancy commenting system. If anything it should be up to the producers of the original story to looking for comment.
Re: (Score:2)
This is widely done in media, and what you get as "replies" are press releases. Actually, your comment pretty much defines "press release." They rarely are going to "clear up the news," or attempt to.
Re: (Score:2)
MS should have plenty of incentive to publish their own FTDI driver that doesn't pull this crap. There are now a bunch of devices out there that work fine with Linux every time but not with Windows unless you screw around with the drivers.
Re: (Score:2)
FTDI can do whatever they think they can get away w
Re: (Score:2)
They have their own generic driver that works if you use an off-brand chip.
For manufacturers and makers the solution is obvious; don't choose FTDI because their own distributors sell counterfeit chips, or at least chips FTDI fails to recognize as genuine. Silicon Labs and Texas Instruments make better chips anyways.
Check the data sheet for your chip and make sure it uses the generic USB driver. Then it works in any new-ish OS, and on older ones with driver install.
Re:Microsoft's responsibility and WHQL (Score:5, Insightful)
I would imagine Windows Hardware Quality Labs tests the drivers against the hardware they are made to support. Requiring anyone to test real drivers against fake hardware would be a Gordian knot as new knockoff distributors appear and then fade away when someone starts trying to find them. I'm sure the same factory would produce the same knockoff and a "new" distributor would get it into the supply chains.
All that being said, I learned long ago not to let Windows update my hardware drivers, any hardware drivers. I just fixed one the other day where suddenly a favorite resolution on an LCD TV was missing. It took a bit to figure out the latest graphics driver (Intel via Windows update) installed a management program limiting display resolutions. Removed that program (and hid the update) and everything was back to normal.
Of course, in this case it would not matter where you got the update, if your device is counterfeit it gets tagged.
Re: (Score:2)
MS can't test against genuine hardware, because FTDI can't/won't check an existing chip to tell if it is "genuine," and don't guarantee chips as genuine even when purchased through their distributors. So a generic device that purports to have an FTDI chip can't be tested by MS. Nobody has any way of knowing is something is genuine unless they personally picked up the chips at FTDI's will call door and hand-shepherded them through the manufacturing process.
An OS vendor has to be able to walk into an office s
Re: (Score:2)
MS can't test against genuine hardware, because FTDI can't/won't check an existing chip to tell if it is "genuine," and don't guarantee chips as genuine even when purchased through their distributors...
Well, now all anyone has to do to check is apply this driver update and see what it does to the chip. I'm thinking it should be done while your supplier rep is in the room. You bought 10,000 off the internet from a no name site? Well, that's a learning opportunity... Someone should reverse engineer this driver and build a plug and play detector script or dongle. Personally, if I were making hardware and had to also do support for any counterfeits that would make me crazy.
Re: (Score:2)
Pure crap (Score:3)
Let's hope that nobody dies in an industrial accident when a tech connects their cheap USB-to-serial cable to a piece of machinery and the controller misinterprets the garbage data.
If a rogue USB to serial connector (on a windows box, with automatic updates no less) can endanger your workers, then your machinery wasn't safe in the first place.
Re:Pure crap (Score:5, Insightful)
Not necessarily true. Low-level technology like this is frequently the source of "cascading failure" that can endanger people or property.
For instance, we have many USB-to-Serial devices installed in chains that capture weight readings from industrial scales. If this suddenly and inobtrusively starts causing that measurement data to be misaligned in the output, those weight readings could be transmitted to shippers who may or may not re-weigh the product based on our volume. In the worst case scenario, something like this could be done as the last check-weight for loading an aircraft -- a weight-critical application where getting it wrong can cause a tail-strike on takeoff.
Screwing with low-level data INTENTIONALLY is never a good thing. End users have no way of ever knowing that it's happening. Pushing it by Windows Update, where no devs are involved to catch the error, is a recipe for potential disaster somewhere.
This IS Pure Crap... on the part of FTDI.
Re: (Score:2)
If this suddenly and inobtrusively starts causing that measurement data to be misaligned in the output, those weight readings could be transmitted to shippers who may or may not re-weigh the product based on our volume.
Except that the injected appears to be a pretty egregious change in the data stream and not subtle at all
In the worst case scenario, something like this could be done as the last check-weight for loading an aircraft -- a weight-critical application where getting it wrong can cause a tail-strike on takeoff. . . . Pushing it by Windows Update, where no devs are involved to catch the error, is a recipe for potential disaster somewhere.
As I also implied: Windows + auto updates does not equal safe operating conditions in the first place. Especially if you are talking about things like aircraft.
Do you have auto updates enabled on any of the machinery that you use USB to serial converters on? If not, why not?
Re: (Score:2)
Do you have auto updates enabled on any of the machinery that you use USB to serial converters on? If not, why not?
No, I don't... and that's because I'm not an idiot. ;)
Unfortunately, 20 years in this business have taught me that a significant share of people doing this kind of work are. Furthered by the fact that a significant share of business owners/managers (even in large companies) will shave costs anywhere they think they can get away with it.
My basic point is that "non critical" links in the infrastructure can still cascade into critical failures. Many of the developers/integrators in the chain never even recog
Re: (Score:2)
The desktop PC of a warehouse manager, a dumb throw-away "converter" PC that was simply stuck in a remote location to turn a serial device into a "network server", etc... People do ALL kinds of crap to engineer solutions for specific scenarios, often in small suppliers or companies too tiny to have good control processes or discipline.
Believe me I know this first hand as well and I do understand for point about cascading failures, as well as people doing weird things in factories. However if any one system such as this converter can cause a cascading failure to the point of injury or death, then you are already dealing with a house of cards full of safety vulnerabilities that you haven't accounted for. Your system isn't safe, its jus that you don't know it yet. With your experience you I expect that you know that safety isn't something
Re: (Score:2)
Sure, it's an unsafe system and that's irresponsible at best, possibly criminally negligent.
But knowing that is probably the case somewhere, it is also irresponsible at best to violate the principle of least astonishment and effectively fuzz a production system without warning.
If they would like to log a warning and then operate normally, I don't think anyone would object. Perhaps they would care to tell their customers how to spot the fakes? The only thing I have seen about that was the result of reverse e
Re: (Score:2)
All it takes for somebody to die in a factory is looking away for a second.
Factory equipment is rarely designed to be "safe," it is designed to be safe under certain controlled circumstances that typically can't be maintained during maintenance or malfunction.
A piece of equipment merely detecting the garbage data and going into safe mode could cause other equipment to spill a load that overflows onto somebody's head. Especially if the error is something that never would have happened in testing, because RS-
Re: (Score:3)
Low-level technology like this is frequently the source of "cascading failure" that can endanger people or property. For instance, we have many USB-to-Serial devices installed in chains that capture weight readings from industrial scales. If this suddenly and inobtrusively starts causing that measurement data to be misaligned in the output, those weight readings could be transmitted to shippers who may or may not re-weigh the product based on our volume. In the worst case scenario, something like this could be done as the last check-weight for loading an aircraft -- a weight-critical application where getting it wrong can cause a tail-strike on takeoff.
If a single USB-to-Serial mis-reading can cause a disaster, then disaster is coming. It's a matter of if, not when.
It might not be a malicious driver that causes disaster - it could be a programmer error, or a hardware fault.
If a design relies on a single point of failure, then the designer is at fault. End of story.
Re: (Score:2)
Heh... it's not that I disagree with you, philosophically. It's just that, where the rubber meets the road, a huge proportion of the applications and systems out there are not robustly designed.
It's very common for applications to expect either success or failure. Success implies that it's behaving correctly. Failure means anything went wrong. In many ways, FTDI's previous attempt at this -- bricking the devices -- was PREFERABLE to this, as it always resulted in failure. You can be angry that they kil
Re: (Score:2)
If a single USB-to-Serial mis-reading can cause a disaster, then disaster is coming. It's a matter of if, not when.
Such is the state of things in factories. When I was younger I worked in factories, and people do die at work. That does not imply that increasing the likelihood of disaster is harmless.
Re: (Score:2)
how many rs232 control protocols do you think use cryptographic authentication? can you name one?
What does that have to do with machine safety?
Re: (Score:3)
Nothing and the concept originally imputed as not being safe has nothing to do with machine safety either.
The control input on many industrial machines are rs232 or some other serial interface and it has been a standard for a long time. You use computers to directly control them in most cases and n some cases, it has the ability to store the commands and replay them. In either case, you have to connect directly to diagnose certain aspects. Whether this is getting the boards to do a self check or to manually
Re: (Score:2)
If an errant signal is sent, it could move the tool, start spinning the lathe or a host of other uncontrolled things unexpectedly . . . The unexpectedly part is the problem. If you expect something to not have power then all the sudden is does, you do not know you cannot treat it as if there is no power. If your tools are functioning properly, you know the state of the machines. It is not unsafe at all.
Working on live machinery is whole different kettle of fish and you acknowledge that there can be potential issues. As you are aware of the potential failure modes then you should have had safety protocols in place to cancel out or mitigate those modes. If you didn't have such protocols in place then your workplace is already inherently unsafe and the status of the errant signal is irrelevant.
Re: (Score:2)
Lol.. In a perfect world where we just put some carbon in a replicator and yell computer, create this, I guess you are 100% correct.
Of course there could be potential issues. Those issues just got compounded by a device driver possibly sending errant signals with no notice to the consumer. It would be like you changing a light socket and me coming in without your knowledge and flipping switches and breakers at random. Will you get shocked? Will you fall off the ladder and hurt yourself? Nobody knows but yo
Re: (Score:2)
The user of the equipment doesn't get to choose the safety protocols, and there is no guarantee that the first letters of FTDI's line noise isn't a command that moves equipment. Often, most bytes that you send translate to commands! This isn't like some sort of modern system with acknowledged messages; when a byte is ready it is read, and every 2 bytes or so is a command. Just feeding a sentence of English into an RS-232 control system will very often cause numerous events, not even just 1. If it is a facto
Re: (Score:2)
Which is why we have interlocks on things like that. If the machine doesn't have some physical means of being rendered safe, then it's not acceptable for t
Re: (Score:2)
More context needed in summary (Score:2)
No, related story needed (Score:2)
Related stories:
How's about it? Am I qualified to be a Slashdot editor? If hired, I promise to stop being an asshole all the time.
Re: (Score:2)
I believe that being an asshole all the time may be a requirement for the position.
Well, historically that has been true, but I was hoping for change. I know, I know, I must be new. I'm not holding my breath or anything, but hope is cheap.
Re: (Score:2)
Note that there is nothing wrong with copying a chip's functions to make a competing product. In this case they are using FTDI's USB ID so that they don't have to write their own driver. I haven't heard of any FTDI competitors offering to license the driver or pay for its development.
FTDI Serial Driver? (Score:2)
Why is an FTDI serial driver needed? USB has had a serial port protocol as part of its base spec and Windows has a default driver for things declaring themselves to be a serial port. I have several devices that work in this manner.
Why would a vendor of a basic USB-Serial port converter bother writing a driver?
Re:FTDI Serial Driver? (Score:5, Informative)
Why would a vendor of a basic USB-Serial port converter bother writing a driver?
Because the FTDI chip actually works. It's one of the very few USB to Serial chips that has proper timing and signals to make it work with marginal, antiquated hardware. A lot of people trying to use old automotive scan interfaces and the like which interface with serial have serious problems when using other chips.
I have literally never had a USB device outside of HID or mass storage which didn't need its own special snowflake driver, even though USB has driver profiles for several types of device.
Re: (Score:2)
These antisocial conservatroll memes are getting out of hand.
Yeah, sorry, I'm actually working to destroy that one through overuse. But seriously, even for devices which don't do anything special, there's often a special driver. It's annoying.
here's the safe driver for these chips (Score:5, Informative)
Here's the safe driver, in the form of source code so you could check it yourself if you want to.
http://lxr.free-electrons.com/... [free-electrons.com]
This driver does require a non-crap operating system, of course. Linux, FreeBSD, OpenBSD, etc probably OSX will work too.
ps: Not literally the same file for BSD, of course (Score:2)
Before some silly person jumps in, obviously that exact file is for Linux. The BSD versions are similar and also safe from the manufacturer's bullshit.
What? (Score:2)
> Let's hope that nobody dies in an industrial accident when a tech connects their cheap USB-to-serial cable to a piece of machinery and the controller misinterprets the garbage data.
Lets hope that no dumb idiot would connect anything critical to a "cheap USB-to-serial cable".
Re: (Score:2)
Or you might have to get your USB-Serial cable from the corporate approved list. This list being populated by beancounters rather than engineers.
Re: (Score:2)
Yes. And normally if something is that critical, you buy from a reliable source of original parts.
Re: (Score:3)
If you build something critical, you don't just replace a pat by another just because you may be a few days late.
In controlled areas (airospace, pharma, medical devices, automotice suppliers) replacing some part by something cheaper without the suppliers of the parts (in this case the driver) certifying that this change is ok will bring you directly to jail. In others, it could also happen that the court considers such a development method to be criminal, if somebody was killed.
Re: What? (Score:2)
No it won't bring anyone to jail. There are no laws concerning the sourcing of materials besides perhaps the Iranian/Cuban/Korean embargoes.
Sometimes you do source from someone "reliable" but somewhere along the chain (read: in China) someone will replace the original product with fakes or even the manufacturer factory will make a number of unauthorized devices.
Design specs typically don't even include such details as makes and model numbers as those can change at a moments notice even from the original man
Re: (Score:2)
http://www.mddionline.com/arti... [mddionline.com]
And yes: consulting change management for medical devices is one of the field which the department I work in does.
Re: (Score:2)
What's being talked about here is ordering THE SAME part from a different supplier.
No, what's being talked about here is ordering THE SAME part from any distributor.
Re: (Score:2)
You've now built a device with implicit trust between all of the components, and suddenly with a windows driver update, your device is now getting garbage data,
You seem to have a big problem with FTDI taking down your carefully crafted process because your trust of that company has been broken, yet you seem to have no issue with a applying random windows updates to your mission critical system without any form of testing. Strange that.
Re: (Score:2)
One thing you missed is that FTDI doesn't guarantee that chips bought through their official distributors are genuine. The official distributors are the ones substituting the chips that are either "counterfeit," or for whatever QA reason don't get properly detected by FTDI's driver.
There is no source of genuine chips other than FTDI's factory door. And what happens if you hire a shipping company to deliver them? Can you have FTDI check the chips to verify? Is there some official way of checking? No. There i
Going after the wrong people (Score:4, Insightful)
Why can't FTDI realise that this kind of behaviour is only going to hurt innocent end users, rather than the people responsible for peddling counterfeit devices? I've bought hundreds of these devices in the past from reputable suppliers, and in precisely zero cases can I determine whether the chipset is genuine or not before purchase. If I can't tell what I'm buying, then why am I being punished when I've bought in good faith? Why can't FTDI instead use existing mechanisms and laws to find the people responsible?
Of course Linux drivers for these devices work every time, counterfeit or not. Perhaps a different approach might be for someone to take the Linux code and create a decent open-source Windows driver to replace the buggy (i.e. injecting unwanted serial data) FTDI code?
Re: (Score:2)
Why can't FTDI realise that this kind of behaviour is only going to hurt innocent end users, rather than the people responsible for peddling counterfeit devices?
Why does the MPAA keep trying to come up with new encryption schemes for physical and electronic movie media when that kind of behavior is only going to hurt innocent end users?
I assume the answers to these two questions - as well as other related questions - involves the terms "decision-makers", "narcissistic", and "sociopaths".
Kernel-mode code signing in Windows (Score:2)
Perhaps a different approach might be for someone to take the Linux code and create a decent open-source Windows driver
"Open-source Windows driver" is a contradiction in terms.
Since Windows Vista 64-bit, Microsoft has placed a policy in Windows to require device drivers to be digitally signed with a kernel-mode code signing certificate from a commercial certificate authority. As of Windows 10, Microsoft has tightened this policy to require disclosure of the binary code of all drivers to Microsoft [msdn.com], and new drivers submitted since November 2015 must be signed with an Extended Validation (EV) certificate [msdn.com]. An EV certificate is
Re: (Score:2)
They do realize.
However, they are not a very successful electronics company. They have one (1) product that is wildly successful, and since they don't have better engineers than their competitors, they're not positioned to ensure they continue to control that niche in the future. In fact, Silicon Labs are already replacing FTDI as the preferred name-brand chip. Presumably that one is designed by Microchip. I prefer the Texas Instruments ones, because they come in more packages. (SL prefers modern non-hand-s
At this point, I think I'd avoid FTDI hardware... (Score:5, Interesting)
Re:At this point, I think I'd avoid FTDI hardware. (Score:4, Insightful)
Wait, you're actually surprised that Microsoft is okay with screwing users over something they already paid for?
Something is broken in that company (Score:2)
My guess is that they have cash-flow problems and they now think pissing-off potential customers is the way to go. You know, like the music and movie industries.
On the side of solid engineering practices, they can refuse to talk to that counterfeit device by not detecting it or giving an out-of-band error on detection, but that is it. Breaking the hardware intentionally is sabotage and exceptionally unethical. Being willing to work with the device but then injecting data into the data-stream intentionally i
How can FTDI not figure out how to do it? (Score:2)
Seriously, if FTDI wants to use their drivers to push out counterfeits, there's ways to do that without pissing off your customers or doing something possibly illegal.
How about, if your driver detects it's not actual hardware, you just refuse to work? Pop up a message saying "This is not FTDI hardware. This driver is not compatible with this hardware." If you want to be nice, give them a click-through that says "we have no idea what this hardware actually does. We cannot guarantee that using this driver wil
Re: (Score:2)
That then allows the user to complain to the equipment supplier with meaningful information, passing the issue back up the supply chain but also allows the end user to start the process of sourcing and installing working drivers.
The equipment supplier now alerted to the problem can now pay extra to use proper parts in future if they were know
Patent? (Score:2)
Are we talking about chips that are actually using unlicense patented technology, or just chips that have a compatible pinout and interface?
Re:Patent? (Score:4, Informative)
So, when Windows interrogates the device, it appears to be FTDI, so Windows loads the FTDI driver.
That driver makes an undocumented call that only genuine FTDI chips will respond to correctly, so the driver can tell whether a knockoff part is attached.
Other legit serial chip makers use their own PID/VID, so it's not an issue with TI, Silabs, etc., only with 'Best Lucky Interface Ltd' parts.
FTD Driver? (Score:4, Funny)
Those damned florists and their delivery vans!
I don't blame FTDI, fake chips hurt them (Score:5, Informative)
One problem these counterfeit chips pose is that all the sudden companies like FTDI end up with a lot of support costs for people who bought shoddy products with the fake chips, which often don't work nearly as well as the real thing. This is a way for FTDI to crack down on the counterfeit chips. While it sucks for the consumers that end up with the fake chips, it will also help put a stop to the counterfeit chips since any product that uses them will not work.
At my company we make a number of development boards using the quad FTDI chips for the serial interface. We use them because in addition to RS232 they also can talk I2C and JTAG, among other things. I can reliably run the FTDI chips at 10Mbps. I've used other USB to serial devices in the past but I've had lots of problems with them. Some cables I bought, for example, will just suddenly stop working and I have to periodically reset the baud rates.
Why should FTDI have to bear the burden and support costs of counterfeit chips? If somebody else slaps the FTDI manufacturer ID and product ID onto their USB device then they deserve whatever happens. Why should FTDI have to spend resources supporting fake chips? By doing what they are doing, it will drive the fake chips out of the system and prevent future ones.
I work for a chip manufacturer and while there's a very low risk that someone will make fake chips like ours (very complex network processors), we have had to add features to our chips so that our end customers can prevent counterfeit equipment which just copies their software. We have some large customers who have been battling Chinese made counterfeit equipment.
Re: (Score:3)
Just using a counterfeit chip could potentially introduce unintended behavior. I've dealt with a number of USB to serial chips and many of them are crap. I have cables that will just suddenly stop working, or the baudrates that suddenly change. I wouldn't be surprised if the counterfeit chips have similar problems. FTDI should be able to program their chip and expect it to work as designed. If it's counterfeit and it doesn't, then it's not their fault. They shouldn't have to debug problems in counterfeit ch
Re: (Score:2)
I doubt they'll fire the bot, worst thing for Timmy would probably be getting renamed.