Serial Speed-shifting demons

A fellow called Jerry Roy emailed me, asking if I knew how to connect a Cisco AUX port to a Topglobal Phoebus EVDO router console. There were a few thing he needed to work out...

1) the Cisco RJ45 to EVDO Mini-DIN-8 cable wiring
2) the configuration settings on the Cisco
3) why his old Cisco config clues didn't work right

Jerry is no slouch at this stuff, and had configured Cisco gear for reverse-TCP conection to the AUX port in the past, but this one was baffling him. He had a mini-DIN to DE-9 modem cable, but it wasn't playing nicely with the Cisco adapter. When he connected to the AUX port over the network, he got a Cisco login instead of the EVDO. Solving this took us about a week, including emailing to the vendor's support staff and the EVDO manufacturer in China to clarify signalling info and determine what wires needed connect to which pins. Once we had what we thought were the right pins, we still saw garbage on start-up, which made us try a variety of settings (even though the console speed was set to 9600 8-N-1).

We determined that the exec/no exec flag had changed in a major Cisco IOS revision from 12.2 to 12.3, so his abbreviated configuration commands needed to be amended. (It doesn't hurt to invoke a 'default' setting, so my Cisco config clues are a good start, if you're using reverse-TCP to get to Cisco ports.)

Jerry finally determined that the Tpoglobal Phoebus EVDO device runs its console at 115.2k 8-N-1, but he couldn't get any reponse from the console after the startup...because the OS then changes the EVDO console to the user-defined speed. The EVDO was running POST at one speed (spewing garbage at the modem/console), then silently shifting speed to a different, user-specifiable speed. He eventually set the user-defined speed for 115.2k, so the speeds would be consistent.

What made this so hard;
a) cisco changed the 'default' functions for local login (exec) between major IOS versions
b) vendor docs used unusual signal names (TD+, TD-, etc.) without input/output clues
c) molded cables, and unusual connectors made it hard to determine cable pinouts.
d) Roy didn't have any signal testing gear besides a voltmeter.
e) vendor docs didn't mention that P.O.S.T. messages would always be at 115.2 kbps

Developers Clue #1: If you think this speed shifting is a good idea, at least end the POST with a tag indicating that "POST is done, switching to OS console speed", even if you can't indicate what the new speed might be.

Developers Clue #2: If you think this speed shifting is a good idea, in the code that allows the user to set/check the definable console speed, you should also retun a note that the POST speed will remain at [speed], so the user is reminded that there will be a difference. (Or add an option to set the speed "Same as P.O.S.T. console speed".)

Tech Writers Clue: If the system console can be set for two different speeds, the cases need to be called out in the manual.

Here's the cable diagram Jerry came up with (in case someone else needs it) with the pin numbers shuffled to see where loops occur;

Cisco AUX           EVDO console
RJ45M              mini-DIN-8M   refer to my Signals page
1 RTS -->(nc) (nc) --> DCD 1     for connector pinout info
3 TD  -->------------>  RD 3
6 RD  <------------<--  TD 5 8 CTS <------------<-- RTS 6 4 GND ---+-----------> GND 4
       |    (nc) --> CTS 2
5 gnd ---'  (loop Cisco pins 4 to 5)
2 DTR -->-.   (nc) --> DSR 7
7 DSR <---' (loop Cisco pins 2 to 7)      

Since the EVDO apparently doesn't have a DTR output, we looped the Cisco hardware handshake lines. (For use connecting to other consoles, I would usually pass these to the 'far side', so the far device could tell if the cable was plugged in AND the near device was turned on. After all, that's what these leads were designed to do.) If you care about hardware flow control (RTS/CTS), you could also connect Cisco pin 1 to EVDO pin 7.

-Z-

Mining for (serial) gold on Google

When I'm using my gmail account, I find that I know keep an eye on the 'content-relavant' ads they post on the right side of my screen. If a link looks interesting, I'll 'open link in new tab', and look at them later. This way, I don't really interrupt the flow that I'm following now. Most of the links don't pan out, but sometimes I find gold, that really valuable site that I might not have found using keyword searches before. (I don't know why I don't find them at other times. I'll take lucky chances any day! :-)

