Where have all the COM Ports Gone? - How enumerating COM ports led to me finding a ?misplaced? Microsoft tool

Published: 2011-01-24
Last Updated: 2011-01-25 03:39:34 UTC
by Rob VandenBrink (Version: 2)
14 comment(s)

In my work, I connect to routers switches, firewalls and other network gear daily.  Since laptops no longer come with serial ports (who exactly decided that this was a good idea?), this means that I use USB to serial port adapters.  In fact, I've got a nice collection of these things in the laptop bag - some work better than others for various functions (some do a better job at serial packet capture for instance), but the one thing most of them have in common is that when you plug them in, they'll pick some random serial port to use.

So if I'm working on a router or switch, I plug a dongle in, and then have to fire up windows device manager to go hunting and find out which serial port it got assigned.  This is an exercise of several mouse clicks. While I've gotten pretty quick at this over the years, frankly I'm tired of it.

My thought was - there's got to be a way to do this from the command line with WMIC.  WMIC gives you a unique access to the internals of Microsoft Windows, is available for or is native to all modern Windows Platforms, and is usually very simple to figure out.  Not today though, after 20 minutes of effort, one script prints the first COM port, the other catches the physical COM ports but not the USB ones.  So, in the best sysadmin tradition, after 20 minutes, I’ve (temporarily) given up on WMIC for this and decided to try a different approach.

This 1 line script will echo the serial ports on your machine, and what they are assigned to.  It uses the Microsoft REGDUMP command (this used to be part of the Windows Resource Kit, now part of the Microsoft Logo Tools available from http://download.microsoft.com).  It's a simple "show me the reg keys" script.

COMFIND.CMD



So, a test run with 2 dongles plugged in on my laptop looks like:



 


It ain't pretty, but it finds what I need. 

The downside of the approach I took here is that you need REGDUMP.  If I'm using a customer's computer (this is sometimes the case), I need to fall back on the "go look in device manager" approach.  If anyone out there is having better luck using WMIC for this than I have, by all means post your (better than mine) solution to the comments section !

So what can else do we find in the Microsoft Logo Testing kit?

First of all, our two friends REGDUMP and REGDIFF
RegDump - Dumps specific registry keys, or the entire registry
RegDiff - Compares the two files before and after an operation to give you differences (I generally use REGDIFF against two REGDUMP files, hence the name)
Restart Manager - Allows you to stop most processes in Windows (except for “critical system processes”) by injecting a shutdown message using the rmshutdown api – more info on this tool here  http://msdn.microsoft.com/en-us/library/aa373524%28v=vs.85%29.aspx
RollBack – a set of tools to assist in rolling back an application install (to test the error recovery within an application install MSI file)
ThreadHijacker
- Allows you to crash a process by pausing a process thread, inject binary data into it’s address space, then resuming it.  Again, this is used to measure the robustness of applications.
 

================================== UPDATE ======================================

There was a ton of responses to this diary, both as comments and as emails.  A common message in these is that the Microsoft support for serial port enumeration in WMI is not great - "broken" in the words of many.

Another common message was that i goofed.   Using REGFIND is totally not neccessary -  - the REG command has been in Windows for some time (since XP days).  It's also a command that I use pretty regularly, all I can say is that by the time I gave up on my initial run at a WMI solution, I was frustrated enough that I just plain missed it.  Using REG means that no downloads are required, and the script will run on any computer of recent-ish vintage.
An updated  COMFIND.CMD might look like:



We also got some pointers towards some WMI scripts that can do this.  The best examples of WMI scripts that work actually query the registry (go figure), so there didn't seem much point in replacing a one line CMD file with a 15 (or 50) line VBS or HTA file that does the same thing, even though it's possible

A reader did point me at a decent HTA script, but it lists all the ports you have ever had, not just the ones you have at the time the script run.  Note that the author of this script also notes that the WMI command 'WMI "Select * from Win32_SerialPort' is basically broken, so this script also queries the registry for much of it's information.  It's a good example of all that's possible - just be prepared for a bit of a wait while it runs ==> http://gallery.technet.microsoft.com/scriptcenter/087b4d73-4a5e-4746-b365-ad682911360e


 

=============== Rob VandenBrink Metafore ===============

14 comment(s)

Comments

Instead of using regdump use the built in (xp and above) reg.exe. Then it'll work on your customer's computers as well.

reg query HKEY_LOCAL_MACHINE\HARDWARE\DEVICEMAP\SERIALCOMM | find "REG_SZ"
I guess I am just as happy the COM ports are gone. In general they are tricky beasts for users to deal with (getting BAUD rate and # stop bits set correctly), and I have encountered situations where certain types of devices just don't work with certain laptops due to an inability of the laptop to process data fast enough.

Some of the newer equipment that I see has a micro web server of some sort. From and ease of use standpoint that might be a good thing - from a security standpoint it opens up all sorts of potential issues. We all got new VOIP phones at work, and the telephone on my desk listens to port 80, and I can connect to with my browser.
If the computer has PowerShell installed:
Get-WMIObject -Class Win32_SerialPort | % { Write-Host "$($_.Name) ($($_.DeviceID))" }
Our brand new HP 6730b laptops all come with serial ports built in.

Also Tera Term always recognizes my usb-to-serial adapter and its associated com port. No need to go hunting in device manager.
I think the question isn't "who got rid of COM ports on laptops" but more "why does Cisco still use COM ports to connect to their devices?"
Jessica, what would be the alternative? usb?
Plugging into a switch local is the one point, using console servers for several hunderts of network devices around the world is a bit different.

Laptops are not the only devices to admin/deploy devices :)

I´m happy that most vendors still having serial ports.
Dell Latitude laptops still have nice Serial ports.

Linux USB COM ports don't pick random numbers. The first USB COM port will /dev/ttyUSB0, the second /dev/ttyUSB1 and so on.

Newer Cisco x900 (1900, 2900, etc) routers have USB ports now which allow you to connect the device ("B") end of the cable to them and they automatically show up as a USB COM port. Linux continues to just grab the first available free /dev/ttyUSB[0-9] port. One thing to note here is that you cannot use the router's serial CONsole port and the USB console port at the same time - connecting to USB will disable the serial on the router until you disconnect the USB.

This is all the more reason to have serial terminal server solutions in place using a management network to access them so you don't have to physically be on site or deal with cables.

Lastly, my favorite USB-serial vendor which has always just worked is Cool Gear:
http://www.coolgear.com/Category.cfm?catid=199&AZX=

I especially like their part XC-232-C which has two serial ports but uses just one USB connection. It shows up as /dev/ttyUSB0 & /dev/ttyUSB1 as expected under Linux.
Just do add a datapoint, on OS X these show up as /dev/tty.usbserial*.
This article has been plagiarized by a Gregory Evans/LIGATT Security website.

http://nationalcybersecurity.com/?p=48907

Rob, he did leave your article signature in the end of the article, but did not source or otherwise attribute this to you.
At least the COM ports were reliable. I've never found a USB to Serial dongle that didn't have occasional glitches. And being in a customer's telco closet is not a good time to have your console connection glitch. Its hard to find a transmission mechanism more trustworthy than a serial connection. GUIs still don't have the functionality as command line for most commerical-grade telecom equipment.

Diary Archives