Hi all,
Is there anyone who can answer this question? I was wondering if the telnet session could impletment auto-login process. We have some central access point here through which all devices are talked to. It's really frustrating each time you open a session and proceed with secondary login.
I tried the help mannual, but failed to find a solution.
Good request. Btw, if your access point supports SSH, try it out. It's easy then.
I think this has been discussed in other forums as well. Ramar is correct that SSH helps a little bit towards auto-login as you do not have to go through userid and password prompts and in some devices only a password prompt.
Currently there is no auto-login as part of session profile - but you can very easily create a "generic" procedure for logging into a device. This procedure can deal with opening a session, detecting prompts and appropriately sending commands so that at the end of the procedure you are logged in. In many cases involving "terminal servers", which keep previous sessions logged in, this procedure may have to detect that user is already logged in and may have to get the device out of a certain mode (e.g. from config mode back to normal mode) based on prompts or other cues.
People have talked about having a procedure inside the telnet session profile - but you will have to do the hard work of creating this procedure anyway inside session profile/testbed instead of a generic procedure in a testcase. It is true that we can handle some very common situations (e.g. assume that the first prompt is for a user and second prompt is for a password) and make logging in part of open step - but those very cases can also be programmed using a procedure quickly as well.
Anyway - we have been hearing more and more about this and we will consider improving iTest to handle these cases better. In the mean while, let us know if you need help writing a generic login procedure.
Yes, Kumar. That ever went through my mind. However, I am still confused about this generic procedure invoking. The key point is that I want to have the access handler all the time so that I could communicate with devices independently, like actions in a session. If I put it into a test case execution, it will end up with the completion of test case running without any further interaction. Do you have any suggestion?
Thanks,
I see. You need this feature for manual interaction - correct?
You will see that there is a preference in iTest for execution which can leave session windows open after execution ends. You can write a utility testcase which can open a number of sessions to different devices for you and leave them in different states so that you can then interact with the devices manually in the session windows. You can use this feature to write a testcase to log in, download software, reboot and then log in again and leave the session windows open. This way you can automate the daily task of getting a new build from software development team and setting up your testbed with the click of a button.
Yes, Kumar, you are right. That's what I exactly want. I appreciate your help very much.
I have another question now.
I am talking to a bunch of cisco devices through some terminal server. Can I use TCL Expect within my procedures so that the script could intellectually send out username and password. If I could, how should I do? I checked the mannual and found nothing on this topic. My intension is to avoid sending out useless login information when the state is logined already. Any suggestion?
Thanks,
iTest has a tcl shell application which will allow you to write any tcl code you want.
But I am assuming that you are asking a slightly different question - are you asking if a session opened by iTest's telnet application can be handled by "expect". Answer to that is no. Your code has to be either completely "expect" using our tcl shell application or entirely iTest telnet application.
One thing I would like to mention here is that whatever you can do in expect, you can do using iTest's telnet application and you can do it more easily and in a better fashion once you have used it a few times. Just like expect, you can write a procedure using telnet where based on the "prompt" (which is available to you through the prompt() query), you can decide to send whatever command you want.
Your login procedure to terminal server would look like:
open s1 session profile or testbed device url
command s1 <empty> <--- this still sends a newline. On this step, you should store the response in a variable "foo"
if [query foo prompt()] == "userid:"
then
command s1 ciscouserid
command s1 *****
end
This is just a pseudo code and you can see that you can detect what prompt was sent by the device on the empty command and based on that you can decide what to do.
