Training, Open Source computer languages
PerlPHPPythonMySQLApache / TomcatTclRubyJavaC and C++LinuxCSS 
Search for:
Home Accessibility Courses Diary The Mouth Forum Resources Site Map About Us Contact
 
For 2023 (and 2024 ...) - we are now fully retired from IT training.
We have made many, many friends over 25 years of teaching about Python, Tcl, Perl, PHP, Lua, Java, C and C++ - and MySQL, Linux and Solaris/SunOS too. Our training notes are now very much out of date, but due to upward compatability most of our examples remain operational and even relevant ad you are welcome to make us if them "as seen" and at your own risk.

Lisa and I (Graham) now live in what was our training centre in Melksham - happy to meet with former delegates here - but do check ahead before coming round. We are far from inactive - rather, enjoying the times that we are retired but still healthy enough in mind and body to be active!

I am also active in many other area and still look after a lot of web sites - you can find an index ((here))
Another telnet login failure with expect

Posted by neilvp (neilvp), 11 August 2005
Any suggestions as to why this happens....
I am running the current release of TCL & Expect from ActiveState under Windows XP pro.

If I run

spawn telnet
   expect \
   {
       "Microsoft Telnet>" { send "open $nemiaddress\r"}
       timeout {log_user 1 ; puts "Timed Out waiting for Telnet prompt"; exit}
   }    
   
   
   expect \
   {
       "User     :" { send "$username\r" }
       timeout {log_user 1 ; puts "Timed Out waiting for User    : "; error}    
   }    
   
   expect \
   {
       "Password :" { send "$password\r"}
       timeout {log_user 1 ; puts "Timed Out waiting for Password : $expect_out(buffer) "; error}  
   }
   
 
Then the process fails at the 'waiting for password' section, the telnet screen having displayed the " User   :  "prompt.

If however I put

set delay [gets stdin]

immediately before the "User   :" section then the process works fine.

So, why should putting a delaying tactic in before a section that doesn't fail enable a later section that does? I could understand if the delaying tactic was after the "User  :" bit.

The print out of the expect_buffer looks to be a lot of line feeds, - is there a limit to the size of the buffer and is the delaying tactic forcing it to be cleared?
 


Posted by admin (Graham Ellis), 11 August 2005
Been scratching my head on this one;  I know that telnetd (the daemon you're talking to) uses the stdin/stdout channels for most interaction, but a direct /dev/xxxx for password at least and perhaps user name to prevent login scripts and re-directed files working.  And sometimes this effects buffering and timing when switching from one mode to the other - type ahead not working properly or a few millisecond delay being needed.

I'm wondering if that switch occurs one step earlier than you think so that the user name is being "lost" - sent into thin air before the /dev/xxxx is ready.   The User prompt is only then picked up and the password sent as the user name.   So the code hangs when it comes to the password.   And because everything is being buffered ahead you don't realise.  

Yep ... alsmost sure that's it.   User name into thin air.  Password as user name.  Nothing left for the password prompt.  All buffered to make it very confusing.  ((No, I don't want to draw a timing diagram   ))

Posted by neilvp (neilvp), 12 August 2005
Graham, thank you for the explanation, it does make sense and putting in a delay of at least 3 seconds enables the script to work correctly. Having written my own delay routine I subsequently discovered that there is a function within Active State Expect <exp_sleep> that provides this function. I have also checked that the DUT is not sending the phrase twice. It would therefore seem to be a timing problem though 3 seconds seems inordinately long to me.



This page is a thread posted to the opentalk forum at www.opentalk.org.uk and archived here for reference. To jump to the archive index please follow this link.

You can Add a comment or ranking to this page

© WELL HOUSE CONSULTANTS LTD., 2024: Well House Manor • 48 Spa Road • Melksham, Wiltshire • United Kingdom • SN12 7NY
PH: 01144 1225 708225 • FAX: 01144 1225 793803 • EMAIL: info@wellho.net • WEB: http://www.wellho.net • SKYPE: wellho