Welcome to the VanDyke Software Forums

Join the discussion today!


Go Back   VanDyke Software Forums > Scripting

Reply
 
Thread Tools Rate Thread Display Modes
  #1  
Old 05-15-2013, 11:41 AM
gunslingor gunslingor is offline
Registered User
 
Join Date: May 2013
Posts: 27
Chapter 3: Connecting to Remote Machines

I learned a lot from this chapter, but the one method I want to use isn't listed there, so I'm wondering if it (or something like it) is even possible.

Here's my slowly evolving simple first script:
Code:
Sub Main()
	'Run "C:\Program Files\VanDyke Software\SecureCRT\SecureCRT.exe"
	crt.Session.Connect "/Serial COM6 /BAUD 9600"
	crt.Screen.Send chr(13)
	crt.Screen.WaitForString "username:"
	crt.screen.send  "Myusername"
	crt.screen.send chr(13)
	
	'crt.Session.Disconnect
End sub
so I'd like the first thing to happen to be a message box or similar asking if the user wants serial or ssh connection... assuming serial, the above connect statement would run, assuming SSH what I want to happen is for the connect dialog to pop up with all my predefined sessions... when a user selects the session they want execution is passed back to the script which then runs a similar connect statement for SSH.

Is there underlined text above even possible? Is there a way to emulate it if not? I might be making this more complicated than it needs to be... perhaps I should just connect manually, then run the script that is intended to only capture and parse data using, primilary, show commands that will later be imported into a DB.
Reply With Quote
  #2  
Old 05-15-2013, 01:24 PM
miked's Avatar
miked miked is offline
Registered User
 
Join Date: Feb 2004
Posts: 2,040
Quote:
what I want to happen is for the connect dialog to pop up with all my predefined sessions... when a user selects the session they want execution is passed back to the script
There's not a scripting object for the Connect window, so you won't be able to interact with the Connect dialog via the script.
Quote:
I might be making this more complicated than it needs to be...
Absolutely. You're asking about ad-hoc connections and sessions. Ad hoc are often used when you don't have a session for the machine:
crt.Session.Connect "/Serial COM6 /BAUD 9600"
You're also asking about the Connect window (which implies you have a Session).
Quote:
perhaps I should just connect manually, then run the script that is intended to only capture and parse data using, primilary, show commands
Perhaps. Or maybe there's another even better way. Rather than focus on a particular solution right now, it would probably help to go back to the beginning and list what it is that you need to do. Collectively in your various posts you've mentioned parts of the task and goal. I'm not sure that my picture is complete but it sounds like the steps are:
  • connect to many machines
  • run a sequence of commands on each machine
  • capture machine responses into a database
I think you mentioned elsewhere that you would need to modify commands for each machine, so you wanted individual scripts for each machine. That didn't make a lot of sense to me, and I see it as a critical point. Depending on that one point, you may or may not be able to use the example script that has worked so well for so many network engineers:Read Data From Separate Hosts/Commands File And Log To Individual Files.
__________________
Mike
VanDyke Software
Technical Support
[http://www.vandyke.com/support]
Reply With Quote
  #3  
Old 05-15-2013, 02:27 PM
gunslingor gunslingor is offline
Registered User
 
Join Date: May 2013
Posts: 27
Quote:
There's not a scripting object for the Connect window, so you won't be able to interact with the Connect dialog via the script.
-oh well, I suspect I can make my own at a later date... for now I'm just going to connect and run it.

Quote:
You're also asking about the Connect window (which implies you have a Session).
-I might be using the wrong terminology. I have a bunch files that the boss man gave me to interface with these devices... I installed CRT and pointed the path to these files... now most of our devices show up in the connect window for easy access. To me, I'd call these 'session config files' and not 'sessions'... right? I mean, a session isn't established until you connect.

Quote:
I'm not sure that my picture is complete
Here it is since your being so helpful:
We have roughly 300 networking devices I now have security responsibility for. The company... well, lets just say security/compliance/documentation hasn't been the highest concern for the last 20 years... but now we could be fined due to new compliance requirements and that's why they hired me =).

So, first and foremost I need an accurate accounting of all devices my department owns... so I made a quick Access DB which house basic PHYSICAL data (e.g. rack, row, room, mfr, model, device type, description and a lot more); the intent being I plan to go around to all our cabinets and take a tally of all the networking device, which will give an accurate count. However, all the good/bad documentation done by different departments and people up until now references devices using a huge swath of variation. I mean, currently the most accurate tally is the boss man's secureCRT sessions, which some times uses host or IP name.... but this doesn't match up with the physical data I'm gathering.... which is the primary reason this scripting task began, to make my physical data match the various forms of cyber data people have been using to track stuff over the years. So if one report from 10 years back references devices using either IP, MAC, serial number, special other tags, hostname, rack/row (mine), etc... that my DB will house all the data needed to identify the device being referred to, without a ton of research.

Wow, sorry, I gotta stop rambling.

Anyway, I'm doing this ONCE around walk down and because of the need to match up the physical with the cyber data, I figure it best to grab some of this cyber data while I'm gathering the physical data. I mean, the boss man uses all these secure crt sessions to manage the network... but he really doesn't know physically where a lot of these are. Initially I was just going to copy past into the db from secureCRT, but this is too slow to gather interface data (on say a 48 port switch.... it would take like 4 hours). So, I'm currently getting my feet wet in scripting to gather and parse the data (I've done this before a ton, but only for hosts and clients and it always ran locally). Minimal data needed: interface data (with the fields specified in a previous post), OS version as spit out with show version, image file name, and I think that's about it for now, though I may grab more as I get better with this development environment and cisco commands.

Quote:
I think you mentioned elsewhere that you would need to modify commands for each machine, so you wanted individual scripts for each machine. That didn't make a lot of sense to me, and I see it as a critical point. Depending on that one point, you may or may not be able to use the example script that has worked so well for so many network engineers:Read Data From Separate Hosts/Commands File And Log To Individual Files.
To clarify, in the end, I suspect I'll have 5 or 6 scripts that are virtually identical. I mean, on a cisco FW you type "show interface brief" whereas on a cisco switch you type "show ip interface brief". I know I can probably pull the model number out of the show run and determine which command to run that way, but... I'm still getting my feet wet =). Also, this could end up being a temporary script and not something that will be used but once... not sure yet though.

