Highlighted
Super Contributor.
Super Contributor.
1339 views

Recording RTE protocol

Jump to solution

Hi , 

I'm trying to understand how to record with this protocol but I'm a bit fed up. I want to check if a server is available with a telnet or ping. I tried using telnet but nothing happen and nothing is recorded. I really dont know many of the item to configure, and I dont know it that is the problem. Anyone can help me to record a telnet to google (for example). Just do a telnet www.google.es 80/443/whatever.

 

Many many thanks

 

Tags (3)
0 Likes
1 Solution

Accepted Solutions
Highlighted
Super Contributor.
Super Contributor.

Re: Recording RTE protocol

Jump to solution

Hi, I am going to assume your objective is to probe whether a certain host:port combination is reachable over the network rather than using the RTE protocol.

 

Recording RTE in Vugen is always a bit of a challenge, at least if one mostly uses Web HTTP/HTML and the like.

You don't tell much about the context, but would your check of server work if you used something like the following?

 

Action.c:

int completed = 1;
int iter = 0;

int completed = 1;
int iter = 0;

Action()
{
    iter++;
    if (iter > 1) {
        if (!completed) {
            lr_output_message("Server is not responding");
            lr_exit(LR_EXIT_VUSER, LR_PASS);
        } else {
            lr_output_message("Server did respond");
            lr_exit(LR_EXIT_VUSER, LR_PASS);
        }
    }
    completed = 0;
    lr_continue_on_error(LR_ON_ERROR_SKIP_TO_NEXT_ITERATION);
    web_url("ssh-host", "URL=http://1.2.3.4:22/", LAST);
    completed = 1;
    return 0;
}

 

Just to use your "seat belt" and "air bag", put some sanity check into Vuser_end.c:

vuser_end()
{
    if (iter < 2) {
        lr_error_message("Script ended without running a second iterartion");
    }
    return 0;
}

 

 

 

It will probe the host 1.2.3.4 on port 22 in iteration 1 and report the status in iteration 2. (Telnet uses port 23,) So yes, make sure the run logic is run two iterations.

If you're fine with the default timeout of 20 seconds, the script will run inside maybe 21 or 22 second in worst case - i.e., when the probed host doesn't reply on the requested TCP port.

 

View solution in original post

14 Replies
Highlighted
Acclaimed Contributor.
Acclaimed Contributor.

Re: Recording RTE protocol

Jump to solution

Hello ADR,

Thank you for your post.

In order to record with RTE protocol, please see below

Make sure that you save the terminal set up so that it uses the correct or same screen during replay. To save the terminal setup, you need to:
1. Start RTE recording.
2. Go to Communication -> Connect.
3. Set up the settings/parameters and connect to your host.
4. Implement either of the following:

  • To automatically save the setting into the script's directory before the end of recording:
        Go to Terminal -> Setup -> Preferences.
       2. Enable "Save Terminal Setup" in the "On PowerTerm Exit" section.
  • To save the setting in a separate location using some other name:
        Go to File -> Save Terminal Setup as.
       2. Save the information in a file with a .pts extension.
       Note: You need to copy this .pts file to the script directory after recording.

If you are saving the script after recording:
1. You need to make sure that the termset.pts file is copied into script directly. If you prefer to use your own setup file, you need to replace the termset.pts in the script directory with your own .pts file (rename it to termset.pts).
2. Avoid saving the script to a directory that has spaces embedded in it as it cause potentially cause problem.

If you have a script that has already been saved, try the following:
1. Put a sleep statement before the TE_connect statement.

Example: sleep(100000);

  1. Run the script.
    3. When the PowerTerm display comes up:
  2. a) Pull down the "Terminal" menu to select the correct terminal type.
  3. b) Pull down the "File" menu and save the terminal setup.
  4. Stop the script execution and remove the "sleep" statement.
    5. Replay the script now.

Hope this helps.

Regards,

Daniela Gómez Alvarado
Customer Support Engineer

If you find that this or any other post resolves your issue, please be sure to mark it as an accepted solution.
If you are satisfied with anyone’s response please remember to give them a KUDOS by clicking on the STAR at the bottom left of the post and show your appreciation.
0 Likes
Highlighted
Super Contributor.
Super Contributor.

