A local cache isn't really going to do much good if they actually want them to not work with their software (old/new) as HDCP can do. There is no local cache in HDCP once the revocation is updated it sticks and removing it isn't possible (probably is). The PID change effectively does the same thing.
Something like Error 43, Windows has stopped this device because it has reported problems.
Or not sure if FTDI can call this error but Error 48, The software for this device has been blocked from starting because it is known to have problems with Windows. Contact the hardware vendor for a new driver. (That is probably an avenue to block older driver versions)
Goodwill and trust takes years to build up and one mistake to tear down in an instant.
But in any case I think higher levels of integration are more a threat to FTDI you can get micro's with built in USB support, Ethernet, RF, ... and the market moves fast and getting the entire thing on one SoC is quite appealing. I'm looking into getting our 1st year boards down to a single chip solution and I'm pretty sure if spent the time it would be easy to build what we need as most of our stuff is old designs passed down from years ago.
Bottom line is FTDI screwed up their response, started a massive burn goodwill bonfire, and I think is still stoking it. (Regardless of if they are allowed to do it or not) I think that is something that is very clear.
Seriously is probably going to be a good example of failed PR I should recommend it to APSC prof that does a course on that kind of stuff (Business case studies)
A local cache isn't really going to do much good if they actually want them to not work with their software (old/new) as HDCP can do. There is no local cache in HDCP once the revocation is updated it sticks and removing it isn't possible (probably is). The PID change effectively does the same thing.
A local cache would not help with past drivers, this is true, but I think that is something FTDI has to accept, and move forward. Innovate their chips, improve their IP, and add some sort of SHA based authentication into their chips at a bare minimum.
Changing the PID is not effectively the same, because it also kills legal clone interoperation with 3rd party drivers which would need to be updated on every BSD and Linux system. This is the big liability FTDI sees, and why the driver had to be pulled, and why FTDI is denying the PID change was intentional. Changing the PID also causes the clone to silently fail with old FTDI drivers, so again not a very good solution.
There is no best solution: one is more destructive and opens you to liability, the other is less destructive but will not prevent people from using older drivers. I thought I read in the previous posts that someone has changed the INF file on the older driver to accept PID 0000, which means people will be able to use a modified old driver anyway.Something like Error 43, Windows has stopped this device because it has reported problems.
Or not sure if FTDI can call this error but Error 48, The software for this device has been blocked from starting because it is known to have problems with Windows. Contact the hardware vendor for a new driver. (That is probably an avenue to block older driver versions)
Yes a proper error code, or a notification pop-up, would have to be a part of any solution, there we agree.
Goodwill and trust takes years to build up and one mistake to tear down in an instant.
But in any case I think higher levels of integration are more a threat to FTDI you can get micro's with built in USB support, Ethernet, RF, ... and the market moves fast and getting the entire thing on one SoC is quite appealing. I'm looking into getting our 1st year boards down to a single chip solution and I'm pretty sure if spent the time it would be easy to build what we need as most of our stuff is old designs passed down from years ago.
Bottom line is FTDI screwed up their response, started a massive burn goodwill bonfire, and I think is still stoking it. (Regardless of if they are allowed to do it or not) I think that is something that is very clear.
Seriously is probably going to be a good example of failed PR I should recommend it to APSC prof that does a course on that kind of stuff (Business case studies)
I think you hit the nail on the head, or even nailed it into FTDI's coffin. When I started using FTDI the AT90S8515 was still a mainstream part, ATMEGAs were just starting to come out from Atmel, although many were vapourware, and certainly none had integrated USB. That was over a decade ago, and now it's a different ballgame. About a decade ago I had the chance to use the LPC2146 when it first came out, and wrote both the firmware (with heavy help from app notes) and the windows side drivers (with heavy help of libusb). The chip was still fairly expensive back then, now you can get ARM Cortex-M3s with USB for less than an FT232.
Not only did FTDI screw-up their response, they did the wrong thing in the first place.
It does still work to stop working it would be impossible to talk to it or use it which if you can run the command at the bottom you certainly are using it.
>> It does still work to stop working it would be impossible to talk to it or use it which if you can run the command at the bottom you certainly are using it.
No. A device with a PID of 0 is not respecting USB specification.
The modification to PID 0 is in fact bricking the device. it's sheer luck that linux does not enforce PID !=0
Yeah, you can repair it to the previous state, but this needs effort, time and tools -> this costs to the user.
Anyway, a lot of the HW will be thrown awy, because the user does not know why it suddently fails ! That's bricking.
QuoteI've tested the install part myself windows does not complain about a bunch of PID 0000 strings
Wonder what are the chances they are going to go on a rampage and try to wipe out of existence their older drivers... (That would be futile but given how they have responded it wouldn't be surprising)
Legal clones shouldn't be using FTDI's VCP driver by default so they would have a different VID/CID to be very clean room style developed legal clones with their own VCP driver for proper interoperability. Which may or may not be so close or functionally identical to FTDI's interface that if you did change the VID/CID to match it would have worked with old FTDI drivers but devs have to test that themselves and they would in the new FTDI drivers realize it doesn't work properly and revert to using their proper clone VID/PID and tell users FTDI isn't being nice. FTDI probably sees more a giant backlash of the online community than legal issues including their continued poor handling of the situation.
(Bottom line is that the bad PR is more damaging than any legal case would likely ever be if ever)
QuoteQuoteI've tested the install part myself windows does not complain about a bunch of PID 0000 stringsYep, you kinda can repair it. But not on new versions of windows, which do not accept PID0.
And as i said, the repair of the FTDI damage costs the users and the serious device manufacturers, not the chinese clones and counterfeit chip makers, and not the cheap device manufacturers.
No. A device with a PID of 0 is not respecting USB specification.
The modification to PID 0 is in fact bricking the device. it's sheer luck that linux does not enforce PID !=0
Yeah, you can repair it to the previous state, but this needs effort, time and tools -> this costs to the user.
Anyway, a lot of the HW will be thrown awy, because the user does not know why it suddently fails ! That's bricking.
I don't have a fake device but FT_PROG and the such will reprogram it and detects them. You just have to modify the inf files first. I've tested the install part myself windows does not complain about a bunch of PID 0000 strings and the driver installs with a warning of modification.
Wonder what are the chances they are going to go on a rampage and try to wipe out of existence their older drivers... (That would be futile but given how they have responded it wouldn't be surprising)Yep, indeed very futile.Legal clones shouldn't be using FTDI's VCP driver by default so they would have a different VID/CID to be very clean room style developed legal clones with their own VCP driver for proper interoperability. Which may or may not be so close or functionally identical to FTDI's interface that if you did change the VID/CID to match it would have worked with old FTDI drivers but devs have to test that themselves and they would in the new FTDI drivers realize it doesn't work properly and revert to using their proper clone VID/PID and tell users FTDI isn't being nice. FTDI probably sees more a giant backlash of the online community than legal issues including their continued poor handling of the situation.
Really depends on if you consider VID/PID property of FTDI, which I do not. Several posts have discussed VID and PID ownership. Clones were using the VID/PID, however the clones did not contain any FTDI IP themselves, and if used with Linux or BSD are perfectly legal. If used with FTDI's Windows driver, they would be considered in violation of the EULA (if that's really worth the paper its written on) however two wrongs don't make a right, so I don't believe you can just wipe their PID, and in doing so prevent legitimate uses of the clones with 3rd party drivers. (yes new drivers can be written, but any old BSD or Linux drivers need modification)(Bottom line is that the bad PR is more damaging than any legal case would likely ever be if ever)Couldn't agree more, sad, but yes that will likely be the case.
I'll need to read up on HDCP, so I can't comment.
Speaking of which, does anyone know where to reliably get a fake chip, or a product with a fake chip? (I don't want to gamble and risk getting a genuine one for experiments. )
Would be fun to get the die out of those chips and inspect them under the SEM, see if there are any markings, just generally learn about the clones. Unfortunately I lost my SEM access when I left UBC.
No. A device with a PID of 0 is not respecting USB specification.
The modification to PID 0 is in fact bricking the device. it's sheer luck that linux does not enforce PID !=0
Yeah, you can repair it to the previous state, but this needs effort, time and tools -> this costs to the user.
Anyway, a lot of the HW will be thrown awy, because the user does not know why it suddently fails ! That's bricking.
I don't have a fake device but FT_PROG and the such will reprogram it and detects them. You just have to modify the inf files first. I've tested the install part myself windows does not complain about a bunch of PID 0000 strings and the driver installs with a warning of modification.I tried this too on a scrap device with an FTDI chip. I programmed the PID to 0000 but left the VID intact. The device first showed up as unknown in the device manager, but I could make the VCP driver into attaching to it using the update driver guide and selecting the driver manually, without even editing the INF file. This is with an older version of the VCP driver and in Windows 7 though. I'll get the scope out later and check the serial communication still works, but I would assume it does.
Would be interesting to find out if this method of coaxing the driver into attaching to the chip, even the older version, works with a fake chip with its PID set to 0000.
Speaking of which, does anyone know where to reliably get a fake chip, or a product with a fake chip? (I don't want to gamble and risk getting a genuine one for experiments. )
No. A device with a PID of 0 is not respecting USB specification.
The modification to PID 0 is in fact bricking the device. it's sheer luck that linux does not enforce PID !=0
I don't have a fake device but FT_PROG and the such will reprogram it and detects them. You just have to modify the inf files first. I've tested the install part myself windows does not complain about a bunch of PID 0000 strings and the driver installs with a warning of modification.
#include <linux/module.h> // included for all kernel modules
#include <linux/kernel.h> // included for KERN_INFO
#include <linux/init.h> // included for __init and __exit macros
#include <linux/errno.h>
#include <linux/slab.h>
#include <linux/tty.h>
#include <linux/tty_driver.h>
#include <linux/tty_flip.h>
#include <linux/module.h>
#include <linux/spinlock.h>
#include <asm/uaccess.h>
#include <linux/usb.h>
#include <linux/serial.h>
#include <linux/usb/serial.h>
/*
* * Version Information
* */
#define DRIVER_VERSION "v0.0.1"
#define DRIVER_AUTHOR "Eneuro"
#define DRIVER_DESC "A Simple walk around FTDI fake PID "
#define FTDI_VID 0x0403 /* FTDI vendor Id */
///#define FTDI_232RL_PID 0xFBFA /* FTDI 232RL PID 0xFBFA or 0x6001 */
#define FTDI_FAKE_PID 0x0 /* FTDI fake PID */
static int debug;
static __u16 vendor = FTDI_VID;
static __u16 product= FTDI_FAKE_PID;
static struct usb_device_id id_table [] = { { USB_DEVICE(FTDI_VID, FTDI_FAKE_PID) }, { }, };
MODULE_DEVICE_TABLE(usb, id_table);
static int __init ftdi_fake_init(void)
{
dbg("%s", __FUNCTION__);
if(vendor > 0 && product >= 0) {
printk(KERN_INFO "The key is to set to default product ID in Linux FTDI driver to 0x0 and add it to FTDI usb device id's table !!!" );
}
printk(KERN_INFO KBUILD_MODNAME ": " DRIVER_VERSION ": "
DRIVER_DESC "\n");
/* printk(KERN_INFO "\n" ); */
printk(KERN_INFO "vid: 0x%x\n", vendor );
printk(KERN_INFO "pid: 0x%x\n", product );
return 0; // Non-zero return means that the module couldn't be loaded.
}
static void __exit hello_cleanup(void)
{
printk(KERN_INFO "Cleaning up module.\n");
}
module_init(ftdi_fake_init);
module_exit(hello_cleanup);
MODULE_LICENSE("GPL");
MODULE_AUTHOR(DRIVER_AUTHOR);
MODULE_DESCRIPTION(DRIVER_DESC);
module_param(debug, bool, S_IRUGO | S_IWUSR);
MODULE_PARM_DESC(debug, "Debug enabled or not");
module_param(vendor, ushort, 0);
MODULE_PARM_DESC(vendor, "User specified FTDI vendor ID (default="
__MODULE_STRING(FTDI_VID)")");
module_param(product, ushort, 0);
MODULE_PARM_DESC(product, "User specified FTDI product ID (default="
__MODULE_STRING(FTDI_FAKE_PID)")" );
static int __init ftdi_fake_init(void)
{
dbg("%s", __FUNCTION__);
if(vendor > 0 && product >= 0) {
static struct usb_device_id id_table [] = { { USB_DEVICE(FTDI_VID, FTDI_FAKE_PID) }, { }, };
so, this will create alias for 0x403, 0x0 usb device to be able to attach it to our driver "usb:v0403p0000d*dc*dsc*dp*ic*isc*ip*"
# depmod -a
$ modinfo ftdi_fake
alias: usb:v0403p0000d*dc*dsc*dp*ic*isc*ip*
depends: usbserial
vermagic: 2.6.30.10-105.2.23.fc11.x86_64 SMP mod_unload
parm: debug:Debug enabled or not (bool)
parm: vendor:User specified vendor ID (default=0x0403) (ushort)
parm: product:User specified product ID (ushort)
If this attaching worked, than overriding product variable in module init to PID of 232RL which I'm not sure but based on oryginal header files is 0xFBFA, maybe could allow use this bricked device under Linux without any problems, if it is possible to attach usb device with PID 0 as I wrote earlier #define FTDI_232RL_PID 0xFBFA
product= FTDI_232RL_PID;
Speaking of which, does anyone know where to reliably get a fake chip, or a product with a fake chip? (I don't want to gamble and risk getting a genuine one for experiments. )
I believe some people earlier in the thread suggested cheapest ones on Amazon. I would personally go onto eBay and get any of the ones shipped direct from China. Would be fun to get the die out of those chips and inspect them under the SEM, see if there are any markings, just generally learn about the clones. Unfortunately I lost my SEM access when I left UBC.
Also anyone feel like writing an FTDI compatible implementation based on a microcontroller with USB? Could be fun
No. A device with a PID of 0 is not respecting USB specification.
The modification to PID 0 is in fact bricking the device. it's sheer luck that linux does not enforce PID !=0
I don't have a fake device but FT_PROG and the such will reprogram it and detects them. You just have to modify the inf files first. I've tested the install part myself windows does not complain about a bunch of PID 0000 strings and the driver installs with a warning of modification.Just wrote sample ftdi_fake.c Linux 2.6.x kernel module to invetsigate this if is it possible to attach USB device with unchanged FTDI_VID= 0x403 (hex) and PID= 0x0 (0)Code: [Select]#include <linux/module.h> // included for all kernel modules
#include <linux/kernel.h> // included for KERN_INFO
#include <linux/init.h> // included for __init and __exit macros
#include <linux/errno.h>
#include <linux/slab.h>
#include <linux/tty.h>
#include <linux/tty_driver.h>
#include <linux/tty_flip.h>
#include <linux/module.h>
#include <linux/spinlock.h>
#include <asm/uaccess.h>
#include <linux/usb.h>
#include <linux/serial.h>
#include <linux/usb/serial.h>
/*
* * Version Information
* */
#define DRIVER_VERSION "v0.0.1"
#define DRIVER_AUTHOR "Eneuro"
#define DRIVER_DESC "A Simple walk around FTDI fake PID "
#define FTDI_VID 0x0403 /* FTDI vendor Id */
///#define FTDI_232RL_PID 0xFBFA /* FTDI 232RL PID 0xFBFA or 0x6001 */
#define FTDI_FAKE_PID 0x0 /* FTDI fake PID */
static int debug;
static __u16 vendor = FTDI_VID;
static __u16 product= FTDI_FAKE_PID;
static struct usb_device_id id_table [] = { { USB_DEVICE(FTDI_VID, FTDI_FAKE_PID) }, { }, };
MODULE_DEVICE_TABLE(usb, id_table);
static int __init ftdi_fake_init(void)
{
dbg("%s", __FUNCTION__);
if(vendor > 0 && product >= 0) {
printk(KERN_INFO "The key is to set to default product ID in Linux FTDI driver to 0x0 and add it to FTDI usb device id's table !!!" );
}
printk(KERN_INFO KBUILD_MODNAME ": " DRIVER_VERSION ": "
DRIVER_DESC "\n");
/* printk(KERN_INFO "\n" ); */
printk(KERN_INFO "vid: 0x%x\n", vendor );
printk(KERN_INFO "pid: 0x%x\n", product );
return 0; // Non-zero return means that the module couldn't be loaded.
}
static void __exit hello_cleanup(void)
{
printk(KERN_INFO "Cleaning up module.\n");
}
module_init(ftdi_fake_init);
module_exit(hello_cleanup);
MODULE_LICENSE("GPL");
MODULE_AUTHOR(DRIVER_AUTHOR);
MODULE_DESCRIPTION(DRIVER_DESC);
module_param(debug, bool, S_IRUGO | S_IWUSR);
MODULE_PARM_DESC(debug, "Debug enabled or not");
module_param(vendor, ushort, 0);
MODULE_PARM_DESC(vendor, "User specified FTDI vendor ID (default="
__MODULE_STRING(FTDI_VID)")");
module_param(product, ushort, 0);
MODULE_PARM_DESC(product, "User specified FTDI product ID (default="
__MODULE_STRING(FTDI_FAKE_PID)")" );
This module does nothing for the moment, only print kernel messages when successfully loaded and outputs detected USB device vid and pid visible in $ dmesg output, added usb aliases for this fake pid,
As you can notice changed also main module init condition to accept this fake PID=0
Than change this code module init code to accept this FTDI fake PID 0 :Quotestatic int __init ftdi_fake_init(void)
{
dbg("%s", __FUNCTION__);
if(vendor > 0 && product >= 0) {The key is to add this fake PID to this table I guess tooCode: [Select]static struct usb_device_id id_table [] = { { USB_DEVICE(FTDI_VID, FTDI_FAKE_PID) }, { }, };
so, this will create alias for 0x403, 0x0 usb device to be able to attach it to our driverQuote"usb:v0403p0000d*dc*dsc*dp*ic*isc*ip*"Additionaly, we probably want in module init, after detecting we have bricked FTDI with PID==0,
overwrite it to proper product (PID) value, while probably there is another stuff which connects to device so it needs proper PID in variable product later.
But for the moment, one need to ensure that Linux will be able to attach bricked usb chip to this ftdi_fake module I've wrote,
so after recompiling, installing (copying it) in /lib/modules/...../ (where ftdi_sio sits ) we need also recreate those aliases with:Code: [Select]# depmod -a
Than we should be able see in module info this alias for our fake module, by typing:Code: [Select]$ modinfo ftdi_fake
If this attaching worked, than overriding product variable in module init to PID of 232RL which I'm not sure but based on oryginal header files is 0xFBFA, maybe could allow use this bricked device under Linux without any problems, if it is possible to attach usb device with PID 0 as I wrote earlier
alias: usb:v0403p0000d*dc*dsc*dp*ic*isc*ip*
depends: usbserial
vermagic: 2.6.30.10-105.2.23.fc11.x86_64 SMP mod_unload
parm: debug:Debug enabled or not (bool)
parm: vendor:User specified vendor ID (default=0x0403) (ushort)
parm: product:User specified product ID (ushort)Code: [Select]#define FTDI_232RL_PID 0xFBFA
product= FTDI_232RL_PID;
Unfortunate, I have no bricked FTDI stuff, so can not test it, but if you want take this ftdi_fake.c source code and recompile on 2.6.x Linux machine with oryginal FTDI Makefile but change names inside from ftdi_sio to ftdi_fake
They changed this PID to 0 while they know from Linux source that they make this devices also useless under Linux without extra work, while in their Linux manuals they suggest using standard Linux ftdi_sio kernel module, and those modules has condition of vendor and product to be >0 before any other initializations in 2.6.x kernels
More details there https://www.eevblog.com/forum/reviews/what-should-ftdi%27s-next-driver-update-look-like/msg540077/#msg540077, while this thread is spammed by a210210200 .
The devices were on life support provided by the illegal use of FTDI drivers, FTDI figured out how to and turned off the switch. I believe it was within their rights to do so. No one is stopping you resurrecting the corpses by writing some other drivers or using the legal ones on Linux.
http://bit.ly/1rUMwkt
New and Good quality !
Looks like a winner to me. Just over two dollars shipped.
http://bit.ly/1rUMwkt
New and Good quality !
Looks like a winner to me. Just over two dollars shipped.
At least not as weird as...
Arguably you could say HDCP isn't legal either since the master key is leaked and it is no longer an "effective technical measure" it isn't really as anyone can make new HDCP keys themselves. But HDCP still is allowed to disable user equipment and is not banned in the EU and I don't think is facing any current legal challenges. Also with HDCP 2.2 it is just going to get even "better...", now it will be not backwards compatible, have distance latency checks, and all sorts of fun stuff.