During some of that work on my network I’ve been talking about over the last few posts, I stumbled across a realization that I wanted to share. Before I get there, I have to explain that I was turning on VLANs for my wireless network. My network has an inner ring where my files are stored and which has a site-to-site VPN to the colocation center. However, there’s an outer ring behind the U-Verse gateway. I wanted to allow guest wireless to this network – thus they could get to the Internet and I didn’t have to worry about them on my network. I setup VLAN 1 as my private network and VLAN 2 as my U-Verse (public) network. Once that was setup I went to my access point, a NetGear WAG302 which I’ve discussed before. When I turned on VLAN tagging the device became unresponsive.

These particular APs have a console port on the back so I started trying to make a console connection. I pulled out my USB to Serial adapter and tried to make a connection. Based on the day I was having I realized that this wasn’t going to be easy – and it wasn’t. The console port had 9600, N, 8, 1 under it which I knew meant 9600 baud, no parity, eight data bits, and one stop bit. I started up a communications client called Putty and tried to connect. However, that wasn’t working.

At this point I’ve got to explain how I even knew anything about the console port. You see I cut my teeth on networks of serial based terminals (like the VT100). I was used to wiring up serial cables. We’d run them through offices and wire them up ourselves with a soldering iron. Of course, since then I have installed modems that used serial connections and have connected all sorts of devices like CNC machines. That seems like a million years ago. However, there are still things that have stuck with me. Obviously, I recognized the pattern of the baud rate, parity, data bits, and stop bits. However, I also can still recall from memory the pin out of a DB25 RS-232 serial connection – I had to use it all the time for several years so it’s not exactly surprising that I remember it. You see Pins 1 and 7 are grounds. Pin 1 is a frame ground and pin 7 is a signal ground. Pins 2 and 3 are send data and receive data. Pins 4 and 5 are ready to send and clear to send – the hardware flow controls. I remember that pins 6, 8, and 20 are also signaling pins for various states including data set ready, data carrier detect, and data terminal ready. I remember them as a set because we were often jumpering the three of these together. You see the RS-232 standard was really designed to work across modems but we often were using it for connecting without modems. Don’t ask me what the pin outs are for a DB9 connection – like the ones that are used often today because I never had to make enough of those connections to remember the pin outs.

All of this is important because connecting to the console port didn’t work. I knew that the settings were right – something I only knew because of years of experience. I was struck by how this knowledge that in most cases is useless – you don’t see much RS-232 these days – was something useful. Sure I couldn’t figure out initially why it wasn’t working, but I realized that someone coming out of school today may be barely introduced into what a serial port is. No computers come with them any longer. Why would someone teach about serial ports these days? However, in this case knowing how serial works meant that I could identify that I had things right on the software side and allowed me to move quickly from that as a possible cause.

One of the common problems with RS-232 back in the day was the null modem problem. That is that RS-232 was intended for a terminal or modem to be connected to a host system. In order to do this the wires need to be crossed. One device used pin 2 to transmit and 3 to receive and the other device had those reversed. So it was a common issue that we’d have to do some pin flipping. Today you can buy some cute and tiny null modems. We used to make them in the cables. That’s a great suspicion but that suspicion doesn’t do you any good unless you’ve got a way to test it. As it turns out, I still had my RS-232 breakout box from all of those years ago. The one I have is hard to find and still relatively expensive even today. Take a look at what it:

It’s got rows of green and red LEDs which light to indicate what signals are on which lines, a set of switches down the center to allow you to open or close the connection between the two sides. This allows you to separate the two signals and if necessary remap them. The brass posts are designed to have jumpers attached to them so that you can connect various pins with others. On the bottom there’s a convenient set of switches to cross pins 2 and 3 – the most frequent need.

In this case I did in fact need to have a null modem – which I used the breakout box to accomplish since the need was very short term – just getting the device back online.

So why am I telling you this story? Well, I realized that in addition to the learning which most folks aren’t getting today there are also tools that are necessary that most folks won’t have today – a breakout box was a standard tool back then. I should say in defense of the learning that serial communications are still officially listed as a part of the objectives for the CompTIA A+ certification – so there’s some hope that the skill is being taught somewhere. Ultimately, the folks that we’re trying to teach how to use the tools today don’t necessarily have the background or tools to solve the problems we’re creating.

And I’d be the first person to kill off serial communications in a review of useful information today. I’d argue that technologies like USB and working with them is much more important than serial communications – but I’d be wrong. The problem is technicians today have to know BOTH about serial and USB. In other words, they need to know MORE and not less in order to work today. Some have argued that It professionals today have it easy. Everything just works. The argument is that you don’t have to worry about fitting drivers into 1 MB of RAM or how to get a large spreadsheet on a hybrid 8/16 bit processor. However, I’d argue that there are places where this knowledge is essential to success.

And at the same time I’d say if I were looking at learning a 30 year old technology today I’d probably turn my nose up. I’d think that I could surely ignore that technology – but again I’d be wrong. Why the long post about a long perceived dead technology? Because the point is that you never know what you’re going to need to know. I deal with SharePoint every day and I can tell you that there are tons of things that you’ll find helpful if you know – and those are the things that you don’t teach in a SharePoint course. Why not? They’re foundational. They should be known. In the Microsoft Learning 10232 course we make a point of spending the first module talking about advanced ASP.NET concepts like caching and memory management because these things are really helpful to understand for SharePoint development – but things that are often skipped or overlooked as folks try to focus on test driven design, LINQ, ORD, and other more interesting items.

In the end, knowing about serial communications – and packet sniffing – made it possible to figure out what was wrong with the access point and resolve it. I’ll explain the need for packet sniffing in another post.