What should FTDI's next driver update look like? - Page 1
Forum section: electronics / general

author: JoeN
author_rank: Frequent Contributor
timestamp: October 27, 2014, 11:34:56 pm
content: Now that FTDI pulled their bricking driver and admitted some degree of culpability for that update, how should their next driver update behave? I was thinking about this and I think they do have an opportunity to create pressure from end users back on manufacturers to use only genuine chips and do it through their driver software. It would just be nagware and not bricking, maybe with a 30 second delay prior to use. I bought several "FTDI" USB-to-serial adapters on eBay last week and if I had received such a message, I would have been mad at my seller and sent them back, not mad at FTDI. Instead, I am mad at FTDI and I want my hour back. Nag messages being emitted by name brand products would embarrass manufacturers and give them a good reason, and also the actual opportunity, to spot test the ICs they receive from their suppliers. Good idea, bad? What do you think?

author: all_repair
author_rank: Frequent Contributor
timestamp: October 27, 2014, 11:48:28 pm
content: Quote from: JoeN on October 27, 2014, 11:34:56 pmThe big installed base is a gold mine.If they have no idea how to capitalise their driver, they can split the company into driver co. and chip co. Driver company probably shall worth much more than the chip co. That is provided that the clones still want to use FTDI as their default driver.

author: Fungus
author_rank: Super Contributor
timestamp: October 28, 2014, 04:50:58 am
content: If you look at what their bricker did, you'll see the problem - the driver can't really tell the fakes from the real chips by looking at them, it has to exploit a "bug" in the fake hardware (it does something that a driver wouldn't normally do).In two weeks you can expect the cloners to have patched this hole, FTDI will no longer be able to exploit it, business as usual.The only problem will be all the existing devices out there. The innocent end-users will be left high and dry and the cloners won't have lost any sleep over it, let alone any money.

author: JoeN
author_rank: Frequent Contributor
timestamp: October 28, 2014, 05:02:52 am
content: Quote from: Fungus on October 28, 2014, 04:50:58 amReally? I mean, from what I understand the FTDI chip is architecturally very different than the clone chip. They may be register compatible, but the timings can't all be exactly the same. Obviously, from FTDI's perspective, their only diagnostic tool is the host software and the USB port and that is a pretty dull tool compared to real test equipment, but there must be some way to identify the fake ICs short of bricking it. It's hard to believe that the only "bug" in the clone chip is the one that bricks it - how totally convenient is that?Quote from: Fungus on October 28, 2014, 04:50:58 amTwo weeks to a new mask, really?

author: Fungus
author_rank: Super Contributor
timestamp: October 28, 2014, 07:59:16 am
content: Quote from: JoeN on October 28, 2014, 05:02:52 amSo? The driver can't remove the plastic from the chip and peek at the silicon inside. The driver can only see what the chip chooses to expose over the USB interface.Quote from: JoeN on October 28, 2014, 05:02:52 amYes, really. Those clones use a general purpose microcontroller with masked ROM. All they need to do is to tweak their FTDI emulation software and press "send". The machine does the rest. The only real inconvenience to them is they'll have more trouble selling any stockpiled chips (which won't be many).

author: Psi
author_rank: Super Contributor
timestamp: October 28, 2014, 08:22:20 am
content: It just needs a warning box popup explaining that the hardware the user just plugged in is using counterfeit components. That's all.The driver can refuse to work with fake chips or maybe continue with a nag screen every hour.Hehe, could have it redirect to a paypal gateway where the user can pay $1 to FTDI and the driver will work until the next rebootA better way to do fake detection is to figure out maybe 20+ ways to 'detect' a fake chip and then randomly test the chip every so often (statistically speaking maybe once every 12h of use) and use only one of those detection methods pseudo randomly chosen. Even better if the detection methods are weighted, so some methods almost never get used.This way it's harder for china to figure out how to bypass the detection, since its not quickly testable and keeps changing.They would have to disassemble the ftdi driver and find all the methods used.

author: JoeN
author_rank: Frequent Contributor
timestamp: October 28, 2014, 05:06:29 pm
content: Quote from: Psi on October 28, 2014, 08:22:20 amThey really need to provide something to their direct customers (integrators) so they can test incoming reels and know if the part is good or not.

author: AG6QR
author_rank: Frequent Contributor
timestamp: October 28, 2014, 06:55:02 pm
content: Quote from: Fungus on October 28, 2014, 04:50:58 amI'd argue that the "bug" is in the genuine FTDI hardware. The bricker wrote to a couple of even numbered eeprom addresses. On a real FTDI chip, those eeprom writes are ignored, and I believe that's due to a bug in the FTDI implementation of the eeprom write routine. On a fake chip, those writes are honored, writing the bad PID into eeprom.The code is here:http://hackaday.com/2014/10/24/ftdi-screws-up-backs-down/Of course, one man's bug is another man's feature. It's within the realm of possibility that FTDI intentionally implemented their WriteEEPROMValue function to ignore even-numbered addresses, though I can't for the life of me understand why. Still, without a written specification for what the WriteEEPROMValue function is supposed to do, I can't be sure that was a bug in FTDI's implementation.But what IS clear from the code is that the bricking was intentional.If they wanted to nondestructively test to see if a chip has that FTDI behavior of ignoring writes to even-numbered addresses, they could have attempted the write to a less-critical spot in EEPROM, and they could have restored the byte they attempted to write, instead of calculating a new checksum and altering a different byte to make the checksum match. Or, they could have found some other unique behavior of the genuine FTDI chips.Of course, whatever they do, they're just getting into an arms race with the counterfeit chip makers. The next round of counterfeit chips will most likely ignore EEPROM writes to even addresses, in order to mimic the behavior of genuine FTDI parts and work with the FTDI driver. Likewise if they exploit some other difference, the counterfeiters will eventually copy that behavior, whatever it might be, as well.

author: Rufus
author_rank: Super Contributor
timestamp: October 28, 2014, 07:53:34 pm
content: Quote from: AG6QR on October 28, 2014, 06:55:02 pmWriting to EEPROM every time the device is plugged in or powered up would eventually wear out the EEPROM and really destroy the hardware. Do you know the EEPROM endurance of fake parts? Changing something to prevent FTDI drivers loading in the future was really the only option for exploiting this non-genuine detection method and had the advantage of preventing older drivers loading as well.They could have allocated a non-zero PID for detected non-genuine hardware which would make it slightly easier for users to restore the PID and carry on their unlicensed use of older drivers.

author: AG6QR
author_rank: Frequent Contributor
timestamp: October 28, 2014, 08:08:29 pm
content: Quote from: Rufus on October 28, 2014, 07:53:34 pmThe bricking solution they tried does an unconditional write to EEPROM every single time the driver initializes. Of course, the write fails on a genuine FTDI part, and the solution I described would also fail to write to a genuine FTDI part. So for a genuine FTDI part, there's no difference.Yes, there are limited write cycles for EEPROM, but the limit may be 100,000 cycles or more. That's an order of magnitude or more higher than the number of mating cycles for USB connectors, so I'd say it's not likely to be a huge issue if you write to EEPROM once or twice each time the counterfeit device is plugged in. And of course, it's ONLY an issue for counterfeit chips, because they're the only ones that will honor the EEPROM write. And since the counterfeit chips won't work with the driver that's detecting them this way, someone would have to be a really slow learner to keep trying to use the fake chip until its EEPROM failed.In the end, if the technique I described DID destroy any chip, it would only destroy a counterfeit one, and it would only do that after the write cycle limit was exceeded. That worst case result isn't any worse than the bricking code FTDI released, and it's a lot better, because it takes a very long time to do any damage.

author: SeanB
author_rank: Super Contributor
timestamp: October 28, 2014, 08:14:17 pm
content: If it fails for a chip then the checksum will fail, and the chip should use the default values for itself, and work without having an eeprom available.Wonder what the clones do if the checksum fails, or if they use it at all.

author: _Sin
author_rank: Regular Contributor
timestamp: October 28, 2014, 08:26:09 pm
content: Quote from: Psi on October 28, 2014, 08:22:20 amWhich would take all of 10 minutes. And it wouldn't just by the knock-off merchants in China doing the reverse engineering, it would be anyone trying to use a non-official device with the requisite knowledge.Our understanding of how FTDI's last attempt worked didn't come from the counterfeiters.Basically I think it would be a mistake, if they have 20 methods to spot a fake, to put them all in a single release - they'll be patched around in no time and every aspect documented for the next counterfeit revision to fix.If they really want to be in an arms race, do it one at a time for maximum impact.

author: Rufus
author_rank: Super Contributor
timestamp: October 28, 2014, 09:11:07 pm
content: Quote from: AG6QR on October 28, 2014, 08:08:29 pmOr it might be FLASH with 100 cycles how does anyone but the people that made it know.Quote from: AG6QR on October 28, 2014, 08:08:29 pmPhysically destroying the chip is very different from bricking (because there are no other drivers) it with a PID change. It is what half the loons have been incorrectly claiming FTDI is doing while they fantasize about law suits.

author: dannyf
author_rank: Super Contributor
timestamp: October 29, 2014, 09:10:04 am
content: QuoteFairly common on mcu's to maintain reading / writing atomicity.

author: daqq
author_rank: Super Contributor
timestamp: October 29, 2014, 10:44:00 am
content: Maybe they could generate SOME profit from the fakes - make an ad sponsored driver that shows google ads when the user uses a fake FTDI...

author: eneuro
author_rank: Super Contributor
timestamp: October 29, 2014, 08:19:54 pm
content: Quote from: AG6QR on October 28, 2014, 06:55:02 pmInvestigated a little bit latest Linux driver published (relased) on their web site at 2009-05-14 and it is in old version: 1.5.0 .Module initialization routine looks like this:QuoteSo, ifproduct(PID) was changed to 0, than no way even Linux version had no chance to work-only after this overwrite, but it require additional effort shown in this thread:https://www.eevblog.com/forum/reviews/ftdi-driver-kills-fake-ftdi-ft232/msg534432/#msg534432QuoteWhile they write additional address in ROM not used by oryginal FTDI this trick above should work, while this additional write to keep checksum correct do not affect other chips, unless no important data was stored there?Are there any tools other than FTDI to write back correct numbers to those affected chips?It looks like in latest kernel 3.17 the only parameter isndi_latency_timer, so no way to pass thosevendorandproductparameters no more?http://lxr.free-electrons.com/source/drivers/usb/serial/ftdi_sio.cCode:module_param(ndi_latency_timer, int, S_IRUGO | S_IWUSR);MODULE_PARM_DESC(ndi_latency_timer, "NDI device latency timer override");In olderftdi_sio.cand even thosehttp://www.ftdichip.com/Drivers/VCP.htmLinux drivers we had such module parameters: debug, vendor, productCode: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 vendor ID (default="__MODULE_STRING(FTDI_VID)")");module_param(product, ushort, 0);MODULE_PARM_DESC(vendor, "User specified product ID");and in my kernel )while it is newer that Linux driver released on FTDI current web pages) additionaly was this one which looks like is the only one module parameter in latest kernels eg. 3.17Code:module_param(ndi_latency_timer, int, S_IRUGO | S_IWUSR);MODULE_PARM_DESC(ndi_latency_timer, "NDI device latency timer override");Why thosevendorandproductparameters were removed in latest official Linux kernel releases?It could allow simply pass those vendor and product parameters toftdi_siomodule during loading . eg. bymodprobeetc...Of course I do not plan to use FTDI chips in new designs, but want to ensure will be able give second life bricked one at least under LinuxJust looking into latest Linuxhttp://www.kernel.org/3.17.1and its official patches to see what is inside source of ftdi_sio.c moduleUpdate: In the case of Linux FTDI driver for 2.6.x kernels this update probably could look like this my testftdi_fake.cdriverCode:#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_VID0x0403/* FTDI vendor Id *////#define FTDI_232RL_PID0xFBFA /* FTDI 232RL PID 0xFBFA or 0x6001 */#define FTDI_FAKE_PID0x0/* 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(vendor, "User specified FTDI 232RL product ID (default="__MODULE_STRING(FTDI_FAKE_PID)")" );It looks like the key might be to add to FTDI vendor & product table this... fake 0x0 PID and define this bricked device PID to 0QuoteThan change this code module init code to accept this FTDI fake PID 0 :QuoteAfter installing such module and issuing commandQuotewe could add nice usb alias for this fake FTDI device, but unsure if one can attach USB device with PID 0x0 zeroQuoteUnfortunate, haven't got any device bricked by FTDI, so can not test it, but it could be fun change this Linux driver to support those disabled devices under Linux without any additional magic hacksRecompiled and this module nice loads by hand and nice output in logsCode:$ dmesgThe key is to set to default product ID in Linux FTDI driver to 0x0 and add it to FTDI usb device id's table !!!ftdi_fake: v0.0.1: A Simple walk around FTDI fake PIDvid: 0x403pid: 0x0

author: a210210200
author_rank: Regular Contributor
timestamp: October 30, 2014, 08:13:46 am
content: I thought people already fixed it by just overriding the PID in the OS. (Like if FTDI VID and PID of 0000 force PID of the original)Isn't it trivial to do this in windows(tested myself)/linux can do it too even without a patch just press some buttons or type some text and magic PID 0000 is the same as PID xxxx.Edit:http://www.spinics.net/lists/linux-usb/msg115963.htmlIt seems GE did something funny to need forced assignment as well.

author: Fungus
author_rank: Super Contributor
timestamp: October 30, 2014, 09:39:02 am
content: Quote from: a210210200 on October 30, 2014, 08:13:46 amPeople keep using this word "just" as if it's simple thing to do. A 30 second fix.In my case I'd have to go out and find a live Linux distribution, get it onto some sort of support media, see if it will boot on my machine, go online and find out what files I need and where to get them, and.... (mumble, mumble, don't know where it goes from there).All in all it would probably be a morning's work, even if you know enough about Linux to be able to do it. If youdon'tknow how to do it, or work in an office where you're not allowed to, you're screwed. You might as well throw it away.

author: SeanB
author_rank: Super Contributor
timestamp: October 30, 2014, 08:17:36 pm
content: Quote from: Fungus on October 30, 2014, 09:39:02 amISO fromwww.debian.org, a blank CD or even follow the instructions there to make a bootable CD or USB flash device, copy of the instructions and the python script, reboot to start from CD or USB, get the live distro up, apt get pythonusb, python. Copy file to desktop. Open terminal, cd to desktop and python scriptname and you are done. Shut down or just press reset and you are done.Me I already run Linux so only had to get the pyusb driver set. Turns out the ones I have are genuine.......

author: Fungus
author_rank: Super Contributor
timestamp: October 30, 2014, 08:23:12 pm
content: Quote from: SeanB on October 30, 2014, 08:17:36 pmA what??? I think the last time I saw a "blank CD" was in 2003.Edit: You actually need 8 CDs, or 3 DVDs...Quote from: SeanB on October 30, 2014, 08:17:36 pmObvious, really! I'll get my boss to try it. See if he succeeds...

author: SeanB
author_rank: Super Contributor
timestamp: October 30, 2014, 08:35:30 pm
content: That is why they hire you. He can operate accounts...........

author: Fungus
author_rank: Super Contributor
timestamp: October 30, 2014, 08:54:33 pm
content: Maybe there's something smaller than Debian where I won't have to manually edit X11.conf or spend a morning trying to get the video driver working.Just to fix my $3, "not 'broken', honest!!!", USB cable.Sheesh.PS: Yes, I've heard of things like SystemRescueCD. I was just wondering how easy+simple the Linux users would try to make it sound (I was right...they've suppressed those memories of what a PITA it is to install an operating system, any operating system)

author: Richard Crowley
author_rank: Super Contributor
timestamp: October 30, 2014, 09:08:22 pm
content: The new driver should...1) Repair the damage they caused (restore the values).2) Apologize for damaging the user's equipment.If they detect a counterfeit chip...3) Display a message that the user should return the gadget or report the problem back to the vendor.4) Throw in a 30-second delay on first-sync to make it "painful" for the user if they really want to assert their "rights".Or, if the really want to play hard-ball,4) Refuse to talk to the counterfeit chip. Offer to sell an "unlock code" upon payment of the equivalent royalties on the chip protocol.

