Ready to "Wring Out the Old"...

 2017 was wrapped up with a weeks-long 12+ hour days effort to move a data center "live" (that is, keep as much online as possible, while shifting it all to another building!), in an effort that ended 2 days before Christmas, because the building we had been in was going to be demolished! We got it done, but that was just the start of maintaining that operation while the campus around us was demolished, and significant renovations were being made to the building that we were now in. Going to the data center included suiting up in boots, jeans, hardhat, safety vest and safety glasses. Construction continues even today, on 5 of the 6 sides of the current data center. COVID-19  certainly played a part in extending the length of the construction project, and the end is now foreseeable.

  In January of 2021, I expect to see President Joe Biden sworn in as the 46th President of the US. We may even see the first inoculations for COVID-19 start in the US. In the Spring of 2021, I expect to be relocating to SW Oregon, and selling my California home. We've all been adapting to "working from home", as companies have had to change and adapt to remote working. With that move comes the decisions of what to pack, and where will it live in the new house. Older console servers from the test lab? Manuals and CDs from past vendors (example: Cyclades), with docs and firmware for older hardware. Even bins of serial adapters and specialty cables. Some of that stuff isn't going to "make the cut". This will be much of the "Wringing Out" in the next few months...

  In the past 3 years, I've been making LED Art with Arduino boards for fun (see https://www.instructables.com/IKEA-Star-With-ATtiny-and-NeoPixels/ for an example) and environmental monitors. I also got a Prusa MK2S 3D printer, and I'm learning how to make things. I was a supporter of https://www.hackerdojo.com, but COVID-19 has closed most of our maker spaces. I helped teach embedded computing to Jr High students for a year (1-day every couple weeks, in an Introduction to Technology class). I was at every (SF) Bay Area Maker Faire until there was no more Maker Faire. 

  I was wrestling with whether to start a new Maker-oriented blog as a fork, and try to keep that up after the move. But all the good names I could think of has been taken on blogspot, many years ago. Sadly, most of them had far fewer entries... some seemed to only try a few test posts, and then they want idle. Some started back in 2001, but none updated after 2014. :-( As a result, I think I'll stick with this blog, and post what I like going forward (versus only posting console-related things). 

  I still get the occasional email, asking for something that's not on my pages at https://www.conserver.com/consoles/, but I haven't needed to set up any hardware to recreate a problem for a long while. It may be Murphy's Law that after I toss out old hardware, that's when folks will have a problem that I'd want to look at myself. But since Murphy isn't going to help me load and unload the trucks, I'll learn to live with not having the hardware.

  I'm also exploring Raspberry Pi as I explore new Digital modes in Ham Radio (DMR, New Packet, and some HF modes next year), as I decide which monitors will be useful for Pi projects. There may be some interesting serial-related posts about these in the future.

  I hope for good luck, and good health for all of us in the new year.

Happy 2017!

I didn't realize that I'd left this blog fallow for a couple years! I'm still supporting console info, but I lost my old server (used for posting my web pages, although I still have my development server). It was the domain which was lost at the same time, which was the undoing of mirrors, including the primary at Conserver.com. I've been unable to rebuild that bridge.

I have replicated my repository on a new server, but that server doesn't support server-side includes for security reasons. My pages relied on that feature for page stats and for header and footer info. And I've been to lazy/preoccupied to go manually apply static header and footer into to all the pages. (Part of me had hoped to restore is back they way it was. And then I let myself get busy with other projects, and here we are in the beginning of 2017...)

While I've continued to track new servers, and the changes in the console server industry, there hasn't been any groundshaking news which might have triggered more posts. I've also been hacking with Arduino projects for the past few years as well. And now I find myself at a point where I'm considering a pivot...

I enjoy your emails with questions about something that you haven't been able to find on my web pages or elsewhere. But I'm not going to make any ad revenue off of my web pages. I've considered writing a book, or an ebook, but I can't see much of a market for that. And I realize that I was mainly working on the web pages because I liked new puzzles (the pages answer the easy questions, and then your emails brought me new puzzles).

I'm now looking at an intersection of a couple hobbies. Ham radio (primarily APRS and weather reporting), plus Arduino, having serial communications as a common link. But I don't think I can get many articles annually about APRS and weather. (But, given the storms in the past few months, maybe weather is going to generate more articles than I expect.)

Time will tell, but perhaps this blog will start pointing more towards Arduino in the months ahead. It's a creative outlet for me, and may generate more articles. I'll still field the serial questions, and post interesting new features as I come across them.

Please try to make 2017 a better year, especially where politics and your relationships with friends and family. Last year was rough on many, and this year may be rougher on others. I hope you will join me in trying to be more compassionate, and a better listener, and willing to speak up when your voice is needed to intervene or to support, for the betterment of the many.

From whence the Command Line Interface?

I've taken typing ASCII strings into serial ports as a normal interaction for decades now. Sometimes the strings seemed like arcane incantations that made little sense to me, but seemed to do the right things (in the end) on the device that I was talking to. I've written programs and scripts that took input from a user (via a keyboard, serial port, and other inputs), and I learned to "sanitize the input", and how to parse it, and how to cough up an error if the input was something unexpected, or not in the format that I wanted.

Over the years, I've had to sift through manuals, and command-completion information screens, in order to be reminded what my options are, on this device, running that version of firmware. Mainly because it seems so familiar, overall, but the occasional command options, or the order of arguments, may have been changed.

Today, I was sifting the web, looking for information to configure the serial port settings on an Avocent CCM4850. It turns out that line had roots from Equinox, with a different command syntax from the Cyclades line (which was also absorbed into Avocent, many years ago). But It also looks like the command syntax used for Lantronix and others. And this is when I decided to write this article.

Earlier in this month, Cisco Networks announced it was going to sue Arista Networks (Cisco's announcement) over what looked like copying of their Command Line Interface structures (and a few other items). Arista posted a couple early responses (from the Legal Counsel and the CTO), and I'm curious to see where it goes, and what effect it may have on the decade-old networking company. But, part of the argument begs the question about whether you can protect your Command Line Interface syntax. Are some command lines intuitive (after decades of predecessors...), and are some "common" enough that they become open to the public domain? Would the market benefit if a vendor could lock-in a particular set of commands, while competitors had to find unique ways to configure the same settings?

It harkens me back to the days of the big re-write of the Point-to-Point (PPP) protocols in the IETF Request For Comments... there were only three RFCs then, and there was confusion among the companies trying to write compatible versions. Many companies (Microsoft, Novell, Telebit, Morningstar) were trying to work on vendor-specific adaptations, and some were trying to find a way to aggregate multiple modem links into one larger pipe. The rewrite moved us into 13 different, new RFCs, but they helped lay the groundwork for interoperability. The PPP Consortium grew monthly, as more vendors jumped aboard to make things work together. And many command strings started to look alike. A LOT alike! And, at the time, that seemed like a very good thing, since I didn't have to reference many manuals to get a link running.

So, today, I'm wondering what the downside is, if different network vendors can parse the same command line string to provision VLAN or Spanning Tree settings for a switchport. And what may happen in the Console Server world if a ruling comes out that vendors must have unique command line syntaxes. How many syntaxes would you want to support, or remember?

Happy New Year! I can hardly wait to see what's ahead.

More about Cisco's USB Console Port

This past fall, I was able to work with a Cisco 1941 router, allowing me to explore the USB console in a bit more depth. Because it was the first time I've had an opportunity to work with that interface on the Cisco gear, I came to the installation process as a new user, without any previously  loaded software for this Cisco interface. This was actually beneficial, because it exposed a few other issues that might affect you if you were to approach it today.

When I first plugged the blue USB cable into my computer, nothing happened. That is, no USB device was yet detected. It appears that the USB chip in the cable gets its power from the Cisco device. Once I had the USB cable connected to the router, that's when the USB device was detected.

On a Windows 8.1 system, the USB driver is not found, and a generic interface failed to load properly, resulting in new communications. Searching the Cisco site, you will want to search for “Cisco Windows USB console driver”. The most relevant links I found work installation guides for my hardware. However, the only software download links which were still valid were dated in 2010, and the installer file for windows only supported Windows Vista, XP, and older Windows Server 2000 software.

The good news here, is that the Vista drivers included 64-bit code, and this happily installed under Windows 8.1, properly identifying the Cisco adapter as a Cypress (chip manufacturer) device,  and loaded appropriate drivers… requiring a reboot of the system.


  Device: Cypress 
  Driver added:  CiscoSerial
  Device Installed: ciscoserial.inf
  Device installed: cypressserial.inf
  Driver Management has concluded the process to add Service CiscoSerial...


On Cisco equipment which includes a USB console, there is also an LED next to the USB console interface. NOTE: When the internal interface chip is activated, this LED will illuminate, and that is a visual indication that the local RJ-45 interface has been deactivated because the USB console is active.  If the USB chip in the cable isn't initialized, the LED won't light, and the console won't be swapped.

Caution: When swapping the console channel between the RJ-45 interface and the USB interface does not alter the console process state. That is to say, if you are logged in on the RJ-45 port and already using the enabled mode, and the USB interface is activated, the USB user is now logged in and in the enabled mode!  Conversely, if you leave a session login and enabled, and then remove the USB interface, that enabled session is still now active on the RJ-45 interface. This is a strong argument for having the exec–timeout command set on your serial console line 0.

The USB serial console has a few minor differences, depending on the Cisco hardware family and IOS version. For example, not all versions will support the usb-inactivity-timeout 30 command, but this is a useful method to try and revert to the RJ-45 console, if you have a deployed console server implementation.

Swapping between RJ-45 to USB, or USB to RJ-45, does not force a logout of the consul processed. There was no visual indication (no characters received) on the RJ-45 interface which indicated that the serial process has been diverted to the USB port, or been returned to RJ-45.

 While you can connect multiple Cisco USB interfaces via a USB Hub, each Cisco device does take up a COM port on your Windows machine, or a TTY port on your Linux or OS X machine. As a result, I cannot see this as a practical method to connect the serial console for many machines in data center service. (Using the RJ-45 serial console to a console server for remote access to dozens of machines is still a much more scalable solution.) However, I think that the USB console on a Cisco product is an elegant way to use a laptop or desktop device for setup of new equipment coming in prior to deployment. It offers a quick solution for devices which only have USB interfaces, such as tablets or netbooks, to use a single cable for the configuration and quick debugging, rather than needing to support a USB-to-DE9 interface.

I am grateful for access to the 1941 ISR to be able to do this testing, and for a few candid conversations with Cisco folks who are close to the USB serial console project.

Is USB the new Serial Console?

I'm happy to report that I finally have access to a Cisco device with a USB console (a gently-used C1900 router), so I can experiment a bit with it. I also have had an interesting briefing about how these USB console interconnects came to be at Cisco, and some caveats.

As I understand it, essentially they have embedded a USB-to-EIA-232 bridge chip into the Cisco device. When you connect a PC, and you have suitable drivers, it simply appears to your machine to be a simple COM port. (I'm presuming that a MAC will see s suitable TTY and etc.)

When the serial bridge chip comes on-line, it steals the line console 0 data path from the RJ-45 console connection(!). I need to check if that means that some speed-shifting is also happening. That is, if my line console 0 is set for 9600 8-N-1, does it shift to 115,200 when it swings to the USB channel?

When the USB chip powers down (when you unplug the USB), the data path is supposed to drop back to the RJ-45 port. But, if you leave the USB connected, you could find yourself without access to the RJ45 console for remote administration. Fortunately, there is an idle timer to revert back to RJ45, but this wasn't implemented in hardware in the earliest versions of equipment to have the USB console. I'll summarize more of the details in the next couple weeks. I'm excited to finally get a chance to explore this, since many folks have asked me questions about it already.

This sounds like a great addition for quick desktop administration, or for jacking into equipment with your laptop in a data center. After all, fewer laptops have a built-in DE-9 connection these days, and everything has a USB port, right? With a USB console, you only need the single USB(A)-to-USBmini(B) cable. But, it hasn't (yet) become a ubiquitous connection, so we probably still also need to carry our USB-to-Serial dongle, and also our DE-9 to Cisco-RJ45 cable as well.

Check back in August to read about the results of my hacking.

Dell R6xx, 7xx series servers (iDRAC and Console)

Here are two clues that will help you plan for installing the new Dell server families.

They seem to be great servers... lots of capacity for RAM, lots of CPU strength, and I love the rack mounting rail system. I also like the iDRAC service processors.

What's not to like? The back of the chassis is too thick (or the DE9 console port is recessed too far). Either way, most of the serial console adapters (DE9 to RJ45) won't fit well, and provide reliable connections, unless you grind down the cases of the adapters. And, since the adapter vendors don't offer to sell you a "trimmed" version, that job is going to cost you extra, somehow. Hey, maybe we can get the intern to do it? ;-)

I'm *really* glad that the serial consoles are still on the back of the servers, but if you are going to put them there, it seems to me that making the serial adapters fit should be part of the plan to have them on the server.

The one adapter I've found that works on the R620 series servers is from Cyclades (ADB0036). Yes, you can still get them from CDW. Fortunately, our latest batch went into racks with Cyclades TS2000. But, I did need to modify SO MANY of the Lantronix adapters that I made a custom jig for a Dremel router, to get consistent results.

Clue number two: On the R620, ttyS0 goes tot he iDRAC, and ttyS1 goes to the DE9 on the rear of the server. You will need to start an agetty for BOTH of these, if you want to be able to use both of them.

My other big projects are nearly done, and I plan to post much more often this summer. Thanks for reading.

My first impressions of the Redpark serial cable and Get Console

I'm reviewing them together, as I don't see an easy way to use the cable with another app (yet).
My first attempts were hampered by some Bluetooth weirdness between my iPad 1 and my ZAGGmate keyboard. A hard-reset of the iPad seemed to straighten that out. Since then, I have had good luck using the ZAGGmate with Get Console in both portrait and landscape modes. I'm a bit let down that the top speed is 'only' 57.6 Kbps, as I have a handful of console ports running at 115.2 Kbps. That said, it does perform well at those speeds which it does support.
There is no built-in method to email your log files, but you can copy them to the cut-and-paste buffer,and then paste it into the email app of your choice.
It makes the Escape key sequences visible! This is a BIG plus in my book! If you are working with conserver, this will help you spot devices which are prone to fill your logs with extra characters.
The earlier assertion that the application will only work with Cisco devices seems to be incorrect! That is, with a proper adapter, you can connect the cable to almost any device. Using a CFDTE92 adapter, I can connect to the DE9M com port on most Intel-based servers. (Check my Cisco console connection guide page for more clues, http://www.conserver.com/consoles/Cisco/ciscocons.html )
The cable is about 6' long, with a slender cable. The jacket feels a bit like Teflon, and the RJ45M connector has a molded strain relief, which will likely improve the service life. (That would be great, given the cost of the cable!) It is lightweight, and it looks like a high-quality part. The folks at Redpark have been known for the high quality of their products in the past, and I expect good things from this new product.
I have tried the combination with a variety of non-network devices as well, and I seem to be able to talk to them without needing to do any fussing with the signaling wires. I can't promise that it will work with anything, but the Get Console app running 'stand-alone' (without needing to connect to their website) seems to be a useful basic terminal emulator, if you need a wired serial connection. The cable has made a good addition to my iPad gear bag.
Testing the Get Console website service will need to wait for another post.