Teensy USB driver "hijacks" Samsung Galaxy S4 phone USB function?
- Thread starter timg11
- Start date
- Status
PaulStoffregen
Well-known member
Perhaps reinstall the Samsung driver?
I've helped people with problems accessing samsung phones via USB from their PCs many many times and it has often been a fairly miserable fight with daft drivers and stupid stupid kies - kies is even worse than itunes (nb: while since I checked) and coming from me (ilong itime apple ihater) that is really saying something.
Teensy has never presented a challenge regarding USB functionality till damaged or loaded with fairly bad code. To the best of my understanding of such things it uses very relevant device IDs etc.
My conclusion: I'd blame Samsung for this one.
I was advising people to get themselves HTC phones but their nonsense factor is growing too and I'm beginning to think my next phone might be someone's second hand nokia torch or something
Teensy has never presented a challenge regarding USB functionality till damaged or loaded with fairly bad code. To the best of my understanding of such things it uses very relevant device IDs etc.
My conclusion: I'd blame Samsung for this one.
I was advising people to get themselves HTC phones but their nonsense factor is growing too and I'm beginning to think my next phone might be someone's second hand nokia torch or something
PaulStoffregen
Well-known member
Here's some lengthy info about how the "Serial Driver" works. Hopefully this can clear up some confusion, or serve as a reference for future questions.
When you run the Teensyduino installer on Windows (and you don't click the button to skip driver install), or the stand-alone Serial Installer, it adds an INF file to Windows.
This INF is only needed for USB Serial to work. Since Teensy is not natively USB Serial, you can still reprogram it without the INF. All programming by Teensy Loader is done using HID protocol, not Serial. The HID drivers are built into Windows and automatically recognize all HID devices. You can even use the Arduino Serial Monitor if Teensy is programmed with any of the Tools > USB Type options that don't have "Serial", since it emulates a serial connection using HID in those modes. The INF is only needed to use the Arduino Serial Monitor when Teensy is programmed with Tools > USB Type set to an option with "Serial", and to use other software than communicates with COM ports.
All Arduino brand boards communicate as Serial. USB Serial has much higher bandwidth than HID It's also widely used by lots of other software. For these reasons, the Tools > USB Type menu defaults to "Serial", and of course the installer attempts to add the INF file (unless you click the button to skip installing it).
Even though we're calling this a "driver", the INF file is really just text-only instructions to Windows, to tell it with drivers to load. The actual drivers are USBSER.SYS and SERENUM.SYS, which are files from Microsoft included in all copies of Windows. Unfortunately, more precise terminology to distinguish between the actual executable driver code and mere text-only instructions regarding which driver to use does not seem to exist. Normally, this distinction is a subtle point people don't need to know, but if you're trying to understand strange issues seen on Windows, it can be important to understand the details.
Many USB serial devices exist in the world. If you're used to only Windows, you might believe they're all different, since each seems to require its own driver. However, there are only 3 widely used protocols/drivers: CDC-ACM, Prolific, and FTDI. The later 2 are semiconductor manufacturers who make dedicated USB to Serial converter chips, which have their own proprietary communication protocols created by those 2 companies. CDC-ACM is an open standard published by the USB Implementers Forum, Inc (USB-IF, the non-profit group which publishes official USB standards).
When your computer detects a new USB device (called "enumeration" in USB lingo), several small blocks of data (called "descriptors") are read. The first descriptor contains numbers to identify the device. The most familiar of these are the Vendor ID and Product ID. For products with their own specific drivers, like the FTDI and Prolific chips, these are meant to be used.
Three less familiar numbers in the main device descriptor are Class, Subclass and Protocol. When a device uses one of the many standard device class protocols, these numbers are meant to identify the device by the communication protocol it uses, rather than who made it. For example, HID devices uses Class=3, with the other numbers either zero or certain values if very specific keyboard and mouse data are used. Class=2 is defined by the Communication Device Class (CDC) specification. With CDC, Subclass=2 and Protocol=1 refers to Abstract Control Model (ACM), which is a generic serial device, which would use "AT commands" if connected to a modem. Teensy and nearly all software-implemented USB Serial devices use the CDC-ACM protocol, as defined in this official standard from the USB-IF.
Windows, Linux and Macintosh have all long provided the drivers for CDC-ACM devices. On Widows, the actual driver is USBSER.SYS. The Linux kernel developers and Apple's engineers decided to closely follow the USB standards practice. When a device is detected with Class=2, Subclass=2, Protocol=1 (indicating CDC-ACM), they load their driver automatically. Microsoft, unfortunately, only loads drivers automatically for just a few standard USB classes (HID, Mass Storage). Even through CDC is among the oldest USB standards and USBSER.SYS has existed since Windows 98SE & 2000, Windows does not ship with an INF that causes USBSER.SYS to load automatically. Microsoft expects each vendor to ship an INF file and installer program, even if they're merely using standard protocols like CDC-ACM that only require Microsoft's on "in box" (automatically included as part of Windows) driver.
Microsoft recommends writing INF files to use the Vendor ID and Product ID numbers. Nearly everyone copies the same INF (or one of a small collection) and merely changes these 2 numbers and the string for their company name and product name. Microsoft calls this "Hardware-Id" matching. When Windows searches all its INFs to figure out which driver to load, a Hardware-Id match is the highest priority, so publishing an INF this way guarantees the driver you want will load for your specific device, and the strings from its INF will appear in the Windows Device Manager.
Early in Teensy's development (late 2008), I decided to try "Compatable-Id" matching, which uses the Class, Subclass and Protocol numbers instead of Vendor ID and Product ID. Matching this way allows a single INF to match to USB Serial regardless of the Product ID number. It also allows composite (multi-function) devices to match automatically, which specifying which of the multiple interfaces is serial. Since 2008, I have planned to someday create far more USB types. I've also dreamed, since early on, to create a GUI-based tool (and far more flexible USB code on the Teensy side) that lets you pick nearly any combination of those many interfaces. I still want to eventually do this someday, and Compatable-Id matching is much better way than publishing an INF with a huge list of ID and interface number combinations, which would need to be updated as the code develops.
Of course, a downside to Compatable-Id matching in the Teensy USB Serial INF file is the possibility of matching to other non-Teensy devices. In nearly all cases, they just work, because it is a standard USB protocol published by the USB-IF and it's merely loading Microsoft's own USBSER.SYS driver.
Because Hardware-Id matching is at a higher priority as Windows searches for the driver to load, simply installing the original vendors INF or driver will override the Teensy INF with Compatable-Id. Well, at least it will on a Windows system that's working correctly.
Still, occasionally I hear requests for a way to remove the "driver" Teensyduino installs. The easiest and safest way is to follow this Adafruit tutorial to show hidden devices. Then you can right-click to remove the device, and check the option to completely remove the driver files. Letting the Windows Device Manager do the work is the safest way.
The dangerous way involves finding the .INF in the hidden c:\windows\inf folder. The exact text to search inside the files is:
Simply find the .INF file(s) with this text and delete them and any related file (eg, a file with the same name but different extension, like .PNF). Unfortunately, Windows automatically renames the files as it installs them to this directory, so you can't simply look for a specific name. It'll be different on each unique Windows system.
The installer uses the WIN32 function SetupCopyOEMInf to install the INF. I've seen documentation on Microsoft's site for SetupUninstallOEMInf. So far, it seems to be unsupported by the MinGW tools I use to create the installer. I'm hopeful it will someday become supported, so I'll be able to make an uninstaller that calls this WIN32 function.
When you run the Teensyduino installer on Windows (and you don't click the button to skip driver install), or the stand-alone Serial Installer, it adds an INF file to Windows.
This INF is only needed for USB Serial to work. Since Teensy is not natively USB Serial, you can still reprogram it without the INF. All programming by Teensy Loader is done using HID protocol, not Serial. The HID drivers are built into Windows and automatically recognize all HID devices. You can even use the Arduino Serial Monitor if Teensy is programmed with any of the Tools > USB Type options that don't have "Serial", since it emulates a serial connection using HID in those modes. The INF is only needed to use the Arduino Serial Monitor when Teensy is programmed with Tools > USB Type set to an option with "Serial", and to use other software than communicates with COM ports.
All Arduino brand boards communicate as Serial. USB Serial has much higher bandwidth than HID It's also widely used by lots of other software. For these reasons, the Tools > USB Type menu defaults to "Serial", and of course the installer attempts to add the INF file (unless you click the button to skip installing it).
Even though we're calling this a "driver", the INF file is really just text-only instructions to Windows, to tell it with drivers to load. The actual drivers are USBSER.SYS and SERENUM.SYS, which are files from Microsoft included in all copies of Windows. Unfortunately, more precise terminology to distinguish between the actual executable driver code and mere text-only instructions regarding which driver to use does not seem to exist. Normally, this distinction is a subtle point people don't need to know, but if you're trying to understand strange issues seen on Windows, it can be important to understand the details.
Many USB serial devices exist in the world. If you're used to only Windows, you might believe they're all different, since each seems to require its own driver. However, there are only 3 widely used protocols/drivers: CDC-ACM, Prolific, and FTDI. The later 2 are semiconductor manufacturers who make dedicated USB to Serial converter chips, which have their own proprietary communication protocols created by those 2 companies. CDC-ACM is an open standard published by the USB Implementers Forum, Inc (USB-IF, the non-profit group which publishes official USB standards).
When your computer detects a new USB device (called "enumeration" in USB lingo), several small blocks of data (called "descriptors") are read. The first descriptor contains numbers to identify the device. The most familiar of these are the Vendor ID and Product ID. For products with their own specific drivers, like the FTDI and Prolific chips, these are meant to be used.
Three less familiar numbers in the main device descriptor are Class, Subclass and Protocol. When a device uses one of the many standard device class protocols, these numbers are meant to identify the device by the communication protocol it uses, rather than who made it. For example, HID devices uses Class=3, with the other numbers either zero or certain values if very specific keyboard and mouse data are used. Class=2 is defined by the Communication Device Class (CDC) specification. With CDC, Subclass=2 and Protocol=1 refers to Abstract Control Model (ACM), which is a generic serial device, which would use "AT commands" if connected to a modem. Teensy and nearly all software-implemented USB Serial devices use the CDC-ACM protocol, as defined in this official standard from the USB-IF.
Windows, Linux and Macintosh have all long provided the drivers for CDC-ACM devices. On Widows, the actual driver is USBSER.SYS. The Linux kernel developers and Apple's engineers decided to closely follow the USB standards practice. When a device is detected with Class=2, Subclass=2, Protocol=1 (indicating CDC-ACM), they load their driver automatically. Microsoft, unfortunately, only loads drivers automatically for just a few standard USB classes (HID, Mass Storage). Even through CDC is among the oldest USB standards and USBSER.SYS has existed since Windows 98SE & 2000, Windows does not ship with an INF that causes USBSER.SYS to load automatically. Microsoft expects each vendor to ship an INF file and installer program, even if they're merely using standard protocols like CDC-ACM that only require Microsoft's on "in box" (automatically included as part of Windows) driver.
Microsoft recommends writing INF files to use the Vendor ID and Product ID numbers. Nearly everyone copies the same INF (or one of a small collection) and merely changes these 2 numbers and the string for their company name and product name. Microsoft calls this "Hardware-Id" matching. When Windows searches all its INFs to figure out which driver to load, a Hardware-Id match is the highest priority, so publishing an INF this way guarantees the driver you want will load for your specific device, and the strings from its INF will appear in the Windows Device Manager.
Early in Teensy's development (late 2008), I decided to try "Compatable-Id" matching, which uses the Class, Subclass and Protocol numbers instead of Vendor ID and Product ID. Matching this way allows a single INF to match to USB Serial regardless of the Product ID number. It also allows composite (multi-function) devices to match automatically, which specifying which of the multiple interfaces is serial. Since 2008, I have planned to someday create far more USB types. I've also dreamed, since early on, to create a GUI-based tool (and far more flexible USB code on the Teensy side) that lets you pick nearly any combination of those many interfaces. I still want to eventually do this someday, and Compatable-Id matching is much better way than publishing an INF with a huge list of ID and interface number combinations, which would need to be updated as the code develops.
Of course, a downside to Compatable-Id matching in the Teensy USB Serial INF file is the possibility of matching to other non-Teensy devices. In nearly all cases, they just work, because it is a standard USB protocol published by the USB-IF and it's merely loading Microsoft's own USBSER.SYS driver.
Because Hardware-Id matching is at a higher priority as Windows searches for the driver to load, simply installing the original vendors INF or driver will override the Teensy INF with Compatable-Id. Well, at least it will on a Windows system that's working correctly.
Still, occasionally I hear requests for a way to remove the "driver" Teensyduino installs. The easiest and safest way is to follow this Adafruit tutorial to show hidden devices. Then you can right-click to remove the device, and check the option to completely remove the driver files. Letting the Windows Device Manager do the work is the safest way.
The dangerous way involves finding the .INF in the hidden c:\windows\inf folder. The exact text to search inside the files is:
Code:
%DEVNAME%=DriverInstall,USB\Class_02&SubClass_02&Prot_01Simply find the .INF file(s) with this text and delete them and any related file (eg, a file with the same name but different extension, like .PNF). Unfortunately, Windows automatically renames the files as it installs them to this directory, so you can't simply look for a specific name. It'll be different on each unique Windows system.
The installer uses the WIN32 function SetupCopyOEMInf to install the INF. I've seen documentation on Microsoft's site for SetupUninstallOEMInf. So far, it seems to be unsupported by the MinGW tools I use to create the installer. I'm hopeful it will someday become supported, so I'll be able to make an uninstaller that calls this WIN32 function.
Thanks. That is very informative. And it also explains why Linux does a "better" job of handling USB. I just can't understand why Microsoft would cut corners like this and cause so many developers grief. I had hoped they were more savvy and had more respect for standards (which exist for the reason of preventing problems like this). Sigh.
Hello Paul,
I develop various stuff that uses CDC/ACM and I use Hardware-Id in my .inf files. The installer I use for these is based on dpinst.exe. The drivers are not signed (yet).
However, even though everything used to work well, since I installed Teensyduino every new CDC/ACM device I plug gets identified as a Teensy USB serial port, despite having Hardware-Id .inf installed... as if your Compatible-Id .inf rules were interpreted as being higher priority.
Uninstalling the Teensy .inf (safe way) fixes the problem (=new devices will be matched with their Hardware-Id .inf).
This problem is of importance to me as I use the name of the device to identify it in the test and update applications. For better user experience, I want the update to be as automated as possible, yet on any computer where the Teensy .inf is installed, the application will not be capable of finding the device by itself...
Do you have any idea if there are ways to tweak priority? Is it possible that the fact that my drivers are not signed give them a lower priority than yours?
Thanks.
Xevel
PaulStoffregen
Well-known member
Hardware-Id is supposed to have higher priority.
But unsigned drivers get the very lowest, second-class treatment on modern versions of Windows. You really need to sign your driver.
But unsigned drivers get the very lowest, second-class treatment on modern versions of Windows. You really need to sign your driver.
PaulStoffregen
Well-known member
Does your device still work when Windows uses the Teensyduino driver?
Ultimately, the "driver" is just an INF file telling Windows to use its own USBSER.SYS and SERENUM.SYS drivers.
Ultimately, the "driver" is just an INF file telling Windows to use its own USBSER.SYS and SERENUM.SYS drivers.
Oh yeah, they still do work nicely with the Teensyduino "driver", as they are very simple CDC/ACM devices. The question was more about enumerating with the right name - and thus being recognizable by the automatic update app and the user as being my device and not yours.
I'll do whatever it takes to sign the drivers ASAP and report. I have nearly no doubt that it's all there is to my problem.
Thanks again.
I'll do whatever it takes to sign the drivers ASAP and report. I have nearly no doubt that it's all there is to my problem.
Thanks again.
I was wondering why every CDC device now appears as "Teensy USB Serial", even when it isn't. I consider this behaviour a bug. At least when installing Teensy, there should be a dialog asking if the user wants the Teensy driver to hijack other USB serial ports.
I've uninstalled the Teensy driver, lesson learnt!
I've uninstalled the Teensy driver, lesson learnt!
PaulStoffregen
Well-known member
Yup, that's exactly how it's supposed to work. Hardware-Id matching takes precedence over Comptible-Id matching.
Regarding "consider this behaviour a bug", starting with Windows 7, unsigned drivers are terribly problematic. Nobody should be shipping any unsigned drivers anymore.
Fortunately, these dark times of needing a "driver" simply to use USBSER.SYS, which is part of Windows, will soon be coming to an end. Windows 10 loads USBSER.SYS automatically, using Comptible-Id matching.
Regarding "consider this behaviour a bug", starting with Windows 7, unsigned drivers are terribly problematic. Nobody should be shipping any unsigned drivers anymore.
Fortunately, these dark times of needing a "driver" simply to use USBSER.SYS, which is part of Windows, will soon be coming to an end. Windows 10 loads USBSER.SYS automatically, using Comptible-Id matching.
PaulStoffregen
Well-known member
You don't need to pay Microsoft anything to sign your drivers! Well, other than the price of Windows and whatever other software you normally buy from them.
But you do need to obtain a code signing certificate. Mine is from Comodo, which you can see if you look at the properties on Teensy Loader or Teensyduino or other Windows files I've published, and click the button to view the certificate. To sign things, you need your own certificate. It's much like enabling SSL encryption on websites, where the cert proves whoever's on the other end of the encryption is who they say they are (or at least that you managed to convince Comodo or some other certificate authority that you are).
Unlike cheap SSL certs, code signing certificates are still quite expensive. Also like SSL certs, you pay full retail if you buy directly from companies like Verisign, Comodo or GeoTrust, but you can get a bargain if you buy through a reseller. I've been using Tucows, for absolutely no reason other than they had the lowest price last time I looked. If anyone finds someone selling code signing certs cheaper, please let me know? I believe I still have a couple years left before renewing...
Once you get the cert, and get it saved into the right format, Microsoft's free Windows Driver Kit has the code signing tool. It's a command line program, with a "/h" help option. Actually, for drivers, as I recall there's a 2 step process, where the first checks everything and makes an unsigned catalogue file, which you then sign with the other program. I haven't actually done this recently, so online documentation will be far better than anything I can type in this message.
Anyway, the point is you get the signing tools for free as part of the WDK download. It's a gigantic download, over a gigabyte as I recall, and you have to install the whole thing just to get those little command line utilities. But it's all free. The only part that costs money is the certificate, and you get that from a certificate authority like GeoTrust, Comodo, Thawte, Verisign, or maybe a couple others I can't recall.
Microsoft also offers a WHQL program. Long ago, you had to actually send them hardware, and there were horror stories about all sorts of nasty Microsoft behavior. Quite a long time ago, they changed it to self-certification using free tools they publish, and a flat fee of $250 per operating system, and as I recall, you got both 32 and 64 bit as part of the same $250, but consumer and server editions were separate. There's a lot of misinformation suggesting WHQL is insanely expensive, and indeed it might have been before the self-test and flat fee.
In the very old days, WHQL was how you get a signature, so there's still a lot of outdated info online that claims you can't sign stuff youself. That info is dead wrong. I signed the Teensy USB Serial INF, and Teensy Loader and the Teensyduino installer. The only money I've ever paid was to Tucows, for a discounted price on the certificate from Comodo.
But you do need to obtain a code signing certificate. Mine is from Comodo, which you can see if you look at the properties on Teensy Loader or Teensyduino or other Windows files I've published, and click the button to view the certificate. To sign things, you need your own certificate. It's much like enabling SSL encryption on websites, where the cert proves whoever's on the other end of the encryption is who they say they are (or at least that you managed to convince Comodo or some other certificate authority that you are).
Unlike cheap SSL certs, code signing certificates are still quite expensive. Also like SSL certs, you pay full retail if you buy directly from companies like Verisign, Comodo or GeoTrust, but you can get a bargain if you buy through a reseller. I've been using Tucows, for absolutely no reason other than they had the lowest price last time I looked. If anyone finds someone selling code signing certs cheaper, please let me know? I believe I still have a couple years left before renewing...
Once you get the cert, and get it saved into the right format, Microsoft's free Windows Driver Kit has the code signing tool. It's a command line program, with a "/h" help option. Actually, for drivers, as I recall there's a 2 step process, where the first checks everything and makes an unsigned catalogue file, which you then sign with the other program. I haven't actually done this recently, so online documentation will be far better than anything I can type in this message.
Anyway, the point is you get the signing tools for free as part of the WDK download. It's a gigantic download, over a gigabyte as I recall, and you have to install the whole thing just to get those little command line utilities. But it's all free. The only part that costs money is the certificate, and you get that from a certificate authority like GeoTrust, Comodo, Thawte, Verisign, or maybe a couple others I can't recall.
Microsoft also offers a WHQL program. Long ago, you had to actually send them hardware, and there were horror stories about all sorts of nasty Microsoft behavior. Quite a long time ago, they changed it to self-certification using free tools they publish, and a flat fee of $250 per operating system, and as I recall, you got both 32 and 64 bit as part of the same $250, but consumer and server editions were separate. There's a lot of misinformation suggesting WHQL is insanely expensive, and indeed it might have been before the self-test and flat fee.
In the very old days, WHQL was how you get a signature, so there's still a lot of outdated info online that claims you can't sign stuff youself. That info is dead wrong. I signed the Teensy USB Serial INF, and Teensy Loader and the Teensyduino installer. The only money I've ever paid was to Tucows, for a discounted price on the certificate from Comodo.
PaulStoffregen
Well-known member
Also, when/if you sign stuff, there's an option to use a timestamp server. Use it.
If you skip that step, then your signature expires when your certificate expires. Certificates always expire, supposedly for security purposes, but since companies like Comodo pretty much rubber stamp issuing new ones, nobody can convince me the real reason for expiration is anything other than getting you to keep paying up.
The timestamp option prevents your signature from expiring when your certificate expires. You can't sign anything new (the timestamp server is only there to prevent you from setting your PC's clock back to keep signing things without paying more for a new cert), but it does create a signature that does not go bad when your cert expires. It's easy to neglect this step, as the Arduino guys did when first signing their stuff, if you don't know about it. It's merely an extra option on the command line, to create a durable signature... as long as you've paid the certificate tax!
If you skip that step, then your signature expires when your certificate expires. Certificates always expire, supposedly for security purposes, but since companies like Comodo pretty much rubber stamp issuing new ones, nobody can convince me the real reason for expiration is anything other than getting you to keep paying up.
The timestamp option prevents your signature from expiring when your certificate expires. You can't sign anything new (the timestamp server is only there to prevent you from setting your PC's clock back to keep signing things without paying more for a new cert), but it does create a signature that does not go bad when your cert expires. It's easy to neglect this step, as the Arduino guys did when first signing their stuff, if you don't know about it. It's merely an extra option on the command line, to create a durable signature... as long as you've paid the certificate tax!
Source_Error
New member
Is there a way to run your installer for the inf quietly? I've tried some common flags and they all throw an error.
PaulStoffregen
Well-known member
No, sorry, the installer doesn't have any optional command line parameters or a silent mode.
jeremy-daily
New member
I'm fairly new to the forum, but thought this was the most applicable spot to post a comment from what I experienced this morning. The issue was everything was working fine with Windows 7 64-bit, Teensyduino 1.30, Arduino 1.6.11, and a Teensy 3.2. I was working happily along and had uploaded successfully a few times. After some code tweaks the Teensy Loader does it's thing on a new board and the USB Serial drivers fail to install. The most strange part was there was no identification of the board in the little windows troubleshooting dialog where it says "failed." It took a couple hours, but I ended up using a different computer to flash a different (known working) sketch onto the Teensy to fix it. This experience helped me understand that poorly written code can affect the Serial output from the Teensy and affect its functionality as a CDC/ACM device on Windows.
- Status