Month: April 2013

Categories
Tech

Kitty – Putty with extra purrrrrr

I’ve been looking around recently for a nicer way to manage my Putty saved sessions – I’ve been getting involved with a much larger environment lately, and a giant list of names is less appealing. There are quite a lot of tools around that “wrap” Putty to add new features of various kinds, but they’re a bit clunky.

On the other hand, Kitty is a true fork of Putty, with some very cool extra features:

  • Nested folders in the saved sessions
  • Act as your local terminal for cygwin shells – no more DOS box
  • Drag files straight onto the terminal to upload over PSCP
  • Portable version with sessions saved to a file alongside the .exe
  • Still talks with Pageant etc for SSH infrastructure

It’s early days so far, but I think it might be squish time for Putty.

Categories
Uncategorized

This made me smile…

“After all, while it might be OK for the laptop support group to reformat your laptop when they can no longer cope with the increasing complexity of desktop operating systems, reformatting the network usually isn’t an option.”
— This is what makes networking so complex

Categories
Uncategorized

Serial Consoles – Windows Edition

Small update on console servers: Having actually tried, HW Software VSP is the thing to get for adding a virtual COM port to Windows. You need to get the singleport version, and then point it at the ‘telnet’ protocol port on your ser2net server. Now you can change the baud rate and other settings in your Windows app (e.g. Hyperterminal) and the settings are passed through to the remote serial port.

Finally you can virtualise that application with the weird serial hardware!

Categories
Network Projects & Hacking Tech

Raspberry Pi + ser2net = Cheap NM16A (Serial Console Server)

Introduction

I have had a Raspberry Pi model B sitting on the corner of my desk for about 6 months now, gathering dust and waiting for an application. I don’t need an XBMC box – I have one of those that’s more powerful (and also tiny enough) already with a Lenovo Q180 – and the actual I/O stuff looks mostly harder than it would be with an Arduino, so I’ve skipped that too.

Yesterday I was talking with a customer who had installed a network device in their DC racks that wasn’t talking to the outside world anymore. It’s management is either by SSH or serial port. The SSH was part of the problem, so serial needed to be the solution.

A small, easy to install box to allow network connectivity to a serial port? This did seem like a job for the RPi. I grabbed the latest Debian Wheezy SD image from the RPi website, and the USB-serial adapter from my bag, and got to work.

Booting the RPi with the serial adapter installed Just Worked, like USB stuff is supposed to. It’s an FTDI-chipset adapter and it just comes up as /dev/ttyUSB0 in Linux.

To get access to the serial port remotely, I could have just installed minicom on the RPi and then SSH to a shell before running it, but I was interested in how this might scale to more serial ports. You can get the USB serial gizmos for £2 each on ebay if you hunt around, and a couple of 8 port powered hubs would run to perhaps £15 each. That makes an ugly but usable 16-port console server for under £100. If you are building a lab environment for Cisco CCNP SWITCH or CCIE study, then this is a pretty decent deal.

The alternatives are Cisco’s NM-16A and NM-32A modules, plus the special cables to connect them, plus the router to put them in, or the ancient Cisco 2509 (so old it doesn’t have 10BaseT ethernet), or other random ebay scrap. I currently have a Lantronix 8 port device, but it was made before Cisco completely dominated the network world, and everyone else took up their console pinout – that means making up special cables to use it in my rack, which is kind of a pain. NM-16A modules go for around £150-200 on ebay, and you still need a pair of £50 cables to connect all the ports, and a router to put the module in.

The RPi has the added bonus that it’s still a linux box – so if you want to have an NTP server, or TFTP server or DNS, or RADIUS, then it’ll do that for your lab network too!

ser2net is a small application that listens for incoming telnet connections and connects them to serial ports. You configure a TCP port per serial port, so that ‘telnet rpi-ip-address 2001’ goes to /dev/ttyUSB01. You can preset the speed and other settings of the serial port, and you can also change them on the fly using the control interface (on a different TCP port). It also understands RFC2217, an extension to the telnet protocol that allows a client to control serial port settings with special codes. You can also get software like Serial Port Redirector which makes the remote serial port available as a local one under Windows, complete with port control. ser2net compiles simply on RPi Debian, and a single line added to the ser2net.conf has you up and running with your new serial console server.

Howto

First, grab the Debian Wheezy SD image from the Raspberry Pi Foundation’s Download Page and write it to a fresh 2GB SD card as described on their website.

Boot the RPi from the card, while connected to a monitor and network – Linux is preconfigured to use DHCP to get an IP address, so you’ll need to know that somehow to get access to the system. It tells you at the end of the boot process. Once booted for the first time, you’ll get the configurator utility, which allows you to enable SSH access. That should be the last time you need the monitor.

Download the latest ser2net distribution using wget.

wget http://downloads.sourceforge.net/project/ser2net/ser2net/ser2net-2.8.tar.gz

Untar, configure, make && make install.

tar xvfz ser2net-2.8.tar.gz
cd ser2net-2.8
./configure && make && sudo make install

Check what device name your serial adapter has:

