Have FTDI kicked-off round 2 of the clone wars?
eevblog.com
eevblog.com
One of these days they're going to brick a pacemaker and kill someone. You have to be a special kind of delusional to think that the courts are going to care about your "good intentions" when you knowingly release a driver like this.
And "pacemaker" is really a placeholder for any system that could end up affecting safety of life, regardless of whether it was intentionally designed to. How many of these FTDI chips do you suppose are on a 747? An elevator controller? A fire suppression system? A one-off alarm system at a power plant? A nuclear power plant? How many hoops do you have to jump through before you start to leave your comfort zone? Not many...
A single lawsuit from a bad enough accident could end the company in one fell swoop. This should be a much bigger existential concern for FTDI than any amount of potential IP theft. If I were their general council, I would be looking for the vigilante engineer to sumarily fire, and put in place mechanisms to ensure that this never happens in the future.
When the fake-killer driver burst onto the scene previously, I just switched to microchip MCP2221's. It just wasn't worth the risk that I might accidentally source a counterfeit on a BOM and not find out until later.
If it says FTDI on it, its now a no go. Just no way to be sure anymore.
The fact is, it's impossible for me to know if an IC is genuine or not. Therefore, buying FTDI is now like playing russian roulette. If you got unlucky, you (or your customer) will have a nasty surprise, possibly years down the line. The rational choice is therefore to buy chips from manufacturers that don't do this.
1. It's half the price of a FT232R.
2. It's available in SOIC. Much easier to solder.
3. It's USB CDC compliant. No drivers required on most OSes.
4. Along with GPIOs, its spare pins can also be configured for ADC or DAC operation. Also, it's got an I2C master.
It doesn't have a full set of UART signals, unfortunately, but it does have a couple of configurable GPIOs. There's also the MCP2200 which sacrifices I2C for RTS/CTS.
And quite frankly, why should they be responsible for any of those things? Shouldn't the fault be on the people who used fake chips?
Yes, this exactly. Most of the systems these chips are attached to are tiny embedded processors with very little RAM and no memory protection. It's almost a given that a non-negligible number of these systems will crash on this kind of input. The FTDI chip wouldn't even need to be in a critical signal path if it's spewing garbage all over memory.
What they are doing is allowing the driver to attach, and then sending arbitrary random crap down the line.
>>Shouldn't the fault be on the people who used fake chips?
It doesn't appear that the problem is people buying fake chips on purpose. All of the large chip distributors have unwittingly sent out fakes.
This approach punishes
- the end users, who likely had no role in this at all
- manufacturers of devices who thought they were buying legit chips
The situation is not unlike that of usb keyboard/mice which use the HID ("human interface device") standard driver (which MCP2221 apparently also supports). So there won't be any argument or shenanigans about whether any third-party chip should be allowed to be compatible with this commonly available driver.
That breaking a license and using software with hardware it wasn't ever intended to be used with might produce undefined behaviour?
Don't get me wrong: It would be great if we had an open source FTDI driver. But putting the blame on FTDI for all the people effectively pirating their software isn't the way to go.
If you are a stern supporter of Free/open source licenses you also need to accept other peoples' rights to license their work as they think is right. Because without a strong licensing framework GPL & co. don't work either.
How can I, as consumer, be absolutely positive that that the "FTDI" chip in my device is genuine? I'll go ahead and answer that. I can't. Anyone who works in the electronics industry knows this. When everything is made in china, it's very hard to be sure that fakes don't end up where they shouldn't belong.
Why do I bring this up? Because, last time they pulled this crap, reputable brand's products were damaged. Somehow some fakes ended up in their supply and those customers got screwed.
OK, so sure, we can fix the supply chain, add expensive testing to the manufacturing process, buy direct from manufacturer, etc... or hey, I got a better idea. Let's just not buy FTDI any longer. That sounds much cheaper and less painful.
In countries that respect IP this isn't a problem. The larger issue is China, Taiwan, etc don't respect IP and hard tactics like the FTDI driver bricking becomes a reality. No one wants to talk about the elephant in the room: Asian manufacturer corruption and lack of accountability with IP issues in those countries.
Lets get one thing straight here. Multiple people/management in the supply chain here know these things are fake. They aren't stupid. They know that a no-name manufacturer who suddenly undercuts everyone else and uses FTDI's driver is a counterfeit. They chose this knowingly to save cost and said 'fuck all' to any issues later down the line.
>Let's just not buy FTDI any longer.
Dell didn't need to buy FTDI to have the nightmarish capacitor plague issue. FTDI didn't make all the toxic dogfood that killed all those US dogs in 2007. FTDI had nothing to do with putting melamine in infant formula. Again, you're ignoring the real issues of how China and Taiwan and other governments do a "wink, wink, nod, nod" when its comes to IP issues and encourage and even protect counterfeiters for the sake of economic output and underselling those who respect IP.
Oh well, here comes the downvotes because on HN you can't criticize China, only Western nations.
edit: to the person who thinks the capacitor issue was just a 'QA issue.' It was corporate espionage against Japan from China to get around IP issues:
https://en.wikipedia.org/wiki/Capacitor_plague#Industrial_es...
Wait what? The real issue is that manufacturers can push broken drivers (kernel-mode code!), with seemingly no oversight, to users who no longer have an option to opt out.
I don't disagree with you, but you can't ignore the realities of the world. One of those is that almost all electronics are made in these regions (fake and genuine). This is why supply chain control is very difficult in these places. Additionally, supply chain control is not my problem to solve. It's the vendor's (FTDI).
> Dell didn't need to buy FTDI to have the nightmarish capacitor plague issue.
None of those issues were created intentionally by a reputable company. Dell didn't intentionally start building bad caps. It was due to a QA process gap at a fairly reputable capacitor manufacturer. It was a mistake... In this case, FTDI is doing this on purpose. It's totally reasonable to blame FTDI for a problem they created.
I don't see that as a "QA process gap".
In this case, there is no way to test for this as ftdi doesn't provide any way to do so. They simply break stuff after the fact. The only way to prevent this from happening is to not use ftdi branded parts.
Please don't. The HN guidelines explicitly ask you not to go on about downvotes, and the on-HN-my-opinion-is-oppressed line is tiresome.
Doesn't the Somehow some fakes point to those brands not entirely deserving a reputation for not shipping fakes? I get that an isolated incident is different than not caring at all, but fake chips ending up in their products is a demonstration that they are not fully preventing it.
Whether consumers are interested in paying for products that they can be sure do not contain counterfeits is a different question than whether a given company shipped counterfeits or not.
or hey, I got a better idea. Let's just not buy FTDI any longer. That sounds much cheaper and less painful.
If you want to trade on your reputation and a manufacturer makes it impossible to verify their parts, don't use that manufacturer.
I think differing ideas of 'reputable brand' may be the problem, you can't just want to be a reputable brand and go through some motions of providing quality, you have to walk the freaking walk.
The cost for a company to use those chips are too great now. And that result is purely FTDI's response.
They could have taken other avenues: Windows Syslog, GUI messages, warnings. Instead they chose to do a path that we plebes would have been arrested and charged with the CFAA for doing (vandalizing hardware over a network).
Logically, the proper thing to do would be to develop a counterfeit detector and distribute it to all reputable intermediaries in the supply chain between them and the customers. That way, distributors could test the chips before accepting a shipment, and before paying for knockoffs.
Instead, FTDI gave the tester to end-users, all the way down at the other end of the supply chain. Many of these people will not even know what a FTDI is. And the tester actually works by making all detected counterfeit chips non-functional, which basically means someone ordered a package and it blew up in their face after they already paid for it.
The responsibility for protecting and enforcement of trademarks rests entirely upon the owner of the mark, not upon the customer.
Well, you can't. But that's just a side effect of the clones working with FTDI's drivers for so long. Now, when the clones stop working, your distributor won't be able to sell you counterfeit chips anymore.
>Let's just not buy FTDI any longer.
That or let your distributor know (wallet, lawyers, whatever) that you want the original FTDI chips you paid for and not knock offs.
In any case this creates new opportunities on the market. FTDI had/has a quasi monopoly on those chips. When this end this might be painful in the short run but we could get so more competition into the market.
That's the booby prize. It's too late. You've shipped product containing chips that the FTDI driver bricks or disables, and (a) you are screwed, and (b) your customers are screwed.
Meanwhile FTDI is chastising you for buying counterfeit chips.
Logical response: To heck with the whole mess. Buy someone else's chips.
This was not well thought out.
The problem today isn't just "undefined behavior". It could have been a problem yes, but FTDI defined this behavior quite specifically. The problem is they defined it with an in-band licensing message instead of out-of-band.
Imagine if you were using Microsoft Outlook for email (hey, we're corporate here, cut us some slack) and the Outlook client determined that your Windows installation wasn't Genuine and it decided that the proper recourse was to replace the body of all your outgoing emails with a message saying "NON GENUINE WINDOWS(TM) FOUND".
Would that sort of design be (a) insane, or (b) insane?
There is a free-software FTDI driver[1]. What this driver doesn't do, is to destroy or send random data to a chip it doesn't recognize as original.
[1] http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.g...
We do have an open source FTDI driver, and it works perfectly with both the real thing and with clones.
If you run a windows platform and you introduce FTDI chips in your design schematic, you run afoul of using accidentally counterfeit chips. Digikey and Mouser both have had this problem of counterfeits in their supply chain. And we aren't discussing FTDI-compatible chips, that do not counterfeit or claim to be FTDI. But the FTDI kills them all.
The safer alternative is to use a USB-serial chip that's cheaper, and doesn't harass users or nuke their chips: ch340G
Datasheet: https://www.olimex.com/Products/Breadboarding/BB-CH340T/reso...
Somehow with FTDI chips it's "normal", "okay" and expected to get counterfeit goods. And heaven forbid the original manufacturer doesn't support you in your innocence.
But if someone ships you a fake ATtiny all hell breaks loose and the Chinese ebay seller must be punished, hours and hours are spent communicating with ebay, with PayPal, with other users' on web forums.
Hobbyist electronics people are strange. Wake up and give Mouser hell if they send you faked goods!
The CH340G is really a nice and cheap chip. And I'm starting to see it in more established American designs too (as opposed to Chinese designed electronics).
Actually, that's a pretty good idea. Anyone who works in supply chain, switch to ordering directly from FTDI. They'll soon realize the folly in this decision.
Safety development is serious business. You cannot justify your "I want everything as cheap as possible, counterfeit or not" attitude with some hallucinated safety risk.
I agree. I don't want to put counterfeits in my product.
Now, show me FTDI's standards documents that indicate how to identify and test for fakes. (Hint: they don't)
As far as I understand, this "behaviour" is totally deterministic and certain. You immediately notice the problem in any test system.
Don't believe that safety-critical devices are allowed to install some drivers willy-nilly!
FTDI does not provide any guide lines to third parties how to test whether their chips are counterfeit or not.
The only way to test it is trying to use it with FTDI's Windows driver, and FTDI randomly changes the both the detection criteria, and the action done on detecting a counterfeit chip – sometimes it bricks them, sometimes it sends gibberish, you have no way of knowing beforehand. FTDI doesn't even guarantee that this behaviour is deterministic!
And when QA validates them on a set of systems that happen to be legit and ships it to systems that happen to have counterfeits?
You seem to be arguing in this thread with a false dilemma between EITHER we must accept counterfeiting OR we must brick the chips, but there are in between measures that are way safer.
Prior art: Several versions of Windows have been able to detect if they were "genuine". Non-genuine windows did not brick their machine, or destroy themselves. Quick googling suggests it blocks you from getting updates, and pops up with links to a page on Microsoft where you could properly license it with some discount. That exact solution may not apply here, but there are options other than destroying hardware that is carrying your name.
(I mean, this isn't even good for FTDI... how many customers will never find out about this and simply learn that "FTDI chips spontaneously die a lot"? Not the brand experience I'm looking for!)
That is indefensible, regardless of whether it's right or wrong to use counterfeit parts.
So what if all of your preproduction systems have a genuine FTDI chip in them, and many of your millions of deployed production systems have counterfeits that you don't know about? That'll be exciting.
Quality is a matter of defense in depth. You can't rely on your preproduction system running the exact same way as production. You strive for consistency, but ultimately each chip in each computer is a unique physical object made with different silicon crystals, and being identical is impossible. You want a system that's robust against a variety of subtle differences.
FTDI is just doing their small bit to make everything just a little more fragile and unpredictable where their chips are concerned, and as such their products ought to be shunned.
I agree with your premise, but in this case, for a medical device it would also be a Quality Systems failure. Any change in a component is scrutinized and analyzed for impact. You have no idea how many times (as a software dev for medical devices), I've had someone from Manufacturing or Purchasing come to ask me "if we change (trivial part X) to a new vendor, what can go wrong and how can we test it?" as a precursor to executing a Change Plan.
I'm not kidding. Even something as seemingly trivial as changing the type of paint used on an enclosure can trigger weeks or months of analysis depending on what's in that enclosure.
Safety-critical and safety-related applications are a totally different game than what most HNers are used to!
It's clearly unsafe to not wear a seatbelt, but it's also clearly wrong to build a device into cars that kills occupants that get in a crash if they aren't wearing one.
As an embedded medical devices engineer, I know you are exactly right. For safety-critical devices, control of the supply chain is beyond good practice, it's required by federal law, precisely so bad actors can't interfere with peoples' lives. The long list of requirements around approving a vendor are tiring and result in epic stories like the $500 toilet seat, etc., but they prevent stuff like this FTDI debacle from happening. You know it's going to be a toilet seat when the box arrives.
The medical device industry is a massive cultural shift from the majority of the HN crowd (e.g. startups and cloud services). In the world of PCs and servers, disruption is, literally, the name of the game. In IEC62304 land though, everything has to be on the straight, narrow and predictable path. This is why medical devices are expensive, laggy and not very startup-compatible. The FDA's system is actually more secure than Europe's. Take that, socialized medicine!
So it's not always wild and fun here in medical-land. It's like being a cop vs. a cowboy. You're not paid to sling your guns, but to de-escalate. But thank the conservative practices next time your elderly or congenitally defective family members found themselves in the hospital!
We already have fitness devices that can communicate with a PC. Is it really unthinkable that the next batch of medical devices will do something similar? For example, a wearable sensor to continuously measure your insulin levels?
Will you be using an FTDI chip in such consumer devices?
Yes, exactly.
I used to work at a sub-contractor for a large manufacturer of medical equipment, and all the systems we dealt with were like that. The device would run a very small embedded OS but would have a serial port for talking to a PC for firmware development, firmware updates, logging, diagnostics, etc. Their older stuff used real hardware serial ports, but their newer systems (~6-7 years ago now) were moving to virtual USB/FTDI serial ports, with an FTDI chip included in the embedded system.
These tricky FTDI drivers would absolutely have the potential to brick and/or alter the operation of such a device; it's not far-fetched or a flight of fancy at all.
I have a special interest in this thread/issue because I have recently been contacted by that manufacturer regarding one of these FTDI-using systems which has recently begun to exhibit new problems. I haven't started looking into that yet, and I don't know where it will lead, but I'll have to bear in mind the possibility of deliberate driver-based monkey-business now.
Instead, 'How do I know that the devices I bought up to 3 years ago don't have a "detected counterfeit" chip and get nuked by a future FTDI driver update?'
Or, 'How do I keep from getting malware and other bad actor software in via Windows Updates?'
And you also glossed over "FTDI compatible" chips. They too exist, and do not claim to be a legit FTDI (the markings on the case are what make a counterfeit, not the underlying silicon). Yet the FTDI driver disables them all, in one way or another.
You assume I'm talking purely about the hobbyist market: anyone who pays for a usb FTDI adapter at $1.50 should know it's likely a counterfeit.
But for a normal part? It's lousy.
But there's no way for an end-user to do this. And since they're the ones being punished by the bricking (any supply chain movement is a second-order effect driven by upset customers), and since I lack the technical capacity to identify a knock-off, then my most rational course of action is to avoid anything that might be counterfeit . . . by insisting on a totally different chip.
Not having FTDI in your design is a feature. And that's easily checked by plugging the device into a USB port and looking at the VID/PID.
FTDI has a death wish.
I built that board into a piece of test equipment that's likely to be used for 5 or 10 years. Fortunately this whole saga happened while I was still developing it - if their chip bricking driver had been released a year later, I'd probably not have known about it. Someone would connect the test PC to Windows Update in 3 years time, and the device would stop working.
Counterfeit chips are a reality, and not one that people building devices on a small scale can properly mitigate against. Not buying chips on alibaba is common sense, but not buying pre-built modules from Farnell? If you're not going to buy them from Farnell, where are you going to buy them from?
But why do you simply accept that? Have you even complained to Farnell?
Read the sundry web forums, very few people complain to their distributor. Everyone bitches about FTDI.
And that's what's really bugging me here. In the FTDI case the problem has obviously gotten out of hand. I can totally understand that the manufacturer wants to get tougher.
Why not just pop up a small window with a message "Hey, this product seems to contain counterfeit chips. Please tell us where you bought it so that _we_ can take care of the problem."
I'd prefer it if FTDI weren't utter douchebags around this whole ordeal. I understand they have to make money, but since when is it a problem when devices are API-compatible with existing device drivers? As far as I'm concerned, this is a rather common and generally beneficial thing.
FTDI do not provide any useful traceability systems. Rather than providing their customers with a reliable means to identify genuine parts, they have hugely increased the risk posed to their customers by counterfeit parts.
http://www.publicintegrity.org/2011/11/07/7323/counterfeit-c... http://spectrum.ieee.org/computing/hardware/counterfeit-chip...
Popular moralism in a nutshell. "I can steal from big companies because they're evil! But if someone even samples one of my songs I'm lawyering up!"
There's something almost psychopathic about how people just rationalize amorality because the entity they're attacking from is "big" or "different" Or "the other." I guess the mp3 wars are over with Google Music, Spotify, Apple Music, etc but for a long time it was creepy to hear these justifications from otherwise normal adults. It made you think, "What if they see me and my interests as 'the other'? What would they do without a conscience to stop them?"
And that's the rub: if i get a legit ftdi chip, I have a high level of trust that it will do what it says, and there's tons of documentation.
Even after seeing them pull a stunt like this in their drivers?
[1] https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux....
The manufacturer's website is http://wch.cn
Their drivers are here: http://wch.cn/index.php?s=/page-search_content-keyword-USB%E...
They don't appear to be open source, but I believe they are signed drivers for both Windows and OSX.
At least on recent OSX the OS CDC one seems more robust than the FTDI provided one if you pull a cable while it's running. (I assume it's a genuine chip, who knows!)
The best Windows ever keeps getting better; or something.
Also, businesses typically use WSUS, where you need to intentionally whitelist driver updates.
If you have a CNC machine set to get all Windows Update from MS without oversight and testing, well, you're doing it wrong. I suspect a lot of "GUISE MY CLIENTS ALL HAVE DOWNED MACHINES THIS MORNING" is straight-up bullshit. In my experience, CNC machines are sacred cows and never, ever updated, let alone ever get driver updates. Hell, it isn't even patch Tuesday.
This does punish the hobbyist who just bought some toy and WU grabbed the latest driver. The world's manufacturing isn't going down this morning. Lets stop being naive.
Also, it's a little late for driver rollback if your hardware is already bricked.
Here are all the drivers for "proprietary" USB UARTs that are currently supported by Linux: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux....
Here's the class compliant "Abstract Control Model driver for USB modems and ISDN adapters": https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux....
/*
* Certain versions of the official Windows FTDI driver reprogrammed
* counterfeit FTDI devices to PID 0. Support these devices anyway.
*/
#define FTDI_BRICK_PID 0x0000Here's the old knowledge base article for the fix that eventually patched usbser.sys:
I reproduced the issue by connecting two FTDI serial ports, opened each /dev/cu.usbserial* device node with a screen session, and piped War and Peace.txt through at 115200 baud. Closing the screen session on the read end would cause ALL usb devices connected to the Mac to cease functioning.
Personally, I would love to have a reliable way to detect counterfeit chips. For FTDI I do! Now it is trivial to lot test my chips: Just put one (or a few depending on your level of quality) on a test jig and use the latest driver with it.
Contrast that with one of these other generic pieces of silicon. Is the argument that since the drivers are generic it doesn't matter if counterfeits make it into your products? Of course it still matters! Every single datasheet value that you used in your design is now out the window.
FTDI should absolutely be more forthcoming with their counterfeit detection process. It is going to be a tough call next time I need a USB-Serial chip. FTDI has a great product and documentation, but a future update might break my device if it used counterfeit components that were so far undetected.
Oh and it's not reliable because you might get one that's accepted by the current driver but gets bricked in the future
This would be akin to the government poisoning cocaine shipments with anthrax to try to stop the drugs from flowing in. You won't stop anything, you'll only hurt "innocent" people.
A better analogy would be the government enforcing an import ban by adding sugar to the petrol imported from specific countries.
Here is the patch for anyone who's interested, http://kiguino.moos.io/2014/12/31/how-to-use-arduino-nano-mi...
I now have to test the Flow control and the parity/frame... signals so I hope I wont have to buy one.
Before the 1st FTDIGate, as a guy who has implemented user-space drivers for the most common USB to serial converters my opinions about the FTDI were quite good (from an engineering standpoint I really like the solution they use to send the CTS,Parity status, Break... in a two bytes packet every 40ms which it is a good simulation of a serial port instead of having to poll sending control commands) but now I would recommend to avoid them.
From my humble experience I would recommend CP2102, they work fine (and have a nice documentation for driver developers). The CH340/CH341 is real pain.
It is always interesting to see the mechanics at play too, people who get counterfeit chips are more often (but not always) people who have released all "quality" requirements in order to achieve the lowest possible price. As being price preferred they put themselves at risk of getting substandard parts, and then when they get parts that don't work or work anomalously, they frame that problem as someone else's problem rather than their own choice.
In the referenced forum post you have a person using "Chinese clone" Arduino nanos which happen to have chips on them that report as FTDI USB to serial converters but are in fact something else. So drop the vendor or have the vendor write their own USB driver for windows but why hate on FTDI for identifying the bogus chip and refusing to work with it?
Already a lot of counterfeit users of FTDI (i.e. knockoff Arduinos and cheap "VAG-COM KKL" auto diagnostic cables) are switching to CH340 instead of buying real FTDI.
I'm hoping we can train consumers to not buy things based on "lowest price" without understanding what was done to achieve that price.
The driver situation for CH340 seems a bit sketchy. Whenever I've considered buying cheap Arduino Uno R3 clones via aliexpress.com, but then first went searching for CH340 OS X drivers, all I've found have been drivers on random sites whose provenance seems to be "I found this somewhere". Often these are unsigned drivers so I'd have to disable driver signing to use them, although last time I looked there was a set of signed drivers floating around.
For Arduino knockoffs, I prefer something that uses the same hardware that a genuine Arduino would use, or something that works with the CDC driver that comes with the OS. For Uno R3, this is the clone I'm using for development [1]. It uses an ATmega16u2 to handle the USB, which is what a genuine Uno R3 uses.
[1] http://www.amazon.com/gp/product/B00P2FX9WY?psc=1&redirect=t...
The only thing the counterfeiters are losing is one of the chips they are fabricating. They're fabbing other fakes, they'll move on. And they can always try to push their pile of fake FTDI parts (it's sunk cost, and you can always find a sucker).
FTDI is punishing everyone except the bad guys.
Why do you think that? A lot of players in the supply chain are enabling the counterfeiting. It's going to be very difficult for any of them to move inventory on those counterfeit chips.
And I'm sorry, but I cannot see fit to blame FTDI for not wanting to talk to counterfeit chips.
We don't absolve people who buy diamond jewelry of all responsibility for buying 'blood diamonds' - we say that consumers have to be aware of where diamonds come from and hold jewelers responsible for sourcing diamonds carefully.
I think the really unfortunate lesson for small parts suppliers like FTDI is that if they really want to protect their IP from Chinese counterfeiters free-riding on their driver development work, they need to begin building designs that require software uploads, binary blobs, and key exchanging, none of which are good for open hardware development and open source software.
Then there is no innocent person in existence and the term becomes meaningless. So, to avoid having to fully deprecate the term, we veto the above definition.
I'm not sure what point you're making regarding the infeasibility of detecting counterfeit chips. It's not like these chips were bricked by accident. FTDI is specifically going out of its way to exploit bugs in these clones to brick them. So it looks like they have the detection thing pretty well covered.
You'll note that the opensource linux drivers works just as well with the clones. That's because they do not expend extra effort to make them not work.
EDIT: As a practical example, consider the case of I2C. This is a proprietary NXP protocol, and you have to pay to get slave addresses. So instead people use "Two Wire Interface", which is not I2C but is electronically indistinguishable. The only way to detect counterfeit use of I2C is looking at the packaging/documentation.
and then, if I use "compatible", am I still a counterfeit? And why does my device deserve to be destroyed?
You what? But there's only a hundred of them.