author: Fungus
author_rank: Super Contributor
timestamp: October 30, 2014, 10:04:56 pm
content: Quote from: Richard Crowley on October 30, 2014, 09:08:22 pmAfter this stunt they should be begging us to keep on using the fake chips.Don't worry though, the counterfeiters are already busy tweaking their chips so the FTDI driver won't be able to detect them. As with any DRM scheme dreamed up by company bosses, the only real damage is to the innocent end users.

author: a210210200
author_rank: Regular Contributor
timestamp: October 31, 2014, 12:16:08 am
content: Quote from: Fungus on October 30, 2014, 09:39:02 amSerious if this is so hard to do I'm "just" going to give you a pictorial guide just like the first years need for the turn on the box please instructions. I don't have a fake FTDI chip but I mangled one's VID/PID intentionally to test this.Get an error can't connect your FT232 cable. Click on the bubble or look in device manager.Click update driver as the screen says to.Then obviously since the automatic process failed click on the find it yourselfThen because we are lazy and we know the old driver worked press pick from listSelect all devices (its easier)Select FTDI and choose an old driverYou'll get a warning but obviously ignore it as normalDone, no third party tools needed, no live cd required, no reg edits, no command line. Just device manager. If you want you can now re-program the PID in FT_PROG.Also, you don't need to restart.Additional note windows tracks the exact port you plug something into so as you may or may not have noticed moving the USB plugs around can cause drivers to update, change, or re-install for basically everything from mice/keyboard/and the FTDI chips.