Today's nugget was the Intro to Serial Communications page at TalTech.com. There is a lot in common with my Minor Scroll of Console Knowledge, but there are a few other tidbits there that I haven't put on my page. (I've already emailed the webmaster, asking if permission to link to their page. Netiquette first, of course.)

If you haven't tried gmail, you might want to, now that you don't need a referral. My acount was a test, to chat with a friend. It expanded to become an archive for console-related emails that I received on my other accounts, and the ads became more relavant. Now it's one of my main accounts. Thanks, Google!

-Z-

Crossing a VPN to get to your Console Ports

You may not have tried this yet, but you may want to read the note anyway, so you'll be prepared for the day you will need to cross a VPN. As security gets tightened, and networks are segmented, the VPNs will be coming to a LAN near you.

I hadn't thought about the issue of "dropped links" for years. My modems would often time-out from inactivity. Sometimes ISDN connections would drop due to idle timers, because there weren't that many B-channels available in the pool. I understand why you get timed out, and I empathize with the implementers. But, sometimes you need to keep a link up, without thinking too hard, or remembering to type a key.

In the modem days, I'd start a PING across a PPP link. Sometimes I'd set my email to poll every 5 minutes, just short of the timer, in order to keep links active. But broadband access and SSH to hosts was ubiquitous enough that I'd forgotten about this inconvenience.

Today, I was bitten bye a VPN with idle-timeouts set uselessly low for working remotely on my consoles. While email, and web browsers don't care so much (since they are always initiating a new TCP connection), it was invisible at first. But, my SSH sessions would suddenly be frozen. with no indication of the problem. Meanwhile, my idle TCP connection at the far host was abandoned, and would need to be killed off by someone with administrative privileges.

The answer was the TCP-keepalive options available in my SSH client. Under Microsoft graphical OSs, I use PuTTY, and you can set the option there for sending keep-alive null packets every n seconds, and/or TCP keep-alives. This solves the problem when it needs solving (only when I've got an SSH session I care about), and its automatically done (no need to remember special hacks), with minimal load on the network link.

Now, I admit that I am hogging a resource (the VPN session), but I'm usually logged in for a good reason (such as wrenching on the network), so I'm doing it for a good cause.

If you are going to SSH into console servers (or even reverse-TCP), a dropped VPN connection will cause you a lot of grief, since the port you were connected to will be 'busy' until someone can kill off that process. If you are using SSH to log into a Console Management Application Server (such as Conserver), you will be leaving abandoned sessions on the application server host, but the console ports themselves will still be available to the next person who needs to get on them. If you run into this symptom, check for the keep-alive options in your telnet/SSH clients, and see if that doesn't fix your timeouts. Just remember to log out of those sessions when you are done, so the VPN access can continue to be shared.

-Z-

Making the adapter or cable you need

I've got shelves, covered with tupperware tubs and drawers of adapters, sorted by wiring type and DCE/DTE, and labeled (both the adapters, and the tubs and drawers). I also have a variety of test gear handy to help me test serial ports and devices. But I know that I'm a bit unusual in this regard.

Most shops I've visited have one box or drawer where they collect 'stuff' that isn't 'Ethernet'. The problem is, many vendors do little to label their parts, other than to add a part number. (Sometimes, though, the part number is on a baggie around an unlabeled part. Once the baggie is lost, the part becomes useless as soon as you seperate it from its associated equipment.)

You can spend a lot of time trying various combinations of the parts at your disposal, testing at each step whether it shows signs of working, or you can set out to build the cable or adapter that you need.

To build the cable or adapter, you need to know:
1) are both devices using the same Electrical Signalling (i.e. RS232, TTL, RS488, etc.)
2) which pin/contact numbers are which on the connectors you need to use
3) which signals are on which pins, and which are inputs vs outputs

Your search for information should start with the equipment you need to connect. Some equipment will include pinouts and signal info on a label on the chassis itself. Next comes reading the manual, which should be on a bookshelf in your office if the equipment is still in use. Sometimes you can find the documentation on a CD-ROM that came with the equipment (you keep those, too, right?), or the vendors website, in their support section. Start with these if you can, since configuration information for the port may be needed later, and these documents will be specific to the software revision loaded on your equipment.

If you can't find the information resources from your vendor, your favorite search engine may be useful. I prefer Google, but they have their good and bad weeks when it comes to finding useful results. (There are occassional bouts with bogus search portals saturating the Google results. It's like a tide, really...when it gets really bad, they manage to clean it up, and results get really good again. No, I'm not trying to bite the hand that holds my new blog. ;-) I've had poor results with MSN, and Yahoo is hit-and-miss but they have too many ads for my tastes. The lesson here is to pick your favorite, but to try others if you are not successful in your searches.

