Live data from Hacker News

FTDI driver kills fake FTDI FT232s

eevblog.com

11–20 of 315 posts

Re: FTDI driver kills fake FTDI FT232s

#11
I haven't gotten into the DIY/Hacker/Arduino stuff but it seems like there would also be plenty of consumer devices that may be impacted that don't have correct supply chain control (or care about the source of their chips).

I wonder if Windows will pull the driver.

Re: FTDI driver kills fake FTDI FT232s

#12
post #2

Ouch, something tells me the Arduino, Raspberry Pi, etc. forums are going to be full of people that are confused why they can't talk to their device anymore. IMHO it's pretty bad to target the consumers who probably don't even know or care that there's an FTDI chip in their device. Certainly am not condoning piracy of the chips, but wonder if there's a better way of handling the situation than breaking everyone.

Fortunately, most of the newer Arduinos have moved to firmware implementations of USB-to-serial that use one of the standard USB device classes and drivers, but there's all kinds of stuff out there with FTDI chips in.

Re: FTDI driver kills fake FTDI FT232s

#13
Me and my buddy were going to work on a couple of projects last weekend and got bit by this.

The workaround once your chip has been flashed by the new driver is modifying the driver to communicate with devices that have a PID of 0.

Re: FTDI driver kills fake FTDI FT232s

#14
post #8
post #4

Earlier quoted context omitted.

Wow. That is seriously uncool. I'd never even heard of FTDI before but they can rest assured that if I ever need a USB-to-UART chip that FTDI won't be the company I choose to buy. FTDI's drivers refusing to work with the fake parts is understandable, purposely reprogramming them to make them non-functional isn't.

> purposely reprogramming them to make them non-functional isn't Dumb question maybe, but why?

Because they're intentionally breaking your property. Sure it can be fixed, but it's the intent that's worrying.

Simply refusing to work - perhaps logging something to the event log about counterfeit products - would be fine.

Re: FTDI driver kills fake FTDI FT232s

#15
post #8
post #4

Earlier quoted context omitted.

Wow. That is seriously uncool. I'd never even heard of FTDI before but they can rest assured that if I ever need a USB-to-UART chip that FTDI won't be the company I choose to buy. FTDI's drivers refusing to work with the fake parts is understandable, purposely reprogramming them to make them non-functional isn't.

> purposely reprogramming them to make them non-functional isn't Dumb question maybe, but why?

You're damaging someone's hardware without their consent? Its essentially vandalism.

Re: FTDI driver kills fake FTDI FT232s

#17
post #7

FTDI have been anti-consumer for years - their last several drivers have introduced intentional instability and Code 10 errors for suspected counterfeit devices. I think this is totally crappy. I see what they're trying to do (create market incentive for consumers to insist on real FTDI chips) but the reality is that it's just screwing over innocent consumers who buy a device.

The FTDI OSX drivers will still randomly cause kernel panics when the device is unplugged and a program still holds an open file descriptor for the serial port. While working with a company which was developing and selling products with FTDI chips in them, we made FTDI aware of this issue and attached many panic logs.

It's been about 5 years and they've still yet to actually fix it.

Re: FTDI driver kills fake FTDI FT232s

#18
post #8
post #4

Earlier quoted context omitted.

Wow. That is seriously uncool. I'd never even heard of FTDI before but they can rest assured that if I ever need a USB-to-UART chip that FTDI won't be the company I choose to buy. FTDI's drivers refusing to work with the fake parts is understandable, purposely reprogramming them to make them non-functional isn't.

> purposely reprogramming them to make them non-functional isn't Dumb question maybe, but why?

I could sort of understand it if the driver refused to work and popped up some dialog that said "You're using a counterfeit FTDI device, here's how to get an official device. Sorry this driver is not compatible with unofficial devices." However if it just silently bricks the chip then consumers will have no idea what's wrong. They'll think their Arduino clone is broken or they can't talk to their Raspberry Pi for some reason. I doubt they'll make the connection that the FTDI chip in their device is a clone and understand what to do to fix it.

Re: FTDI driver kills fake FTDI FT232s

#19
I hope this causes a major and publicly visible malfunction in some important device/installation/machinery, of course with no harm done to any persons, but enough of an embarrasment to really set an example, so no vendor will think of pulling tricks like these in the future.

Takeaway lesson: End users should never touch anything remotely FTDI-like, since it's probably impossible to verify if the device is genuine or not. Wonder if FTDI thought this through.

Re: FTDI driver kills fake FTDI FT232s

#20
post #8
post #4

Earlier quoted context omitted.

Wow. That is seriously uncool. I'd never even heard of FTDI before but they can rest assured that if I ever need a USB-to-UART chip that FTDI won't be the company I choose to buy. FTDI's drivers refusing to work with the fake parts is understandable, purposely reprogramming them to make them non-functional isn't.

> purposely reprogramming them to make them non-functional isn't Dumb question maybe, but why?

In addition to the other posted replies, it's bad software engineering. You really can't be confident enough in your logic to ever start issuing DESTROY_HARDWARE() commands of any kind, short of the small set of very specialized programs that may be deliberately used for such things (FPGA programmers, etc). Any error whatsoever and you may end up nuking your real customer's hardware. Bad plan. Same reason why programs that think they are pirated shouldn't run around being actively destructive... some real customer will find some way to tickle that code, if only through bad hardware, and now you're in trouble.

To a first approximation, all code eventually runs. Relatedly, never put an error message into your product you wouldn't want customers to see, because they will.

Post reply on HN