All Propeller ASC+ boards currently in stock at Parallax and at my online store use FT231X chips bought directly from Digi-Key. Some of the earliest ASC's used FT232RL chips from a China supplier. If anyone has this issue pop up with their boards, please contact me for a replacement.
I think most agree that cloners relying on FTDI drivers to pull the heavy load is unethical. I don't think that's in debate.
There is some discussion going on (in other forums) regarding the illegality of "borrowing" another company's identification code, for the purpose of making your product appear to be identical ***from a machine standpoint***. Traditionally copyright has been often used to protect drivers and firmware from being reproduced, or from a counterfeit interacting with another product. This is how HP, Canon, and other printer manufacturers can restrict the use of non-genuine toners and inks, for example. But a unique PID/VID is not copyrightable -- it passes no tests for copyrightability. It cannot be trademarked, because it is not used in commerce to identify a product among buyers. So other than the ethics, this brings into question FTDI's legal standing in altering another company's product by effectivelty erasing a numeric value that is not by itself protectable by law.
Trademark and passing off laws rely on humans being mislead as to the origin of a product. If a counterfeit chip is printed with an FTDI logo, that's clear infringement. If the chip is otherwise sold as something else, but it identifies itself to another software layer as FTDI by way of a numeric identifier, that is not intended to fool the buying consumer. So it doesn't necessarily follow that such a process is counterfeiting. The USB org may disallow unauthorized reuse of PIDs/VIDs, but that's not the same as federal or international law.
Again, we're talking legalities, not ethics.
The result is FTDI finding itself in untested legal waters, especially as it regards to rendering end-user hardware non-functional without adequate prior warning. In fact, from a legal (not ethical or moral) standpoint, I'd say it's just about as close to corporate suicide as you can get. That said, the quote from Microsoft made clear it was *FTDI* that removed the updated drivers from the Windows Update channel, perhaps showing they are reconsidering their approach. Let's hope so.
This scandal is huge. Over on the EEVBlog the debate is already 36 pages long !
Over there is a user named "FTDI Chip", who may or may not be really anything to do with FTDI but in his first post he firmly puts the blame for this problem on his customers:
When the FTDI driver is installed you are agreeing the terms of use of FTDI`s device. Please note that FTDI`s driver licence agreement will be broken if used with counterfeit devices.
I think you should find hard evidence that FTDI have done this deliberately before condemning them.
As far as I can see there isn't any.
Consider this, the new driver kills fake chips by pure coincidence, who then are you going to be blaming?
.
Actually, you ,might want to read Roy Eltham's explanation from someone on eevblog forums, how HOW this disables the clone, before playing the 'pure coincidence' card...
Quite clearly, a driver that CHANGES to a Programmer, does not do so 'by magical accident', and they method it uses, is not 'accidental code'.
A couple of ironies are already present.
a) There are already a couple of work-arounds, (that use FTDI's own tools - ouch).
b) The attack method used can be remedied in a clone ( and I imagine will be quickly ).
If FTDI had been a little less 'blunt hammer' in this, they could have better long term outcomes.
The FTDI VID/PID can be changed with a tool, and anyone making their own drivers does so already. They won't be affected by this problem even if they have pirate chips.
There has been a similar case already...
Remember the Palm Pre?
That pretended to be an iPod so that it could sync seamlessly with iTunes...
Apple only rewrote iTunes to detect it and block it, though.
But there, too you had a 'my Palm worked, now it doesn't' situation.
Palm did this to get 'easy access' to the music, without care of what could happen if a FW update for the impersonated iPod was sent out, or frankly lots of other 'not disclosed' functions that exist in the synch function.
Palm and their supporters were yammering about being 'shut out'...
But... the iTunes library isn't the same as iTunes the player, or even iTMS the music store. The iTunes library is completely open. Anyone can get the docs for the xml structure that the database consists of, and the files themselves are just that... files... Just drag and drop!
If I bothered, and knew a bit more about xml, I could probably create a OS/2 REXX script that pulls my favorite playlist from the networked HDD my itunes library is on, and then run the files through a REXX-enabled music player... (That same stunt should then also work on Amigas... )
Apple made certain everyone KNEW what they were doing and why...
FTDI is ****** because Pirated chips not only causes them losses, but any time they glitch, it's FTDI who gets the blame.
If they just rewrote their driver to not work with pirated chips, people would just say that the new driver it glitchy and go back to the old one.
(Drivers have very few ways of 'communicating' with the user. It could put a message in the system log, but how many reads that?)
Now they're 'taking back' their property (PID/VID) and letting everyone know why.
They have the tools to remedy the problem for those with serious issues(FTDI's tools to change PID + older drivers), so no system is permanently 'bricked'.
Yes, it will cause problems, lots of problems...
But hopefully, this will lead to fewer pirate chips on the market.
FTDI is owning that VID and remove it from things not produced by them.
What is wrong with that?
Plenty. I seriously doubt that there is such concept as owning a number in any legal system in the world.
They are not destroying any hardware.
Most certainly they are.
If the many reports I have read are to be believed then my Serial/USB dongle can me made unusable by plugging it into a Windows computer that has this new driver installed. That is destruction.
Yes, I know, people with the know how can reprogram the VIDs and PIDs and recover the situation. That does not mean it is not destruction.
Given that they have knowingly done this then it is illegal in many jurisdictions.
They just de-badge it. Ripping of the label stating it is a FTDI product. Because it is not.
I think there are laws against one destroying other peoples property no matter if it's a fake of something or not. That is taking the law into their own hands. Not good.
Name it morals and values if you need a label for it.
I find these morals of yours a little bit disturbing.
coley
I think you should find hard evidence that FTDI have done this deliberately before condemning them.
Ok, for years the picaxe group have known there has been a problem with the fakes. They never work reliably, and in the end the solution was "FTDI chipset" eg a post from my good mate Stan over in NZ http://www.picaxe.orconhosting.net.nz/USB_D9.jpg
There have been similar problems on the Propeller - timing of the reset pulse in particular.
I don't condone the faking of other peoples products. But I'm rather hoping FTDI gets killed off. Or at least shaken up a bit.
Here goes my reasoning:
This sorry saga highlights why I always thought USB was a disgusting idea.
We don't actually want USB, or an FTDI chip or their stupid driver or a USB/serial dongle.
No, what we wanted was a UART. A simple, humble frikken UART. About the oldest and simplest means of electrical signalling possible. Dating back to the telegraph and teletype. A device that pretty much anyone here can knock up with TTL chips or program into their COGs.
What did we get? Well someone (Intel?) decided it would be a great idea to subsume a whole bunch of different peripheral interfaces into a single standard. That standard would provide for serial communication, parallel ports, mice, keyboards, block device storage etc etc etc.
OK, nice idea. Except we end up with a mess. we need USB host devices, USB slave devices. We need hubs and their power supplies. We need a ton of driver software.
The complexity multiplies. Just recall how many forum posts here and else where have been related to USB/serial hardware and drivers.
Now, this perhaps might not even be so bad if USB/Serial dongles were built to the USB standard for serial devices. The USB communications device class or CDC.
Oh no. That would be too easy. Better make our own proprietary system that requires our special driver software. Thank you FTDI. (And others I believe).
Why on Earth can't I run a simple UART device from software that comes built into the USB protocol stacks of operating systems for that purpose?
As it stands now a USB serial adapter is pretty much nothing but a tiny micro-controller and some firmware. There are many firms out there who can and do make them. FTDI's only way to exist in this space is to use that stupid driver as the gateway.
I would hope to see that one day there are many suppliers of USB/serial devices all conforming to a common standard and using a common driver. Thus getting away from the kind of problems that companies like FTDI cause.
USB was an attempt to copy Apple's ADB, a system that actually worked...
The reason why we need drivers is that we don't HAVE physical access to the device any more. Not only isn't any longer 'on board', but it shares the same interrupt and all that with lots of other USB-devices.
And since you need a SW layer inbetween, why should anyone bother specify a standard for the chip's control registers and such?
(No, the CDC definition doesn't really specify all that)
As long as the triver has an interface that meshes with the OS, that's of no interest.
It's called Hardware Abstraction, and it's the price we pay to be able to mix and match parts.
FTDI is owning that VID and remove it from things not produced by them.
What is wrong with that?
They are not destroying any hardware. They just de-badge it. Ripping of the label stating it is a FTDI product. Because it is not.
Mike
If FTDI's software can identify the fakes, I don't see why denying service is a less than adequate solution. It would seem that would render the device useless without invasive modification.
This just sets a precedent for turning your hardware purchased in good faith into junk without any dialogue or recourse. Big companies tend to provide use with all sorts of fine print about which we are required to accept without any real ablitity to evaluate what all the implications are.
A few years ago, I purchased a Seagate USB harddrive specifically to back up Linux data. Nothing on the outside of the box indicated it was NOT an actual purchase, but a device that was licensed to be used ONLY with Windows and Apple systems. It wasn't until the user booted up the hard drive that an HTML explained the hard drive was licensed to me, not sold to me. And I was to never ever remove the Windows/Apple applications included.
So I was stuck.. either return the hard disk or reformate in LInux and await punishment from Seagate. I reformated as I felt I purchased the device without prior notification of all these fantastic legal stipulations. I will NEVER by Seagate again.
I am sure FTDI has looked into this and thought that they were perfectly within their rights to remove their Id number. That may be all quite legal. But the resentments created by not allowing the end-user some warning will remain for a very long time. There are lots of people that have no idea who FTDI is or what a driver is that just will get the message that FTDI turned something that should work into junk.
I don't condone the faking of other peoples products. But I'm rather hoping FTDI gets killed off. Or at least shaken up a bit.
Here goes my reasoning:
This sorry saga highlights why I always thought USB was a disgusting idea.
We don't actually want USB, or an FTDI chip or their stupid driver or a USB/serial dongle.
No, what we wanted was a UART. A simple, humble frikken UART. About the oldest and simplest means of electrical signalling possible. Dating back to the telegraph and teletype. A device that pretty much anyone here can knock up with TTL chips or program into their COGs.
What did we get? Well someone (Intel?) decided it would be a great idea to subsume a whole bunch of different peripheral interfaces into a single standard. That standard would provide for serial communication, parallel ports, mice, keyboards, block device storage etc etc etc.
OK, nice idea. Except we end up with a mess. we need USB host devices, USB slave devices. We need hubs and their power supplies. We need a ton of driver software.
The complexity multiplies. Just recall how many forum posts here and else where have been related to USB/serial hardware and drivers.
Now, this perhaps might not even be so bad if USB/Serial dongles were built to the USB standard for serial devices. The USB communications device class or CDC.
Oh no. That would be too easy. Better make our own proprietary system that requires our special driver software. Thank you FTDI. (And others I believe).
Why on Earth can't I run a simple UART device from software that comes built into the USB protocol stacks of operating systems for that purpose?
As it stands now a USB serial adapter is pretty much nothing but a tiny micro-controller and some firmware. There are many firms out there who can and do make them. FTDI's only way to exist in this space is to use that stupid driver as the gateway.
I would hope to see that one day there are many suppliers of USB/serial devices all conforming to a common standard and using a common driver. Thus getting away from the kind of problems that companies like FTDI cause.
The reason why we need drivers is that we don't HAVE physical access to the device any more.
I don't follow you.
Sure the USB/Serial chip may well be on the end of a USB cable. So what? There is a protocol defined to move data between PC and dongle over USB. There are device drivers at the PC end that create virtual COM ports for your apps to use.
That protocol is standardized, the CDC. Therefore one would hope than any dongle that conforms to the USB CDC spec would be seen by the same driver in the OS on the PC. A built in part of the OS. Not a special driver hacked up for a particular dongle and supplied by an untrustworthy vendor like FTDI.
(No, the CDC definition doesn't really specify all that)
My, admittedly sketchy, understanding of the CDC is that it caters for pretty much everything we normally do with UARTS around here.
This kind of abstraction should not really be working down at the level of bits and bytes of some particular chips registers.
It's called Hardware Abstraction, and it's the price we pay to be able to mix and match parts.
Yes, it's called a Hardware Abstraction. So how come these USB serial devices don't all conform to that abstraction we have defined for them?
We are paying the price and not getting the benefit.
Heater said
I don't condone the faking of other peoples products. But I'm rather hoping FTDI gets killed off. Or at least shaken up a bit.
Here goes my reasoning:
<snip>
Stone the bloody crows, he's right!
Well, my post all made sense, at least to me, and said the opposite of what heater said. And then heater goes and takes the logic further, and he is right. It is a mess. And I agree. In the olden days I had a RS232 port on my computer and I could control stuff with it, and I did, including a sprinkler system that watered my garden from an old CP/M computer for over ten years. And then they (Microsoft/Windows) said RS232 was old-skool and tried to get rid of it, repeatedly, in programming languages like whatever the official Basic was at the time, and repeatedly, people complained because they wanted to control stuff, so they put it back in as a .dll and it got more and more complicated. And then PCs didn't come with RS232 ports, and they called that "progress" and instead they gave you a USB port and said it was "universal". And you had to buy a special chip to convert that USB back to good old RS232 and then you had to install endless updates, and then they charged too much so then we had fakes, and then the updates tried to kill the fakes, and they called that "progress".
Well, time to fight back!
I have in front of me my Propeller to Four RS232 ports board which arrived today. I shall use them to replicate a simple BBS piece of software to control routing of old-skool RS232 signals. And then I will connect them with nifty RS232 radio modules, and log into to clever FPGA CP/M emulations with RS232 ports, and control pumps and other stuff with Arduinos talking RS232. And finally, because I have to, somewhere in that network will be a USB to RS232 dongle with a FTDI chip so it can link to the Internet. But just one chip in all that network, because I am fighting back!!
Here's a challenge. A software based USB hub or slave running in a cog on a Propeller (or PFGA emulation), with driver software available from Parallax. Bypass the whole FTDI thing
Yes, it's called a Hardware Abstraction. So how come these USB serial devices don't all conform to that abstraction we have defined for them?
We are paying the price and not getting the benefit.
But we ARE getting the benefit...
For any USER PROGRAM, an USB-rs232 adapter looks identical to an oldfashioned rs232-port embedded on the motherboard.
That is what Hardware abstraction is all about. Giving every device of the same type a uniform interface.
USB communications device class (or USB CDC) is a composite Universal Serial Bus device class. The class may include more than one interface, such as a custom control interface, data interface, audio, or mass storage related interfaces.
I can't quite work out whether it's USB, FTDI or even both that you don't like ;-)
It's probably Intel. They created this catastrophe and pushed it onto the world.
Perhaps I just don't like computers at all. Which is a shame because you can do a lot with a computer, computer science is interesting and programming can be fun.
Seems to me that we are always piling more and more complexity up into an unfathomable heap.
Sure computers and computing is complex by it's very nature. And sure as we want more and more capability we will get more and more complex systems.
But I always get a sneaking suspicion that a lot of the complexity we end up with is not actually necessary.
The USB specs are one such case.
@Dr_A
Stone the bloody crows, he's right!
Wow, must be the first time for a while around here:)
Thanks.
Here's a challenge. A software based USB hub or slave running in a cog on a Propeller...
Yes, what happened to the USB on a Propeller projects people were working with a few years back?
Hopefully the P2 can do this a lot more easily and effectively.
I think an interesting question is "who is making these fakes, and why?"
The margin on such a small chip hardly makes it worth counterfeiting for profit.
Let me put my tin foil hat on and ask, "is a government behind this?"
A fake USB interface chip with some extra logic would be an interesting way to infect SCADA devices around the world. FTDI chips are used in all sorts of places where new computers need to connect to old hardware, like SCADA and control systems. USB injection of malware is, after all, how Stuxnet was started, and more recently new USB-injected malware made an appearance:
So on one hand, I think FTDI bricking devices is a boneheaded, Sony rootkit like, move. On the other, maybe they are breaking things that need to be broken and replaced?
For any USER PROGRAM, an USB-rs232 adapter looks identical to an oldfashioned rs232-port embedded on the motherboard.
That is what Hardware abstraction is all about. Giving every device of the same type a uniform interface.
Yes of course. I agree.
But in the case of USB the Hardware Abstraction already exists on the protocol going over the USB cable. The CDC.
Ergo, it should not be necessary to have more than one driver in the OS that implements the CDC abstraction for serial devices over USB. As there is only one and it is standardized it would be supplied as part of the OS.
As far as I'm concerned the fact that you need separate drivers for different manufacturers serial dongles means that those dongles are broken implementations of the abstraction.
To quote the fountain of wisdom...
Ah, we are both consulting the same fountains of wisdom. And coming to different conclusions:)
CDC is NOT the same as rs232...
I would hope not. The CDC is a communications protocol specification. RS232 is a hardware specification.
Now, what do you find missing from the CDC when it comes to exchanging data with a serial device and controlling it's parameters and operation?
Or, what does the FTDI driver offer that the CDC does not?
Microsoft's hostility to plain serial extends to that hardware-abstracted API. Due to problems with the plugin about a decade ago I figured out how to control the serial ports directly from VB6.
First you need two pages of constant and function declarations.
Next, to open the serial port -- a job that takes one line of code in every other environment I've ever used -- you need to dimension four typed variables and make SIX API calls, each of which must be set up with a variety of those declared constants and which might return several errors, also as declared constants.
Finally, to do it "right" you need to start a thread to collect incoming data, which of course is impossible in VB6. However, I found that the 32 (and later 64) bit versions of Windows will cache incoming data for you. The technique doesn't work on Windows 98 or in Wine.
Lately I've been building Propeller boxes which communicate via Ethernet UDP via ENC28J60 and bridge to peripherals such as serial ports. These work a lot better than USB to serial adapters, they can be multi-function, I have full control if I need to change their behavior, and they work on all operating systems including in emulation.
A fake USB interface chip with some extra logic would be an interesting way to infect SCADA devices around the world.
Oh yes. That is another giant can of worms.
It's not just USB serial dongles that can present such a risk.
Pretty much every device on your computer has a controller in it that could potentially be used for purposes of sniffing on or controlling your machine. We can also worry about network adapters, WIFI chips, the controllers in your hard drive and so on and so on. These all pose security threats.
There are reasons why some people are fanatical about opensource software. And that includes what is going on in all those little devices.
Yes, what happened to the USB on a Propeller projects people were working with a few years back?
Hopefully the P2 can do this a lot more easily and effectively.
Yes, that would be nice.
...and to be a legal USB device running on a P2, you still need a valid VID/PID which you can PURCHASE from another vendor or from usb.org *OR* you can become a usb.org member which appears to cost a bunch of money.
So bottom line, it is a Universal standard that is a benefit to the user/consumer but if you want to use it from the producer side you need to pay to play. Of course you can just pass those VID/PID licensing fees back to your consumer.
If you don't want to pay for a VID/PID, you can just "borrow" one from somebody else and then pay the price when your borrowing is discovered.
In one of these threads there was a statement about the ownership of a number. While it's true you can't own a number, you can "own" a number in a given context. I don't own 425-98-6319 but when used in context as my Social Security Number, I "own" all the rights, privileges and liabilities associated with that number sequence when used as a Social Security Number. Anyone else using that number sequence in that context is breaking the law and committing identity theft and subject to whatever punishment that legal punishment that entails.
$DEAD_BEEF is just a number sequence too but if my VID/PID as assigned by usb.org to identify my company and one of my devices, then in this context, I own $DEAD_BEEF. Anyone else using that as a VID/PID (especially using $DEAD as a VID) is stealing my identity as a company in the USB world. They shouldn't be doing this and should be stopped and punished.
Now, is what FTDI right? It sounds like they just took back their VID/PID which left the device inoperable since that is the key to recognizing a USB device. It isn't their device and shouldn't have their VID/PID so they are just removing it. A reasonable action on the surface. The problem lies in where and how these USB devices are being used which is where the FTDI action becomes irresponsible.
heater, you mean like how open source kept the world safe from heartbleed? or how open source found the ShellShock bug after being in the bash code for 20+ years?
If you think open source is the solution to security you are way off. Maybe it helps, or maybe the source being open enables exploit. I'm sure there were people using Shellshock for years before a whitehat disclosed it. There is no way to definitively say that open source is any more secure.
I am fully aware of all the components in a PC, I'm only asking here, why this $1 part is being counterfeited, when it is relatively low volume, but specifically used in high value targets like SCADA. If you were going to build counterfeit parts for profit it seems like memory or some other high volume, easy to slip in the manufacturing stream part would make more sense.
If you think open source is the solution to security you are way off.
I don't. There are no silver bullets here. I do however think it's a jolly good start.
There is no way to definitively say that open source is any more secure.
You are quite right to point out that all software has bugs. In the code, in the design, in the very concept sometimes. Security holes are the result of such bugs.
Further, it's pretty much impossible to conclusively prove that any non-trivial piece of code will perform as expected or desired in all possible situations.
However it seems obvious to me that actually having the possibility for people to look at the source is a far better situation than not.
Comments
There is some discussion going on (in other forums) regarding the illegality of "borrowing" another company's identification code, for the purpose of making your product appear to be identical ***from a machine standpoint***. Traditionally copyright has been often used to protect drivers and firmware from being reproduced, or from a counterfeit interacting with another product. This is how HP, Canon, and other printer manufacturers can restrict the use of non-genuine toners and inks, for example. But a unique PID/VID is not copyrightable -- it passes no tests for copyrightability. It cannot be trademarked, because it is not used in commerce to identify a product among buyers. So other than the ethics, this brings into question FTDI's legal standing in altering another company's product by effectivelty erasing a numeric value that is not by itself protectable by law.
Trademark and passing off laws rely on humans being mislead as to the origin of a product. If a counterfeit chip is printed with an FTDI logo, that's clear infringement. If the chip is otherwise sold as something else, but it identifies itself to another software layer as FTDI by way of a numeric identifier, that is not intended to fool the buying consumer. So it doesn't necessarily follow that such a process is counterfeiting. The USB org may disallow unauthorized reuse of PIDs/VIDs, but that's not the same as federal or international law.
Again, we're talking legalities, not ethics.
The result is FTDI finding itself in untested legal waters, especially as it regards to rendering end-user hardware non-functional without adequate prior warning. In fact, from a legal (not ethical or moral) standpoint, I'd say it's just about as close to corporate suicide as you can get. That said, the quote from Microsoft made clear it was *FTDI* that removed the updated drivers from the Windows Update channel, perhaps showing they are reconsidering their approach. Let's hope so.
Over there is a user named "FTDI Chip", who may or may not be really anything to do with FTDI but in his first post he firmly puts the blame for this problem on his customers:
That's nice. I'm the bad guy when their driver breaks my system. I really don't want to buy anything from them any more.
[url]
http://www.eevblog.com/forum/reviews/ftdi-driver-kills-fake-ftdi-ft232/msg534653/#msg534653
[/url]
I'm just settling down with a nice cup of tea to read what kind of hammering that guy gets over there:)
I think you should find hard evidence that FTDI have done this deliberately before condemning them.
As far as I can see there isn't any.
Consider this, the new driver kills fake chips by pure coincidence, who then are you going to be blaming?
rod1963 says it best...
Actually, you ,might want to read Roy Eltham's explanation from someone on eevblog forums, how HOW this disables the clone, before playing the 'pure coincidence' card...
Quite clearly, a driver that CHANGES to a Programmer, does not do so 'by magical accident', and they method it uses, is not 'accidental code'.
"I felt a great disturbance in the Force. As if millions of unknowningly fake @FTDIchip's suddenly cried out in terror...and were silenced."
If the product is genuine does the same thing happen?
a) There are already a couple of work-arounds, (that use FTDI's own tools - ouch).
b) The attack method used can be remedied in a clone ( and I imagine will be quickly ).
If FTDI had been a little less 'blunt hammer' in this, they could have better long term outcomes.
The FTDI VID/PID can be changed with a tool, and anyone making their own drivers does so already. They won't be affected by this problem even if they have pirate chips.
There has been a similar case already...
Remember the Palm Pre?
That pretended to be an iPod so that it could sync seamlessly with iTunes...
Apple only rewrote iTunes to detect it and block it, though.
But there, too you had a 'my Palm worked, now it doesn't' situation.
Palm did this to get 'easy access' to the music, without care of what could happen if a FW update for the impersonated iPod was sent out, or frankly lots of other 'not disclosed' functions that exist in the synch function.
Palm and their supporters were yammering about being 'shut out'...
But... the iTunes library isn't the same as iTunes the player, or even iTMS the music store. The iTunes library is completely open. Anyone can get the docs for the xml structure that the database consists of, and the files themselves are just that... files... Just drag and drop!
If I bothered, and knew a bit more about xml, I could probably create a OS/2 REXX script that pulls my favorite playlist from the networked HDD my itunes library is on, and then run the files through a REXX-enabled music player... (That same stunt should then also work on Amigas... )
Apple made certain everyone KNEW what they were doing and why...
FTDI is ****** because Pirated chips not only causes them losses, but any time they glitch, it's FTDI who gets the blame.
If they just rewrote their driver to not work with pirated chips, people would just say that the new driver it glitchy and go back to the old one.
(Drivers have very few ways of 'communicating' with the user. It could put a message in the system log, but how many reads that?)
Now they're 'taking back' their property (PID/VID) and letting everyone know why.
They have the tools to remedy the problem for those with serious issues(FTDI's tools to change PID + older drivers), so no system is permanently 'bricked'.
Yes, it will cause problems, lots of problems...
But hopefully, this will lead to fewer pirate chips on the market.
If the many reports I have read are to be believed then my Serial/USB dongle can me made unusable by plugging it into a Windows computer that has this new driver installed. That is destruction.
Yes, I know, people with the know how can reprogram the VIDs and PIDs and recover the situation. That does not mean it is not destruction.
Given that they have knowingly done this then it is illegal in many jurisdictions. I think there are laws against one destroying other peoples property no matter if it's a fake of something or not. That is taking the law into their own hands. Not good. I find these morals of yours a little bit disturbing.
coley There certainly is a lot of evidence. See here: [uel]http://www.eevblog.com/forum/reviews/ftdi-driver-kills-fake-ftdi-ft232/[/url]
Ok, for years the picaxe group have known there has been a problem with the fakes. They never work reliably, and in the end the solution was "FTDI chipset" eg a post from my good mate Stan over in NZ http://www.picaxe.orconhosting.net.nz/USB_D9.jpg
There have been similar problems on the Propeller - timing of the reset pulse in particular.
And then earlier this year, it looks like some boffins actually found what the fakes are http://hackaday.com/2014/02/19/ft232rl-real-or-fake/
and what they look like http://zeptobars.ru/en/read/FTDI-FT232RL-real-vs-fake-supereal
'bout time the fakes got killed off, I say!
http://www.eevblog.com/forum/reviews/ftdi-driver-kills-fake-ftdi-ft232/msg535270/#msg535270
Here goes my reasoning:
This sorry saga highlights why I always thought USB was a disgusting idea.
We don't actually want USB, or an FTDI chip or their stupid driver or a USB/serial dongle.
No, what we wanted was a UART. A simple, humble frikken UART. About the oldest and simplest means of electrical signalling possible. Dating back to the telegraph and teletype. A device that pretty much anyone here can knock up with TTL chips or program into their COGs.
What did we get? Well someone (Intel?) decided it would be a great idea to subsume a whole bunch of different peripheral interfaces into a single standard. That standard would provide for serial communication, parallel ports, mice, keyboards, block device storage etc etc etc.
OK, nice idea. Except we end up with a mess. we need USB host devices, USB slave devices. We need hubs and their power supplies. We need a ton of driver software.
The complexity multiplies. Just recall how many forum posts here and else where have been related to USB/serial hardware and drivers.
Now, this perhaps might not even be so bad if USB/Serial dongles were built to the USB standard for serial devices. The USB communications device class or CDC.
Oh no. That would be too easy. Better make our own proprietary system that requires our special driver software. Thank you FTDI. (And others I believe).
Why on Earth can't I run a simple UART device from software that comes built into the USB protocol stacks of operating systems for that purpose?
As it stands now a USB serial adapter is pretty much nothing but a tiny micro-controller and some firmware. There are many firms out there who can and do make them. FTDI's only way to exist in this space is to use that stupid driver as the gateway.
I would hope to see that one day there are many suppliers of USB/serial devices all conforming to a common standard and using a common driver. Thus getting away from the kind of problems that companies like FTDI cause.
If I desire reliable asynchronous serial, I skip USB entirely and use RS422/485 in Linux.
The reason why we need drivers is that we don't HAVE physical access to the device any more. Not only isn't any longer 'on board', but it shares the same interrupt and all that with lots of other USB-devices.
And since you need a SW layer inbetween, why should anyone bother specify a standard for the chip's control registers and such?
(No, the CDC definition doesn't really specify all that)
As long as the triver has an interface that meshes with the OS, that's of no interest.
It's called Hardware Abstraction, and it's the price we pay to be able to mix and match parts.
If FTDI's software can identify the fakes, I don't see why denying service is a less than adequate solution. It would seem that would render the device useless without invasive modification.
This just sets a precedent for turning your hardware purchased in good faith into junk without any dialogue or recourse. Big companies tend to provide use with all sorts of fine print about which we are required to accept without any real ablitity to evaluate what all the implications are.
A few years ago, I purchased a Seagate USB harddrive specifically to back up Linux data. Nothing on the outside of the box indicated it was NOT an actual purchase, but a device that was licensed to be used ONLY with Windows and Apple systems. It wasn't until the user booted up the hard drive that an HTML explained the hard drive was licensed to me, not sold to me. And I was to never ever remove the Windows/Apple applications included.
So I was stuck.. either return the hard disk or reformate in LInux and await punishment from Seagate. I reformated as I felt I purchased the device without prior notification of all these fantastic legal stipulations. I will NEVER by Seagate again.
I am sure FTDI has looked into this and thought that they were perfectly within their rights to remove their Id number. That may be all quite legal. But the resentments created by not allowing the end-user some warning will remain for a very long time. There are lots of people that have no idea who FTDI is or what a driver is that just will get the message that FTDI turned something that should work into junk.
At least FTDI don't BSOD your OS like the Prolific ones used to if it detected a fake, that's far worse than bricking a fake device IMO.
Sure the USB/Serial chip may well be on the end of a USB cable. So what? There is a protocol defined to move data between PC and dongle over USB. There are device drivers at the PC end that create virtual COM ports for your apps to use.
That protocol is standardized, the CDC. Therefore one would hope than any dongle that conforms to the USB CDC spec would be seen by the same driver in the OS on the PC. A built in part of the OS. Not a special driver hacked up for a particular dongle and supplied by an untrustworthy vendor like FTDI. My, admittedly sketchy, understanding of the CDC is that it caters for pretty much everything we normally do with UARTS around here.
This kind of abstraction should not really be working down at the level of bits and bytes of some particular chips registers. Yes, it's called a Hardware Abstraction. So how come these USB serial devices don't all conform to that abstraction we have defined for them?
We are paying the price and not getting the benefit.
I don't condone the faking of other peoples products. But I'm rather hoping FTDI gets killed off. Or at least shaken up a bit.
Here goes my reasoning:
<snip>
Stone the bloody crows, he's right!
Well, my post all made sense, at least to me, and said the opposite of what heater said. And then heater goes and takes the logic further, and he is right. It is a mess. And I agree. In the olden days I had a RS232 port on my computer and I could control stuff with it, and I did, including a sprinkler system that watered my garden from an old CP/M computer for over ten years. And then they (Microsoft/Windows) said RS232 was old-skool and tried to get rid of it, repeatedly, in programming languages like whatever the official Basic was at the time, and repeatedly, people complained because they wanted to control stuff, so they put it back in as a .dll and it got more and more complicated. And then PCs didn't come with RS232 ports, and they called that "progress" and instead they gave you a USB port and said it was "universal". And you had to buy a special chip to convert that USB back to good old RS232 and then you had to install endless updates, and then they charged too much so then we had fakes, and then the updates tried to kill the fakes, and they called that "progress".
Well, time to fight back!
I have in front of me my Propeller to Four RS232 ports board which arrived today. I shall use them to replicate a simple BBS piece of software to control routing of old-skool RS232 signals. And then I will connect them with nifty RS232 radio modules, and log into to clever FPGA CP/M emulations with RS232 ports, and control pumps and other stuff with Arduinos talking RS232. And finally, because I have to, somewhere in that network will be a USB to RS232 dongle with a FTDI chip so it can link to the Internet. But just one chip in all that network, because I am fighting back!!
Here's a challenge. A software based USB hub or slave running in a cog on a Propeller (or PFGA emulation), with driver software available from Parallax. Bypass the whole FTDI thing
But we ARE getting the benefit...
For any USER PROGRAM, an USB-rs232 adapter looks identical to an oldfashioned rs232-port embedded on the motherboard.
That is what Hardware abstraction is all about. Giving every device of the same type a uniform interface.
To quote the fountain of wisdom
( http://en.wikipedia.org/wiki/USB_communications_device_class )
CDC is NOT the same as rs232...
Perhaps I just don't like computers at all. Which is a shame because you can do a lot with a computer, computer science is interesting and programming can be fun.
Seems to me that we are always piling more and more complexity up into an unfathomable heap.
Sure computers and computing is complex by it's very nature. And sure as we want more and more capability we will get more and more complex systems.
But I always get a sneaking suspicion that a lot of the complexity we end up with is not actually necessary.
The USB specs are one such case.
@Dr_A Wow, must be the first time for a while around here:)
Thanks.
Yes, what happened to the USB on a Propeller projects people were working with a few years back?
Hopefully the P2 can do this a lot more easily and effectively.
The margin on such a small chip hardly makes it worth counterfeiting for profit.
Let me put my tin foil hat on and ask, "is a government behind this?"
A fake USB interface chip with some extra logic would be an interesting way to infect SCADA devices around the world. FTDI chips are used in all sorts of places where new computers need to connect to old hardware, like SCADA and control systems. USB injection of malware is, after all, how Stuxnet was started, and more recently new USB-injected malware made an appearance:
http://gizmodo.com/the-only-fix-for-that-terrible-usb-malware-requires-req-1643428652
So on one hand, I think FTDI bricking devices is a boneheaded, Sony rootkit like, move. On the other, maybe they are breaking things that need to be broken and replaced?
But in the case of USB the Hardware Abstraction already exists on the protocol going over the USB cable. The CDC.
Ergo, it should not be necessary to have more than one driver in the OS that implements the CDC abstraction for serial devices over USB. As there is only one and it is standardized it would be supplied as part of the OS.
As far as I'm concerned the fact that you need separate drivers for different manufacturers serial dongles means that those dongles are broken implementations of the abstraction. Ah, we are both consulting the same fountains of wisdom. And coming to different conclusions:) I would hope not. The CDC is a communications protocol specification. RS232 is a hardware specification.
Now, what do you find missing from the CDC when it comes to exchanging data with a serial device and controlling it's parameters and operation?
Or, what does the FTDI driver offer that the CDC does not?
First you need two pages of constant and function declarations.
Next, to open the serial port -- a job that takes one line of code in every other environment I've ever used -- you need to dimension four typed variables and make SIX API calls, each of which must be set up with a variety of those declared constants and which might return several errors, also as declared constants.
Finally, to do it "right" you need to start a thread to collect incoming data, which of course is impossible in VB6. However, I found that the 32 (and later 64) bit versions of Windows will cache incoming data for you. The technique doesn't work on Windows 98 or in Wine.
Lately I've been building Propeller boxes which communicate via Ethernet UDP via ENC28J60 and bridge to peripherals such as serial ports. These work a lot better than USB to serial adapters, they can be multi-function, I have full control if I need to change their behavior, and they work on all operating systems including in emulation.
It's not just USB serial dongles that can present such a risk.
Pretty much every device on your computer has a controller in it that could potentially be used for purposes of sniffing on or controlling your machine. We can also worry about network adapters, WIFI chips, the controllers in your hard drive and so on and so on. These all pose security threats.
There are reasons why some people are fanatical about opensource software. And that includes what is going on in all those little devices.
Yes, that would be nice.
...and to be a legal USB device running on a P2, you still need a valid VID/PID which you can PURCHASE from another vendor or from usb.org *OR* you can become a usb.org member which appears to cost a bunch of money.
So bottom line, it is a Universal standard that is a benefit to the user/consumer but if you want to use it from the producer side you need to pay to play. Of course you can just pass those VID/PID licensing fees back to your consumer.
If you don't want to pay for a VID/PID, you can just "borrow" one from somebody else and then pay the price when your borrowing is discovered.
In one of these threads there was a statement about the ownership of a number. While it's true you can't own a number, you can "own" a number in a given context. I don't own 425-98-6319 but when used in context as my Social Security Number, I "own" all the rights, privileges and liabilities associated with that number sequence when used as a Social Security Number. Anyone else using that number sequence in that context is breaking the law and committing identity theft and subject to whatever punishment that legal punishment that entails.
$DEAD_BEEF is just a number sequence too but if my VID/PID as assigned by usb.org to identify my company and one of my devices, then in this context, I own $DEAD_BEEF. Anyone else using that as a VID/PID (especially using $DEAD as a VID) is stealing my identity as a company in the USB world. They shouldn't be doing this and should be stopped and punished.
Now, is what FTDI right? It sounds like they just took back their VID/PID which left the device inoperable since that is the key to recognizing a USB device. It isn't their device and shouldn't have their VID/PID so they are just removing it. A reasonable action on the surface. The problem lies in where and how these USB devices are being used which is where the FTDI action becomes irresponsible.
If you think open source is the solution to security you are way off. Maybe it helps, or maybe the source being open enables exploit. I'm sure there were people using Shellshock for years before a whitehat disclosed it. There is no way to definitively say that open source is any more secure.
I am fully aware of all the components in a PC, I'm only asking here, why this $1 part is being counterfeited, when it is relatively low volume, but specifically used in high value targets like SCADA. If you were going to build counterfeit parts for profit it seems like memory or some other high volume, easy to slip in the manufacturing stream part would make more sense.
Further, it's pretty much impossible to conclusively prove that any non-trivial piece of code will perform as expected or desired in all possible situations.
However it seems obvious to me that actually having the possibility for people to look at the source is a far better situation than not.
Why would it not be so?