Last edited by gunslingor; 05-15-2013 at 02:32 PM.
Reply With Quote
  #4  
Old 05-15-2013, 05:01 PM
miked's Avatar
miked miked is offline
Registered User
 
Join Date: Feb 2004
Posts: 2,040
Quote:
I'd call these 'session config files' and not 'sessions'... right?
In SecureCRT and SecureFX the items you see in the Connect window are referred to as sessions. Sessions are saved as .ini files (that your boss gave you, and which are stored in a folder named Sessions inside the configuration folder). If we were talking about TCP/IP packet analysis, or the OSI model, then session could take on other meanings, but there's not much reason to talk about things at that level on the VanDyke forums.


Thank you for providing more details. I think there are several different ways you could solve the problem effectively. Here's one possible path:

The SecureCRT Script Recorder is an easy way to generate all of the scripts for the different devices (see section 1.2 of the SecureCRT Scripting Guide). Connect to the device, start the Script Recorder, issue some commands, then stop the Script Recorder. This will provide the WaitForString/Send that you need for a particular type of device, and help avoid any common mistakes, like having back to back crt.Screen.Send calls without a crt.Screen.WaitForString call in between.

Once you have that script, you may be ready to expand it a little to accommodate different types of devices... If based on the response to a particular command you can determine the device type, and thus the specific command to send (show ip interface brief vs. show interface brief). You could use crt.Screen.WaitForStrings (plural) to list the various possible responses to the one command that tells you what kind of device it is. Based on the response, you might choose to call a function, or maybe just set the get interface command in a Select Case statement.

That's the path that seems fastest to me.
__________________
Mike
VanDyke Software
Technical Support
[http://www.vandyke.com/support]
Reply With Quote
  #5  
Old 05-16-2013, 06:17 AM
gunslingor gunslingor is offline
Registered User
 
Join Date: May 2013
Posts: 27
Thanks, that Waitforstrings recommendation sounds like a good suggestion. However, I don't think I should use the script recorder, primarily because the hardest part of this code is the parsing of the output which can't be captured with the recorder.
Reply With Quote
  #6  
Old 05-16-2013, 10:33 AM
miked's Avatar
miked miked is offline
Registered User
 
Join Date: Feb 2004
Posts: 2,040
I understand what you're saying, and hesitate in making coding suggestions, but I think the approach taken in Read Data From Hosts/Commands File... is a good combination of WaitForString and ReadString.

Here's a snippet which demonstrates using WaitForString to know when to send a command, and ReadString so that output can be parsed. A general approach like this may be easier to write, maintain, modify, than an approach consisting of a series of sequential WaitForStrings.
Code:
For Each strCommand In vCommands
	If strCommand = "" Then Exit For
	
	' Send the command text to the remote
	g_objNewTab.Screen.Send strCommand & vbcr

	' Wait for the command to be echo'd back to us.
	g_objNewTab.Screen.WaitForString strCommand
	
	' Since we don't know if we're connecting to a cisco switch or a
	' linux box or whatever, let's look for either a Carriage Return
	' (CR) or a Line Feed (LF) character in any order.
	vWaitFors = Array(vbcr, vblf)
	bFoundEOLMarker = False
	Do
		' Call WaitForStrings, passing in the array of possible
		' matches.
		g_objNewTab.Screen.WaitForStrings vWaitFors, 1
		
		' Determine what to do based on what was found)
		Select Case g_objNewTab.Screen.MatchIndex
			Case 0 ' Timed out
				Exit Do
			
			Case 1,2 ' found either CR or LF
				' Check to see if we've already seen the other
				' EOL Marker
				If bFoundEOLMarker Then Exit Do
				
				' If this is the first time we've been through
				' here, indicate as much, and then loop back up
				' to the  top and try to find the other EOL
				' marker.
				bFoundEOLMarker = True
		End Select
	Loop

	' Now that we know the command has been sent to the remote
	' system, we'll begin the process of capturing the output of
	' the command.
	
	Dim strResult
	' Use the ReadString() method to get the text displayed
	' while the command was runnning.  Note that the ReadString
	' usage shown below is not documented properly in SecureCRT
	' help files included in SecureCRT versions prior to 6.0
	' Official.  Note also that the ReadString() method captures
	' escape sequences sent from the remote machine as well as
	' displayed text.  As mentioned earlier in comments above,
	' if you want to suppress escape sequences from being
	' captured, set the Screen.IgnoreEscape property = True.
	strResult = g_objNewTab.Screen.ReadString(strPrompt)

	' If you want the command logged along with the results,
	' uncomment the next two lines
	' objFile.WriteLine "Results of command """ & strCommand & _
	'    """ sent to host """ & strHost & """: "

	' Write out the results of the command and a separator
	objFile.WriteLine strResult
	
	' Add a separator between commands 
	objFile.WriteLine _
		"- - - - - - - - - - - - - - - - - - - - - - - - - - - - - -"

Next   ' Command Loop
__________________
Mike
VanDyke Software
Technical Support
[http://www.vandyke.com/support]
Reply With Quote
Reply


Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)
 
Thread Tools
Display Modes Rate This Thread
Rate This Thread:

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT -6. The time now is 10:10 PM.