Arduino FTDI driver issue with Windows update

eg:

Their "MSP430 launchpad" eval board has that too, the serial inerface quits after about 10 minutes abd needs to be "re-plugged". Dunno if this is intentional or a bug.

I can't relate this thread to the problem aluded to in your earlier post. The Prolific thread is about them coding their driver to not work with the fake 2303 chips. That is not the same as ruining them and it doesn't make a problem for people with legitimate 2303 chips.

Is this just your observation or have others seen this as well? I'd be very surprised if it is true. It would be hard for TI to sell product to anyone with a demo board that only works for 10 minutes.

BTW, I have my manufacturers mixed up. The $4 board is from Cypress.

They still stop working.

It's my observation. I searched on the topic and couldn't confirm or refute it, I found no evidence that anyone had used the USB connection for extended periods.

On Tue, 28 Oct 2014 15:50:32 -0400, WangoTango Gave us:

I'd say you do not even know the meaning of the colloquialism you are trying to inject into this is.

The crime is manipulating hardware you have no right to manipulate.

That includes any soft or hard 'lock-out switches' and/or 'fuse burning' functions that are not fully user imposed/implemented.

I don't see how that is a problem with the driver supplier if that is a competing chip maker's chip. The dongles don't stop working, the driver stops supporting them. Prolific and FTDI are clearly free to not support other supplier's devices. It isn't the Prolific chips that have a problem, it is the fake devices that stop being supported with the Prolific driver. If you can find a driver from the maker of the dongle or the chip then your device will still work just fine unlike the chips that are bricked by the FTDI drivers.

Interesting. I will keep my eyes open for this one. I have one of the TI launchpads but have not used it much.

distinguish

nice

chip.

that

it

ever

Hey, i just noticed your posts are normal. Good work Lasse.

?-)

For volume manufacturers, the device IDs have to be purchased from USB consortium of one of their captive resellers.

?-)

that

"$20

or

the

see

I'm

an

that

be

Much better strategy.

?-)

If they were using their VID and PID they had every right to do what they will with it.

I don't even know how to respond to dumb asses like you guys.

FTDI get robbed and all you are worried about is the shit you bought that was their stolen IP.

Fuck off.

On Wed, 29 Oct 2014 15:26:14 -0400, WangoTango Gave us:

I'm sorry.. a hardware port with software control... a stupid idea to start with.

So the copytards were not too bright to embrace such a stupid paradigm either, such that they copied (legally reverse engineered, then emulated) all of it.

Of course the branding is illegal.

The back door death knell switch shit should be as well.

Too vulnerable to a hack which would/could render entire systems non-functional.

Really? If I use a registered VID and PID on some USB device I build that makes it the property of the registered agent of that VID/PID? Wow, property rights have changed!!!

Yes, FTDI lost sales and they respond by trashing my living room.

If you don't like the company, please don't stay. You won't be much missed.

As the reality has shown, they are not "reverse engineered to work with the FTDI driver". They do not conform to the VID update procedure. :->

Bets regards, Piotr

Then how many bits does it have to have in order to be "ownable"? Is 128 bits enough? (most symmetric session keys) 1024? (RSA private key). HDCP master key?

You don't buy bits, but the promise that your bits are unique.

Best regards, Piotr

And that's the real issue. How is one going to prove that it has been done deliberately? Or if one can, then what then? Proactively ask "Judge, could you please debug my code in order to ensure that none of the non-conformant devices won't get broken?"

Best regards, Piotr

Depends on the situation. There may be a paper trail in the form of emails that shows that it was deliberate.

Remember, the issue is whether it was deliberate. If not, then the non-FTDI device owners have no redress, since FTDI certainly owed them no duty of care.

Sylvia.

Over in the eevblog forum, somebody used a USB protocol analyser to see what the driver was doing, and also disassembled part of the driver (yeah, quite possibly contrary to that licence "agreement" that they did not even see). When you understand exactly what FTDI did, which depends on a subtle difference between how their chip and the clone chip handle requests to write even and odd numbered 16 bit words to the EEPROM, you can come to no other conclusion than that it was done deliberately.