author: eneuro
author_rank: Super Contributor
timestamp: October 31, 2014, 12:27:18 am
content: Quote from: SeanB on October 30, 2014, 08:17:36 pmIt looks like in 2.6.* Linux kernel FTDI headers is invalid value of PID of FT232RCode:$ cat ./drivers/usb/serial/ftdi_sio_ids.h|grep 232R#define FTDI_232RL_PID 0xFBFA /* Product ID for FT232RL */while in its datasheet:http://www.ftdichip.com/Support/Documents/DataSheets/ICs/DS_FT232R.pdfwe have:QuoteIf one day will find in some teardown of cheap USB dongle fake FT232R chip, will try to brick it by writing PID 0 and test my latestftdi_fakeLinux driver just to see if it works with this fake chipNow no problem to pass PID 0 as module parameter and it has defined alias for USB 0403:0000Testing our newftdi_fakeLinux driver (oryginal ftdi_sio.ko renamed to ftdi_sio_ko and runCode:#depmod -ato recreate aliases while they are the same + additional for our fake chip with PID 0Code:# modinfo ftdi_fake...alias: usb:v0403p0000d*dc*dsc*dp*ic*isc*ip*...depends: usbserialvermagic: 2.6.39.1-nomoreftdi SMP mod_unloadparm: debug:Debug enabled or not (bool)parm: vendor:User specified vendor ID (default=0x0403) (ushort)parm: product:User specified product ID (default=0x6001) (ushort)parm: ndi_latency_timer:NDI device latency timer override (int)Now simulating trying to use fake PID 0, which I hope USB will try to do when such fake FTDI USB dongle with PID 0 will be inserted to our Linux box:Code:# modprobe ftdi_fake product=0Code:# dmesgWARNING: ftdi_fake: vendor VID: 0x0403 unknown PID: 0x0000 changed to default PID: 0x6001USB Serial support registered for FTDI USB Serial Deviceusbcore: registered new interface driver ftdi_sioftdi_fake: v1.6.0-fake: USB FTDI Fake FT232R Serial Converters Driverftdi_fake: VID: 0x403 PID: 0x6001So, far so good, but I need fake bricked FTDI USB dongle to test what usbserial module will do with device with correct vendor id but product id zeroAttached thisftdi_fakemodule based onftdi_sio.c(also included for comparision) from Linux kernel 2.6.39.1 .Changes I've made in file:ftdi_fake.c.diffand below:Code:--- ftdi_sio.c2011-06-03 02:34:20.000000000 +0200+++ ftdi_fake.c2014-10-31 00:49:17.853826047 +0100@@ -1,5 +1,6 @@/*- * USB FTDI SIO driver+ * USB FTDI FAKE driver+ *Copyright (C) 2014 Eneuro**Copyright (C) 2009 - 2010*Johan Hovold (jhovold@gmail.com)@@ -51,13 +52,16 @@/** Version Information*/-#define DRIVER_VERSION "v1.6.0"-#define DRIVER_AUTHOR "Greg Kroah-Hartman <greg@kroah.com>, Bill Ryder <bryder@sgi.com>, Kuba Ober <kuba@mareimbrium.org>, Andreas Mohr, Johan Hovold <jhovold@gmail.com>"-#define DRIVER_DESC "USB FTDI Serial Converters Driver"+#define DRIVER_VERSION "v1.6.0-fake"+#define DRIVER_AUTHOR "Greg Kroah-Hartman <greg@kroah.com>, Bill Ryder <bryder@sgi.com>, Kuba Ober <kuba@mareimbrium.org>, Andreas Mohr, Johan Hovold <jhovold@gmail.com>, Eneuro"+#define DRIVER_DESC "USB FTDI Fake FT232R Serial Converters Driver"++#define FTDI_232R_PID0x6001 /* Product ID for FT232R */+#define FTDI_FAKE_PID0x0000 /* Product ID for counterfeit FT232R bricked by FTDI using Micro$oft automatic update Window$ driver */static int debug;static __u16 vendor = FTDI_VID;-static __u16 product;+static __u16 product= FTDI_232R_PID;struct ftdi_private {struct kref kref;@@ -177,6 +181,7 @@{ USB_DEVICE(FTDI_VID, FTDI_8U232AM_PID) },{ USB_DEVICE(FTDI_VID, FTDI_8U232AM_ALT_PID) },{ USB_DEVICE(FTDI_VID, FTDI_232RL_PID) },+{ USB_DEVICE(FTDI_VID, FTDI_FAKE_PID) }, /** Fake FTDI PID */{ USB_DEVICE(FTDI_VID, FTDI_8U2232C_PID) },{ USB_DEVICE(FTDI_VID, FTDI_4232H_PID) },{ USB_DEVICE(FTDI_VID, FTDI_MICRO_CHAMELEON_PID) },@@ -2317,11 +2322,20 @@return -ENOIOCTLCMD;}-static int __init ftdi_init(void)+static int __init ftdi_fake_init(void){int retval;dbg("%s", __func__);+/** Change fake PID 0 to module default */+if(product==FTDI_FAKE_PID ) {+product= FTDI_232R_PID;+printk(KERN_INFO "WARNING: " KBUILD_MODNAME ": "+" vendor VID: " __MODULE_STRING(FTDI_VID)+" unknown PID: " __MODULE_STRING(FTDI_FAKE_PID)+" changed to default PID: " __MODULE_STRING(FTDI_232R_PID) "\n");+} /** End of: Change fake PID 0 to module default */+if (vendor > 0 && product > 0) {/* Add user specified VID/PID to reserved element of table. */int i;@@ -2338,8 +2352,9 @@if (retval)goto failed_usb_register;-printk(KERN_INFO KBUILD_MODNAME ": " DRIVER_VERSION ":"+printk(KERN_INFO KBUILD_MODNAME ": " DRIVER_VERSION ": "DRIVER_DESC "\n");+printk(KERN_INFO KBUILD_MODNAME ": VID: 0x%x PID: 0x%x \n", vendor, product );return 0;failed_usb_register:usb_serial_deregister(&ftdi_sio_device);@@ -2347,7 +2362,7 @@return retval;}-static void __exit ftdi_exit(void)+static void __exit ftdi_fake_exit(void){dbg("%s", __func__);@@ -2356,8 +2371,8 @@}-module_init(ftdi_init);-module_exit(ftdi_exit);+module_init(ftdi_fake_init);+module_exit(ftdi_fake_exit);MODULE_AUTHOR(DRIVER_AUTHOR);MODULE_DESCRIPTION(DRIVER_DESC);@@ -2369,7 +2384,8 @@MODULE_PARM_DESC(vendor, "User specified vendor ID (default="__MODULE_STRING(FTDI_VID)")");module_param(product, ushort, 0);-MODULE_PARM_DESC(product, "User specified product ID");+MODULE_PARM_DESC(product, "User specified product ID (default="+__MODULE_STRING(FTDI_232R_PID)")");module_param(ndi_latency_timer, int, S_IRUGO | S_IWUSR);MODULE_PARM_DESC(ndi_latency_timer, "NDI device latency timer override");Have a good time

