Thursday, June 02, 2016

Trash to Treasure

I have this nice Digi EL162 (16 port) terminal server that I found in the trash a few years ago. It didn't have a power supply so grabbed it and put it on the ToDo pile and left it. The power supply was the easy part. From time to time I'd pull it out, research it and put it back when I didn't get very far. I must have had the EL162 for more than 10 years. Pretty much each time I'd make a little progress but not enough to actually start using the device.

Fast forward to this past weekend, while checking my notes, researching and playing around with the EL162 I managed to get it to work. :-). Here are a few things I have learned:

  • This is not a terminal server in the sense of a Dec or Cisco terminal server (and that's okay). Instead it's more of a serial port extension across the network which requires a device driver on the host system(s). The server's serial ports are not physically on the server like PCI cards but rather on the EL162 (on the network).
  • Telnet and ssh won't work to connect to the status command line but rlogin will.
  • To access the boot diagnostics menu, you need a serial cable on Port 1, 19.2K,8,n & 1, no Ethernet and a fresh reboot. Then you need to send 3 '#' (hash) characters. Reconfig as needed, then connect the Ethernet and then type boot. It should boot normally.
  • Make sure the firmware the EL162 is in the correct path for tftpboot to find it (if you need to upgrade). Mine was looking for the el16.prm file (oops, wrong name).
  • This one bit me hard: version 7.9 < version 1.2, 1.4 or 1.6. I found 1.6 and it's the version needed for the dgrp Real Ports driver/daemon.
  • On the Linux server, use the latest dgrp (Real Ports) driver. I currently have 1.9 (3?). I think there's also a Windows package.
  • I had a bit of an issue with Debian Jessie's OpenSSL pkg. I used the included OpenSSL tar ball for now.
  • I haven't compiled dgrp 1.9 yet for the Raspberry Pi.

The best part of getting the EL162 working is that now I can migrate Misterhouse off my old server to the new server. My old server has 2 PCI serial boards. With the EL162, I can attach my serial devices via the network. Also I can technically let my other servers use the other ports. This will require a bit of trickery (should be fun). I also go from 12 to 16 serial ports. Very cool device this EL162 and I have to congratulate and thank Digi for supporting this hardware as long as they have. I will be recommending Digi products.

Tuesday, May 24, 2016

Routing redundancy

The SmartThings devices got me thinking about internet connectivity. SmartThings pretty much requires an 'always-on' connection to operate. While my primary ISP is pretty good with it's connectivity, I know a few things they don't cover or don't cover well. The first is 'last mile' redundancy. The 'Last Mile' meaning the connection between my home and the last redundant point in my ISP's network. A car takes out a pole between my house and that point, I'm without internet service until repairs are made. The other area not covered well is device maintenance/log information. A few years ago my ISP had problems with delivering a good signal. It was up, it was down and getting past the tier 1 folks and their "let's reboot again" script was impossible. Turned out the ISP was getting a number of complaints just before the Super Bowl that their Pay-Per-View was failing. It was then they 'miraculously' found the problem and replaced a failing board. I had logs going back 3 months that would have told them the same thing. So if I have devices in my home that need to talk to the internet to keep running, I need a backup solution.

I have worked on large router networks for a number of years and devised all sorts of interesting backup solutions. Applying my knowledge with various Open Source packages I came up with a overly complex but fun solution. A few weeks ago I picked up a second router, a Nexx WT3020. It is so small that I lost it or a couple of weeks (yes, really). A tiny thing with 64M of ram, 2 Ethernet, a/b/g/n WiFi and a USB port. My primary router, the Ubiquiti ERLite-3 works really well and handles the primary traffic load just fine, but without some trickery I can't get it to do LTE backup (via Freedompop). The WT3020, with OpenWRT, will handle backup duties (with a filter) for some of the traffic. I plan on setting up VRRP and RIPV2 to handle directing the traffic properly and IP tunnels to deal with poison reverse issues. So far I have the Quagga ripd working on my primary router, primary server and the WT3020. All are using RIPv2 to my primary router properly. I had experimented with vrrpd between my primary router and a Pi 3 but it appears that OpenWRT doesn't use vrrpd, instead uses keepalived. I now have a very simple setup with VRRP working. I intend to take advantage of a lot of the options of KeepAlived such as status scripts and interface tracking. After getting Quagga ripd, IP tunnels and KeepAlived working I can now begin working on getting the LTE modem working. It works fine on my Windows 7 Laptop but I haven't been able to get it to work under Linux. I really need to brush up a bit more on the LTE modem. Once I understand it and the uqmi software I should be able to make connectivity to Freedompop and figure out how to build the proper filters. I'll also post my findings on my Routers notes page.