telnetlib close not closing sockets

[Mike Monaghan]

Yannick,

Fortunately I'm not using the Microsoft Telnet server.  I'm using an
application server called mvBase.  I've had to filter some control
codes since mv loves to insert them.  It especially loves NUL and STX
but fortunately it was easily filtered on the server side.  My
application is working great now, but there's still one strange issue.
 If I run it from Windows scheduler it doesn't always complete.  It
picks a very random place to hang.  If I start it in a command prompt
it runs flawlessly.  I'm running the scheduler as an admin and my test
account is also an admin.  This is required since I'm restarting
services.

Any thoughts?

Thanks,

Mike

"Yannick Turgeon" <nobody at nowhere.com> wrote in message news:<okG4d.28703$bL1.1119138 at news20.bellglobal.com>...
> Mike,
> 
> Concerning you "expect()" problem (which is very similar to read_until())
> Probably that it's working for 1, 2, 3 commands... but after a couple more
> it's no more working? Is that your situation? I'll tell you a terrible
> secret: Window's telnet is not sending you back only your command result.
> 
> You should read this post before working any harder:
> http://groups.google.ca/groups?selm=RUSQc.43590%24Jq2.1867410%40news20.bellg
> lobal.com
> 
> The solution:
> 
> If you're facing this, you'll have to use a Telnet Program using
> "stream-mode". I'm not sure Windows' Telnet can do this. After long hours
> searching what was happening, to finally find it was caused by Windows'
> Telnet not respecting Telnet Protocol, my company bougth "Pragma
> TelnetServer" and all my telnetlib problem finally went away. I learned
> afterward about "stream-mode" so I don't know if Windows' Telnet offer this.
> 
> Really hope this help.
> 
> Yannick
> 
> 
> "Mike Monaghan" <junkmail at chipworks.net> wrote in message
> news:ab19b1e4.0409231130.6d1e1b7e at posting.google.com...
> > I do have a problem with an expect, but I'm 99% sure a control
> > character in the stream is missing from my expect statement because
> > some of the strings are being detected.  I'm going to play with it
> > again tonight.