dmesg | grep tty
[    9.735015] usb 1-1.3: pl2303 converter now attached to ttyUSB0

(ttyUSB0 in my case)

Now create a config file in /etc/ser2net.conf

BANNER:banner1:this is ser2net TCP port \p device \d  serial parms \s\r\n

# Don't do this by default
#CONTROLPORT:23

2001:raw:600:/dev/ttyUSB0:9600 NONE 1STOPBIT 8DATABITS XONXOFF LOCAL -RTSCTS
3001:telnet:0:/dev/ttyUSB0:9600 remctl banner1

And test by running the server:

/usr/local/sbin/ser2net -c /etc/ser2net.conf -n

With that running, you should be able to open another window, telnet to port 3001 on the RPi and get a welcome banner. If you have something connected to the serial port, you should be able to talk to it.

The final step is to make sure that the ser2net service starts when the RPi boots. Simply add the following line to the bottom of /etc/rc.local, just before the ‘exit 0’ line:

/usr/local/sbin/ser2net -c /etc/ser2net.conf

and it will be started automatically on boot.

You can add additional lines to /etc/ser2net.conf for multiple serial devices.

Extra Cheese

For an added bonus in a shared environment, you can log all output from the serial devices (while someone is connected). You get a file per session, with a timestamp for the start and finish, and the source IP. This is another couple of config lines in ser2net.conf

TRACEFILE:tr1:/var/log/ser2net/tr-\p-\Y-\M-\D-\H:\i:\s.\U
3001:telnet:0:/dev/ttyUSB0:9600 remctl banner1 tr=tr1 timestamp

i.e. add tr=tr1 and timestamp to the end of end of each telnet line. Then create the /var/log/ser2net directory and you are off and running.

Now it’s time to figure out how to ‘package’ this into less of a mess. A 1U box with 16 serial ports in Cisco pinout and a simple IEC power connector would be very handy! I think it’s do-able for about £200.

Categories
Monitoring Network Tech

Why do you make me have to hurt you, baby?

Everyone knows that #monitoringsucks, but does it have to suck this much?

An organisation I deal with uses CA’s Nimsoft monitoring system. It has a neat architecture, with a hierarchy of hubs, each collecting data and funnelling it back up to the central site. A central management console lets you configure any of the hubs. The hubs include an SSL VPN, so monitoring traffic can traverse NATs and live in conflicting address spaces inside customer networks. There are a bunch of application-specific plugins for enterprisey things like SQL and ERP apps. Config and new plugins are pushed out from the centre to hubs when necessary, and alerting/reporting goes back up the same pipe, so you don’t need to punch a firewall full of holes. Pretty cool, right?

Here’s why it sucks though:

  • It’s incredibly slow. Like, “go and do something else while waiting for a window to open” slow. I don’t know why.

  • Each probe plugin provides it’s own UI, and uses it’s own individual config file. So you might have a central management console, but you are centrally managing dozens of individual probes with separate islands of config. Because of that:

    • some probes have templates, some don’t
    • some probes allow arranging targets into groups, or folders, some don’t
    • any probe that uses SNMP or other credentials has it’s own record of the credentials – if you have a Cisco switch and want to monitor general health, interface stats and some other special OID, that’s three different probes to config, per device. Four, if you want to receive traps back from it.
    • sometimes, the same credentials work in one probe, but fail in another, on the same system!
    • Basic UI features, like not having the tab-order through dialogs be completely random, are missing

The “separate config files” thing is supposed to make it easy to roll out a “standard” config across a series of customers, which it might, but it makes dealing with the tool after deployment really painful.

Previously, I’ve used Cacti to do this particular piece of monitoring. Cacti has two plugins, Autom8 and Thold, that allow me to:

  • Add a new device, and apply a Host Template to it – that pulls in the relevant SNMP variables for this device
  • Wait for Autom8 to add all the graphs for me
  • Apply threshold templates that give standard alerting for all those new graphs
  • That’s it

With a CLI to bulk-add devices, I can have a DC full of switches under monitoring, with graphs and alarms in about 20 minutes. Even without the (standard, documented) CLI, it takes a minute to add a new device. The only thing I can’t do is distribute the polling to hubs, for customer networks or for general performance and efficiency. A simple one-line cron job will tell Cacti to rescan for new interfaces on a device as often as I like.

The only other part I need to do manually, currently, is periodically re-apply the Thold templates to pick up new interfaces for checking error-counters. Autom8 doesn’t talk to Thold, unfortunately.

How do large companies manage to make simple tasks so complicated? It’s like nobody actually tried to use this for a normal installation, while imagining they had a real job they were supposed to be doing as well. Configuring monitoring shouldn’t be a career choice, for things like switch error rates, should it?

Nimsoft isn’t alone – last time I looked for a distributed, SME-scale monitoring tool that understood that two devices might have the same IP address in different networks, and had a central management console, the competition was mostly worse. Usually it had better UI, often much better, but didn’t really have central management, just a central reporting console – you go to each remote hub to actually do the configuration.

How can this stuff be so hard?