End-of-Semester update

So wow. It's been a while since I've had time to write in the blog. Between classes, exams, and presentations, it seems like I don't have time to do anything anymore.

To start off, I believe I may have been barking up the wrong tree when I talked about sockets-I was considering using them in the same manner a tabbed web browser does to ensure that data is sent to the correct tab. The socket binds locally to an insignificant, unique port, so traffic requested from that socket is then redirected back to it. However it seems that NoteBook (The Perl module to create tabs) may have it's own method of managing and delivering content to the correct window. The documentation and examples for this module are sporadic at best, I have needed to reference multiple sources to assemble an (almost) complete version of the documentation. The program can detect when a certain tab is active, if each tab has a unique identifier, it should be simple to block traffic to all tabs except the active one.

I haven't pushed any code in a while-this is because I am not a fan of putting experimental code on the public repository, though I have done it in the past. Once I complete my testing and determine the best method for handling the traffic to and from the remote device, I will push the code update which contains this option.

I am currently shooting for a mid-January release date for version 1 of the project. This will be a version of the client that is specifically tailored to work with RPI's Cisco routers, with the hope that the client will be in a state of readiness to be distributed to the incoming class of Network Engineering students in the Spring. To make this deadline, it is likely that most of the connection information will be hardcoded, (as it is already for my testing purposes) so a user will only need to enter the pod number for their devices, and the program will open all the relevant connections.

Once the initial release is complete and functional, I plan to expand the program, adding the ability to customize connection information to make the program more universal. I would also like to expand it's use to include SSH connections, as telnet is not often used outside of secured academic environments.

I'm hoping to complete my code testing sometime in the next 48-72 hours and should have a major update to the repository by the end of the weekend.

New Idea: Sockets

Actually, the title pretty much says it all. I'll write a more updated entry on my success or lack there of after I actually try this.

Developments and Second Presentation

I gave my second presentation to the RCOS on Friday, 5th November. The slides are in http://code.google.com/p/inmp/ along with the rest of the code.

In the meantime, I have been working on using Perl to control a Telnet session to a Cisco router. So far, I am able to log in and run simple commands. The current problem is that the program does not always return the correct router prompt. The next thing I am going to try is inserting a small delay (something like .1 ms) to see if this will help the program set the prompt correctly.

Finally: A GUI client.

INMP is moving in to the 21st century!! We now have a GUI client. Right now, it doesn't yet interact with software. To that end, please continue to use REVISION 10 of the software.

The graphical client is built in Perl, like the rest of the project, and uses the Perl/Tk module. This is an extension to Perl and is not tied to the desktop software, so I can hopefully ensure universal compatibility among all UNIX-based OS. The client further uses an extension to Tk known as NoteBook; this is what allows the ad hoc generation of the tabs. Each tab will be the telnet or SSH session to a Cisco device.

At some point in the future, the client will also feature a menu with configurable options. For instance, if the passwords to all devices you connect to are the same, you will be able to set this and have the password sent to all devices. It will also likely support some type of macro where you can save connections that you use often; so you can just hit one button and instantly connect to these devices. Furthermore, it will interact fully with the scripts to save and load configurations, so that this not longer needs to be done by entering text at a terminal.

I'm sure I've missed some of the features; basically, stay tune for further updates as the heart of this program begins to take shape!!

RCOS Presentation!

I gave my first presentation to the RCOS on Friday.  It went well, lots of tough and interesting questions from crowd, as well as a host of awesome suggestions.  The slides will appear at http://code.google.com/p/inmp/ shortly.

This week, I have plans to begin work on the GUI interface.  I have decided to simply use Perl's built-in Tk interface for maximum compatibility-this way it can run on other desktops like KDE without pulling in a ton of dependencies.

That's about it for now.  I should be back to more regular updates this week now that midterms are over.

Ah, a Breakthrough!

I have spent much of this past week working on the restore script, which purpose is to grab configurations from a text file and load them into the routers and switches, to save much time versus doing the process manually.  The good news is that the script works for the most part.  Sometimes however, a command entered on a router or switch will output a message which is preceded by a %.  These messages are good and are usually informative as well.  Unfortunately, when running an automated script to load configuration files into a device, these message cause the program to terminate.  Fortunately, the exact, specific nature of the problem (termination on any message beginning a %) makes it easy to fix.  I am exploring a couple different solutions at the time of this writing, and will pick the best one.

I'll write very briefly, too, about another issue I encountered, and solved, during the week, as it was interesting to me.  The interface I am using to send commands to the remote devices waits for a prompt to ensure that it is safe to send the command.  The prompt may look something like this, at it's most basic level:

Router#

or, perhaps,

Switch#

This is a most basic prompt encountered when configuring devices.  As increasingly complicated levels of configuration ensue, one may see increasingly complicated prompts.  For example, a prompt when configuring an interface on a certain device may look like:

Router(config-if)#

This is also a basic prompt which was matched and considered safe to send commands too.  In general, the interface accounted for any prompt with (config) in it.  Some prompts, however, do not have this (config) and thus were not considered a matching prompt.  The fix for this, was to simply alter the regular expression matching a prompt from 'config.*' (matching config followed by any text) to simply .* to match on any text that may appear there.

A closer look at INMP

My last blog entry was set up a little bit hastily, so here is a more detailed look at INMP:

Managers of internetworks are often required to work with several devices at once-naturally, having several SSH windows open at once is not practical and contribute to screen clutter.  Unfortunately, for users of Linux-based OS, there is no suitable program which can perform these functions.  The built in terminal programs such as Gnome Terminal do not allow it to spawn a tab from within itself-thus making it impossible to automate the tab generation process.

Rather than needing to rely on some third-party software, to a bunch of scripts from another third party, the ideal solution is to have one program to manage the entire process-this is the goal of the INMP.

Currently, the program is a series of Perl scripts which are executed from the RoxTerm terminal program.  Currently, the scripts are set up to work on the Cisco networking pods at RPI.  As the software continues to grow, however, it will be a simple fix to allow it to connect to any router or switch.  Currently existing scripts connect to the devices, run some initialization commands, and dump the running-configuration of all devices into a text file.  There is also a script to restore data from the text file to the devices, though this is currently buggy.  (i.e, it does not work.)

Getting these scripts working completely and bug free is the initial goal, as they will form the background of the final application.  The final application will feature a Perl-built GUI featuring tabbed windows so that one can manage multiple devices at once.  The program will support both Telnet and SSH connections, though in a real, corporate environment, Telnet should never be used. 

Welcome to the Internetwork Management Program!

The Internetwork Management Program is tabbed telnet and SSH client for UNIX and UNIX-like operating systems with the primary focus on providing features for managing networking devices such as routers and switches.  The program is built in Perl, using the Perl/Tk library for some nice GUI usability.

Currently, the connection scripts are just a series of Perl scripts which must be run through a third party terminal emulator.  The goal of the INMP is to create a single program from which all the necessary script is containing, preventing users from needing to download some third-party software to use the program.