#1
|
|||
|
|||
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 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. |
#2
|
||||
|
||||
Quote:
Quote:
crt.Session.Connect "/Serial COM6 /BAUD 9600"You're also asking about the Connect window (which implies you have a Session). Quote:
__________________
Mike VanDyke Software Technical Support [http://www.vandyke.com/support] |
#3
|
||||
|
||||
Quote:
Quote:
Quote:
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:
Last edited by gunslingor; 05-15-2013 at 02:32 PM. |
#4
|
||||
|
||||
Quote:
![]() 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] |
#5
|
|||
|
|||
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.
|
#6
|
||||
|
||||
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] |
![]() |
Thread Tools | |
Display Modes | Rate This Thread |
|
|