Difference between ConsoleKeyInfo and FunctionKey.

Question

Hello, I have different behavior when working with my network devices (Eltex MES/ESR):

SendShellCommand("enable 15");
//expecting password promt
SendShellData("mypass");
SendShellData(new ConsoleKeyInfo((char)FunctionKey.Enter, ConsoleKey.Enter, false, false, false));

When used this way I have stable device behavior when escalating privileges.

SendShellCommand("enable 15");
//expecting password promt
SendShellData("mypass");
SendShellData(FunctionKey.Enter);

But when used this way, about 50% of the time I receive a message from the device: "error - can't enable privileged mode, authentication failed".

0000 |65-72-72-6F-72-20-2D-20 63-61-6E-27-74-20-65-6E| error - can't en
0010 |61-62-6C-65-20-70-72-69 76-69-6C-65-67-65-64-20| able privileged 
0020 |6D-6F-64-65-2C-20-61-75 74-68-65-6E-74-69-63-61| mode, authentica
0030 |74-69-6F-6E-20-66-61-69 6C-65-64-2E-0D-0A      | tion failed...

Can you please clarify the difference between using FunctionKey and ConsoleKeyInfo. I would really like to understand for myself the reason for the different behavior.

Thank you.

Answer 1

Hello, please note that Scripting.Send(FunctionKey) internally translates FunctionKey to ConsoleKeyInfo and than calls Scripting.Send(ConsoleKeyInfo). So the execution is basically the same and it should not behave differently at the server side.

You can verify it by yourself if you turn on Verbose communication logging. Set the LogWriter on your Ssh or Telnet instance.

However, what can cause problems you described is how you send the data. Please note that the reliable scripting application should goes like this:

1. Wait for initial prompt (it can be login prompt; or shell prompt if you are already logged in)
2. Send command
3. Wait for prompt and process the response. Handle error response as needed.
4. Continue by step 2. and 3. until end.

In your sample code I do not see step 3 (waiting for prompt and handling response), but it is very important because it ensures that the server has processed the previous command.
On some systems we encountered issues even when a command was sent in one data packet. The data being sent had to be interleaved by small delays after each character simulating human typing. The remote system was simply not able to reliably process more than one character at a time. During the time we have learned that waiting for command's response (prompt) is the most reliable way to write scripting applications. Without it, the application can fail occasionally, just because the server did not manage to buffer next command correctly for some reason.

If you want to diagnose the issue further, please create the Verbose communication logging of successful and failed connection. Either post them here or send them to support@rebex.net for analysis.

Comments

Thanks for the answer. It was important for me to make sure that, at their core, FunctionKey and ConsoleKeyInfo work the same. One is a superstructure on the other.

I achieved the same algorithm for the Rebex.Ssh component and Putty, when both send and receive almost identical packets (as you mentioned, including inputting one character at a time with a delay). This led to failure.

In my case, as a result of numerous experiments, it turned out that the device does not allow Enable to be executed in 100% of cases, if at that moment there is a third-party connection with an already open session with privileges 15 for this user.

If a third-party session is very active in its terminal, then an authentication error occurs in 100% of cases.

It looks like the problem is on the device side.

---

OK, thank you for letting us know.