author: C
author_rank: Super Contributor
timestamp: November 02, 2014, 10:06:47 am
content: None of what I am hearing here belongs in a driver.If it is worth someone's time it will be broken!Think about what the normal windows user thinks. Windows takes to long to start!!!And You want it to be even slower?You plug something in to USB and you want to wait longer?If it only wasted one second, Think of what that really means.60 people and you just lost a minute.l3600 people and you have lost an hour86,400 people and you have lost a day31,536,000 and you have lost a yearthe December 2013 world internet user number I found was2,802,478,934 at just one second that wastes 88.866024036 years.How much does it cost to run a cheap computer for 88.6 yearsA clone check or fake test should be a separate program.Google seams to care a little bit, They turned on HTTPS for searches. Think that was free?Google had to add more computing power, More computers = larger power bill.C

author: rob77
author_rank: Super Contributor
timestamp: November 02, 2014, 12:42:19 pm
content: Quote from: Fungus on October 30, 2014, 08:23:12 pmno you don't need 8 CDs or 3 DVDs...... live CD is live CD ... CD because it fits a blank CD but there are also live DVDs (basically the very same thing)8CDs or #DVDs are the installation media... but who the hell is downloading those nowadays ? if you want to install , then just download a 200MB netinstall ISO and let the installer download the subset of packages you need.

author: nctnico
author_rank: Super Contributor
timestamp: November 02, 2014, 12:50:25 pm
content: Using the bootable USB stick image is even easier. I haven't used my CD/DVD burner in years.

author: David Hess
author_rank: Super Contributor
timestamp: November 02, 2014, 07:27:13 pm
content: Quote from: Psi on October 28, 2014, 08:22:20 amMake them have to reboot:http://dilbert.com/strips/comic/1994-09-30/Quote from: mojo-chan on October 28, 2014, 09:48:51 amBased on my experience getting chips out of them, I would say FTDI is under no obligation to provide genuine ICs that work with their driver either.

author: a210210200
author_rank: Regular Contributor
timestamp: November 02, 2014, 08:47:59 pm
content: Quote from: nctnico on November 02, 2014, 12:50:25 pmRufus is a great for making boot able USB key especially for newer UEFI computers. It is also totally freeware (no donations even allowed)http://rufus.akeo.ie/It works great with basically any image you want to boot, made making USB boot keys even easier for me.

author: Fungus
author_rank: Super Contributor
timestamp: November 03, 2014, 05:59:45 am
content: I used my Raspberry Pi...