1

I am attempting to automate a telnet session in Debian, but I am having difficulty when it comes to sending commands.

By looking here, I had a good understanding of what I needed to do.

spawn telnet localhost
expect "login:"
send "test\n"
expect "Password:"
send "password\n"
sleep 10 //Time for the connection to be established
send "ls\n"

Running the script, it correctly inputed the username. It got to the password field and i'm assuming it entered it in (though I can't be for sure since passwords are left blank in Debian when entered). It stalled for the wait, then brought me back to my account (root). It did not ever connect to "test".

Modifying my code to be more like my reference:

spawn telnet localhost
expect "login:"
send "test\n"
expect "Password:"
send "password\n"
interact

This led to it immediately logging in and connecting in my "test" account. From here I tried adding commands after interact using send, echo, and just typing the command. Nothing would happen until I exited the telnet session, then I would get this error.

For send:

send: spawn id exp6 not open
    while executing
"send "ls\n""
    (file ".telnet.sh" line 8)

For echo:

invalid command name "echo"
    while executing
"echo "ls\n""
    (file ".telnet.sh" line 8)

With just the command name "ls" invalid command name "ls" while executing "ls" (file ".telnet.sh" line 8)

I realize interact gives control back to the user, but for some reason it is the only way it will actually have me connect into the account.

Does anyone know why it is having trouble connecting without interact? If not, why I cannot send those commands until the telnet session has ended with interact?

EDIT After some research I found this link, which at the end comes to a resolve that an expect script ends immediately after everything is finished, closing the telnet session. They said they fixed the issue by adding a expect "$ " to let the script know more commands are being sent its way. I tried just using the '$' symbol like the site suggested, but it ended kicking me again. So I tried this.

Here is my updated code:

#!/usr/bin/expect
spawn telnet localhost
expect "debian login"
send "test\n"
expect "Password:"
send "password\n"
expect "test@debian:~$"
send "ls\n"

Now I am still in the telnet session for about 10 seconds, and then it kicks me off. If I try to enter in a command in that time, it pauses for that time, then runs the command I typed after the telnet session closes.

Progress is being made. Slowly but surely.

Community
  • 1
  • 1
Dylan
  • 81
  • 1
  • 1
  • 13

2 Answers2

1

I solved this problem by expecting the bash again after I send my command.

When ran like this:

send "password\r"
expect "*$*"
send "ls\r"

The telnet session immediately ended. What ended up working was to expect the start of the bash script again. Because the script ends after it sends the last command, it doesn't have a chance to display the result of the command entered.

I addressed this by adding an additional expect which then allowed my command to process and get the results.

Here is my final code.

#!/usr/bin/expect
spawn telnet localhost
set timeout 10
expect "debian login"
send "test\r"
expect "Password:"
send "password\r"
expect "*$*"
send "ls\n"
expect "*$*"
send "command2"
expect "*$*"
send "command3"
expect "*$*"
send "exit\r"
Dylan
  • 81
  • 1
  • 1
  • 13
0

The problem may be because you are sending the ls command before expecting a terminal , the code expect "*$*" expects a terminal after you enter the password and the regular expression (*$*) may vary depending upon the PS1 environment variable of the telnet session, below is the code which will the list the contents of the current working directory and logs out

spawn telnet localhost
set timeout 10
expect "debian login"
send "test\r"
expect "Password:"
send "password\r" 
expect "*$*"
send "ls\r"
expect "*$*"
send "logout\r"
Ram
  • 1,115
  • 8
  • 20
  • While the regular expression varied, in my update I accounted for the exact expression. However your code helped me come to the solution. – Dylan Sep 09 '14 at 16:04