You want to be sure that you only connect two devices if they have the same electrical signalling specifications. TTL signals are from 0v to +5v, while RS-232 signals are -12v to +12v. If you connect a TTL device to an RS232 device, you may not damage the RS232 port, but you will most likely 'let the smoke out' of the TTL interface chip (e.g. permanently damage it).

Now, it IS possible to connect a TTL device to an RS232 device, using an interface (electrical) level converter between them, but you cannot do it with a simple cable or adapter.

Once you know that your two interfaces are electrically compatible, just make a wiring diagram for your cable or adapter. List one connector on the left side of the page, and the other on the right side. Include which devices are being connected, as well as the connector type and gender, so you can identify this wiring diagram easily if you need it again in the future.

DCE and DTE were defined 'in the old days', but it was a 'draft specification'. It was an attempt to make things interchangeable. But it wasn't something which culd be enforced, so there are manufacturers that picked the 'less intuitive' option when designing their devices. As a result, they stack the odds against us if we are just guessing. So, when you find the pinout descriptions for the signals, you could 'bet' that TXD (Transmit Data) is an output, and RXD is an input. But, if you're using a less-popular/smaller manufacturers device, you may be disappointed. That's why I test the pinouts after I know where the Signal ('Reference') Ground pin is located. You should try to test your ports as well, whether you use a voltmeter, or a signal tester.

I usually list the pin numbers sequentially (with 1 at the top), and I also add the signal name, and the 'direction' of the signal. If the signal is an output, I use an arrow that points away from the number. An input will point at the number. The reference ground signal will not have an arrow. (You can see an example of this on my Signals page.) You can even use this format in simple text files or email, like so...

Cisco AUX         Cyclades ACS
RJ45-M              RJ45-M
1 RTS -->      <-- RTS 1  2 DTR -->      <-- DTR 2  3 TD  -->      <--  TD 3  4 GND ---      --- GND 4
5 gnd* <-      --> CTS 5
6 RD  <--      -->  RD 6
7 DSR <--      --> DCD 7
8 CTS <--      --> DSR 8 

You can now start drawing the lines that connect 'complimentary' signals, but I find that all of the crossing lines are difficult to read. Instead, I draw a second version, where I draw the signal straight across from the left side to the right side, and I put the appropriate number in the 'right-hand column'. It makes it easier for my eyes to follow. It would look like this...

Cisco AUX         Cyclades ACS
RJ45-M              RJ45-M
1 RTS -->      --> CTS 5
2 DTR -->      --> DSR 8
3 TD  -->      -->  RD 6
4 GND ---+--   --- GND 4
5 gnd* <-'   nc -> DCD 7
6 RD  <--      <--  TD 3  7 DSR <--      <-- DTR 2
8 CTS <--      <-- RTS 1 

This gives you a chance to count all of the pins on the right side. Is there one of each number? It also lets you see the 'odd' connections. In this case, the Cisco side needs to loop pin 4 to pin 5 (it's a switch in legacy products that tells the interface to be RS232. Without that input, the hardware doesn't use RS232 signalling.) Since the Cisco doesn't have a DCD output, the input on the Cyclades would not be connected. You can program the Cyclades to ignore the state of the DCD input. By diagraming the cable or adapter like this, it's a visual reminder that you need to check whether the device cares about an input which will NOT be connected.

I also find it's helpful to have a reference illustration for the pinouts of my connectors handy, when it's finally time to make the adapter or cable. You can find illustrations on the web, but you can find the cmmon connectors used for RS232 connections on my Signals page. Scroll to the buttom of the page for the DB and DE connectors. You can find a more verbose collection of basic RS232 clues and signal information on my Minor Scroll of Console Knowledge.

-Z-

Kick-off post

I've put the project of adding a log to my Console pages (http://www.conserver.com/consoles/) for too long. This seems like a good way to get started with blogging without any more delays.

My plan is to post tips and ideas, and ring to light some of the unusual problems I find while helping set up secure, remote access to serial consoles. I hope the site will become a supplement to the guides and the testing I do on the regular site, and I welcome questions and comments on the topics that I post.

Regards. -Z-