telnetlib close not closing sockets

[Mike Monaghan]

I'm rather new to python but a long time programmer. I think I've
covered my bases so I hope this isn't somthing obvious.

I'm running ActiveState PythonWin 2.3.2 (#49, Nov 13 2003, 10:34:54)
[MSC v.1200 32 bit (Intel)] on win32.

I have several processes that are polling a telnet server on a regular
basis. I'm using telnetlib for this. When I issue the .close method
the connection is not closed (no TCP FIN is sent to the server).

import getpass
import sys
import telnetlib
import smtplib
import time
import os

HOST = "fred"
tn = telnetlib.Telnet(HOST)
tn.write("DEMO\n")
print tn.read_until("\n>",5)
tn.write("OFF\n")
print tn.read_until("Logon Please:",5)
print tn.read_until("make sure socket queue is empty the hard way",5)
tn.close

I've tried several options to accomplish this, but for whatever reason
the socket remains open until I exit python. Since I'm polling in a
loop I'd prefer not to exit python. I must close the tcp connection
after each pass or I'll consume server licenses.

Any of you pythoneers have a clue where I should be looking? Is this
a bug in telnetlib, the socket handlers, or the windows port? Am I
missing something obvious? Telnetlib looks like it is making the
right close calls.

Thanks,

Mike
A python newb

 

[Yannick Turgeon]

Hello Mike,

Your subject remembered me some hard time using telnetlib on Windows. Oh God
I searched for answers!) I would be very happy to prevent you this. To
verify if you have the same problem, Could you tell me if you always reach
the timeout (5 secs) before your read_until() return?

For your current problem. Did you try with parenthesis after "close":
tn.close()

I hope it was just that!

Yannick

 

[Mike Monaghan]

Yannick,

The parenthesis after the tn.close() did the trick. I know I've made
that mistake somewhere else. Telnetlib's documentation even clearly
says .close() and I bet they mean the () is required. Thank you!!!

As for read_until, I'm not reaching timeout there. I am however
setting a timeout in the statement like so:

print tn.read_until("\n>",5)

Maybe that change is making it work for me. Did you set a timeout
value when you were testing?

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.

I have to say I'm much impressed with the python language,
documentation, and community. It will take a while to understand some
of the doc as they are written in a very technical manner. I
personally think its great because most software efforts are plagued
by poor documentation. So far all my problems have been my own.

Thanks again for your help!

Mike

 

[Yannick Turgeon]

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/[email protected]
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]

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