Re: Recording RTE protocol

Jump to solution

 Hi Daniela, 

 

Many thanks for your long and detailled response. I'm afraid it's not running for me. I follow your instructions but when I stop recording I dont get any code/function written in Vugen.

After press Communication -> Connect and do the telnet to google, everything seems right, although any statement is written in the console, but after that I press stop and nothing is recorded.

Any idea what is happening? 

Thanks

0 Likes
Highlighted
Super Contributor.
Super Contributor.

Re: Recording RTE protocol

Jump to solution

Hi, I am going to assume your objective is to probe whether a certain host:port combination is reachable over the network rather than using the RTE protocol.

 

Recording RTE in Vugen is always a bit of a challenge, at least if one mostly uses Web HTTP/HTML and the like.

You don't tell much about the context, but would your check of server work if you used something like the following?

 

Action.c:

int completed = 1;
int iter = 0;

int completed = 1;
int iter = 0;

Action()
{
    iter++;
    if (iter > 1) {
        if (!completed) {
            lr_output_message("Server is not responding");
            lr_exit(LR_EXIT_VUSER, LR_PASS);
        } else {
            lr_output_message("Server did respond");
            lr_exit(LR_EXIT_VUSER, LR_PASS);
        }
    }
    completed = 0;
    lr_continue_on_error(LR_ON_ERROR_SKIP_TO_NEXT_ITERATION);
    web_url("ssh-host", "URL=http://1.2.3.4:22/", LAST);
    completed = 1;
    return 0;
}

 

Just to use your "seat belt" and "air bag", put some sanity check into Vuser_end.c:

vuser_end()
{
    if (iter < 2) {
        lr_error_message("Script ended without running a second iterartion");
    }
    return 0;
}

 

 

 

It will probe the host 1.2.3.4 on port 22 in iteration 1 and report the status in iteration 2. (Telnet uses port 23,) So yes, make sure the run logic is run two iterations.

If you're fine with the default timeout of 20 seconds, the script will run inside maybe 21 or 22 second in worst case - i.e., when the probed host doesn't reply on the requested TCP port.

 

View solution in original post

Highlighted
Super Contributor.
Super Contributor.

Re: Recording RTE protocol

Jump to solution

Hi, 

 

Thanks for your answer, but I think that is not going to run as the server doesn't have any webserver running. Indeed I tried manually and it's not running, the browser is giving error.

I want to check that I can reach the server, doing a ping/telnet, whatever, and I've tried with Winsock protocol and RTE protocol and anyone is running.

RTE protocol is able to record the telnet, but when I replay I need to press a key to finish the sript replay, so it's not finishing by itself.

 

Regards

 

0 Likes
Highlighted
Super Contributor.
Super Contributor.

Re: Recording RTE protocol

Jump to solution
Hi ADR, just make sure later readers in the future don't get confused, my outlined solution probes a server on some port, no matter whether the server runs a web server or not. Yes, the solution uses the LoadRunner Web http/html protocol as the tool to probe a host for a port, so yes, I can see how confusion might arise. I might have forgotten to mention what TCP port 22 is used for - it's usually the ssh service, i.e., secure shell with (possibly) strong encryption. Did you try my solution in your environment? Replacing server and port numbers with the IP address or host name of your server and the port number with 23 for telnet? Did it work? If not, what went wrong? Please do tell, ADR.
0 Likes
Highlighted
Super Contributor.
Super Contributor.

Re: Recording RTE protocol

Jump to solution

Hi Klaus,

 

Thanks for your help. Sorry but I really dont understand your solution, however I've tried and always I'm getting "time out" and "server is not responding". I tried with several port (22,23, 443, 33434 ... ) and always the same answer. 

I dont understand how are we going to get an answer if that port doesn't have anything web running there. 

If you're sure that can run, please let me try again with your news.

Regards

 

0 Likes
Highlighted
Super Contributor.
Super Contributor.

Re: Recording RTE protocol

Jump to solution
Hi!
I tried by entering server and port of something which has a live service (I tried a local server with a live ssh service, but no web server) and got the "positive" answer from the script .
I also tried entering server and port which did NOT have a live service and got a "negative" answer from the script.

What happens when you
(1) try a telnet command from your vugen machine to some server which succeeds and
(2) enter the same id of the server and port 23 in the script and run it in vugen?

Say you are on your normal Windows workstation where you have enabled the Telnet Client in Windows, say the command
C:\> telnet happy
in a CMD window works (i.e., you see a cleared window inside one or a few seconds).
What happens if you then enter id of server in the Vugen script as happy and port as 23 and then run the script?


Good luck!
Klaus
0 Likes
Highlighted
Super Contributor.
Super Contributor.

Re: Recording RTE protocol

Jump to solution

Hi Klaus, 

 

When you say " live service" what do you mean? 

I can't replay the script in the target machine and with the server wanted but I've done an example doing the next from my machine to google web page:

Ping google.es, I get the ip and everything was good.

Telnet to google.es by 443 port, everything ok.

Vugen script replaying with ip got and port 443, it was wrong.  "Server "216.58.201.131" has shut down the connection prematurely " 

Regards

0 Likes
Highlighted
Super Contributor.
Super Contributor.

Re: Recording RTE protocol

Jump to solution

Hi,

a live service would be if you on some server (say one with IPv4 address 1.2.3.4) have a TELNET-service running. If machine 1.2.3.4 happens to be a Unix/Linux, it's probably a telnetd; if it's a Windows server, you probably have activated the Windows function "Telnet-server"). So, with a live Telnet service on your target server 1.2.3.4, you probably have the something listening on port 23 on that machine, as decimal 23 is the default TCP port for Telnet.

In case you have a Telnet CLIENT on you local workstation (again, if it's a Windows, you probably have activated the Windows function "Telnet-client") and if you have connectivity, it should work for you to start a CMD Window and to enter the command

 

    telnet 1.2.3.4  23

 

If the command seems to "hang", you probably don't have connectivity. Then you have to fix that.

If the CMD Window went all blank (no text visible) you DID succeed in opening a TCP connection over the Telnet port from your machine to the server.

Hope you're with me so far.

 

OK, so let's assume you managed to verify your machine has connectivity to the servers Telnet service. (Also known as "telnet daemon" in Unix parlance.) At this point, it makes sense if you can use my script to get a report it also succeeded in establishing such a connection. Just start Vugen and open the script, change the settings so the script tries server 1.2.3.4 and port 23 and run the script.

In the second iteration, it should tell you it did succeed.

 

Now run the  opposite test - first try in your CMD Window something which probably fails - say command

    telnet 1.2.3.4  1337

where you expect the server to NOT run any service listening on TCP port 1337. This time, if the telnet command suceeds (blank Window), you have to guess another port number until you find one which fails to connect (looks like it's hanging).

At that point, let's assume it was port 1337, you can change the Vugen script to try machine 1.2.3.4 and port 1337. Run the Vugen script and in the second iteration it should tell you it failed to connect.

 

If this plays out like this, you have just seen the script

(A) successfulyy report connectivity when there actually is connectivity to the live server

(B) succesfully report non-connectivity when there is no live service or live server to connect to

 

Hope this helps!

 

0 Likes
Highlighted
Super Contributor.
Super Contributor.

Re: Recording RTE protocol

Jump to solution

Regarding
Action.c(18): Continuing after Error -27789: Server "google.es" has shut down the connection prematurely [MsgId: MERR-27789]

is it possible you configured the script like

    web_url("ssh-host", "URL=http://google.es:443/", LAST);

rather than like

    web_url("ssh-host", "URL=https://google.es:443/", LAST);

 

Please note the difference of the s in http: versus https:

You managed to find a weakness in my script - good work! When you are configuring it to trash / mishandle the requested protocol (port 443 is default for running http encrypted so make sure to have Vugen running encryption handshake during connection establishment by using https: instead of http: in the url). I guess you told Vugen to run plain text (http:) and server signaled an error by closing the connection. Well, my little script interprets ALL errors as "connection failed".  My bad.

What happens if you change from http: to https: when you are trying an encrypted service at Google?

What happens if you try http: when you try the telnet service in talked about originally?

 

0 Likes
Highlighted
Super Contributor.
Super Contributor.

Re: Recording RTE protocol

Jump to solution
Hi ADR, did you manage achieve a working solution in the end?
0 Likes
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.