I have a custom app that uses a telnet connection to the Windows telnet program to use as a streaming data display. This program has been working just fine for a number of years under XP, Vista and I think Windows 7. But I need to get it working under Windows 8 and the telnet connection won't complete.
The custom app calls canned routines to create a socket and once started polls looking for a completed connection. The telnet app is then started, the connection completes and the two start talking. Under Windows 8 the two apps seem to both be doing their jobs but never complete the connection and time out.
At first I had a firewall problem but after changing some settings in the firewall program I can now see the messages being sent by each app. Further if I disable the firewall entirely the connection still is not made.
I don't know enough about networking to debug this further. Because the apps have been working just fine for a long time I don't suspect the custom app, but rather expect this is a matter of configuration related to being a Windows 8 machine.
Anyone have a clue on how to proceed debugging this? Is there a more appropriate group to ask for help?
Thanks for the suggestions. I downloaded wireshark and am trying to run it, but I'm not sure it will monitor these comms. The capture setup works on specific hardware interfaces and this traffic does not seem to be on a hardware interface. I tried a ping of 127.0.0.1 and it doesn't seem to show up in the captured data at all. Did I miss something obvious in the setup?
I dunno how this is going to help, but usually when this sort of thing happens to or around me, it's one of the following:
1: The interface that has died is violating some jot or tittle of the protocol, and previous versions of the host OS didn't care.
2: The interface that has died was perfectly good in its day, but specifications have changed and now it's obsolete (IPv5 vs. IPv6?)
3: Microsoft is staffed by lazy assholes, and they've broken something. (Of course, when this happens with Linux it's because everyone in the whole open source movement is a saint, but sometimes things just fall through the cracks, eh?)
It may just be that the custom program is failing to set up one or two defaults that used to get by, and now don't. The suggestion to put it up on a known-good machine with a protocol analyzer, then compare that with the behavior on a known-bad machine with the same protocol analyzer is, I think, going to be your shortest path to success.
Of course, if you have any need for the current version to continue working with old OS's, you'll have to get everything working and then do regression testing. Have fun!
I assume the telnet client has network connectivity generally aside from this problem? Is the application on the same or different host?
Telnet is extremely simple - though there are terminal emulation issues little can go wrong with the connection itself unless the target host:port is wrong or being blocked by a firewall.
All the versions of Windows that have a "user friendly" firewall block incoming telnet by default [telnet has long been considered a security risk], but they have generally allowed outgoing connections. A loopback connection to the same host is both an outgoing and an incoming connection. Unfortunately I don't have Windows 8 so I can't tell you where to look.
 from Vista onward there are separate "domain", "public" and "private" network profiles with differing defaults. The domain and private profiles assume a secure LAN and generally allow all outgoing traffic. The public profile is more selective.
If this is a loopback connection to the same host then it will not appear on any hardware interface. You need to monitor the loopback interface.
don't know. I have not tried connecting to it with anything else yet. What else could I try? Can two terminal programs talk to each other or does one have to be some sort of host?
Someone else had suggested a couple of tests to check the connection using the ping command. Ping localhost seems to be translated to [::1] which I guess is an IPv6 address while 127.0.0.1 is the IPv4 address. If the telnet program is connecting to localhost (I use the command line, "telnet localhost -t vtnt") and the custom program is connecting to
127.0.0.1 I suppose they could be talking to different addresses, but the reports by the firewall show 127.0.0.1 for both on the messages it displays.
Where/how is the profile set and applied? I assume this is in the Windows firewall? I am not using that, I am using Sophos. If I entirely disable the firewall all other issues go away, but the two programs still do not connect.
Yes, I have not had time to deal with Wireshark any further yet. I need to dig in and find out how to access the loopback interface.
Thanks to everyone who has replied. This is a big help!
As Grant has said, no ... you need some kind of TCP protocol server for the telnet client to talk to. Unfortunately, Windows doesn't include anything useful by default. However, you can install "Simple TCPIP Services" (echo, chargen, etc.) or an actual telnet server. These are "features" that can be installed via the Programs/Features applet in the Control Panel (assuming you have your install media handy).
One thing you can do without fuss is use "tasklist" to see if your application is running and "netstat" to check if it has a listen port open.
Unfortunately the netstat option to show the executable name puts the name on a separate line so it is hard to filter effectively ... but if you know the process id or port number to look for you can pipe the output of netstat into find.
If you are willing to use 3rd party stuff on your Win8 host you can try TCPView or tcpvcon (same download)
or Comodo Killswitch which is a ProcessExplorer work-alike which additionally can display netstat information. KillSwitch has to be installed and isn't officially supported on Win8, but AFIAK it works.
Biggest problem with all of these tools is filtering the noise ... generally they show you too much information. netstat can be run continuously, refreshing until you stop it with Ctrl-C, but it will drown you in useless data unless you know exactly what process and port to look for and filter the output using find.
You need to ping something external: another machine on your LAN or a web address (e.g., "ping
") if your host has Internet available.
"pathping" and "tracert" are other handy utilities you can try (again on external targets).
I'm not sure what "other issues" you have, but don't automatically assume that the Windows firewall is disabled under Sophos ... it might not be. The Win7/Win8 firewall is quite capable by itself (but hard to configure) and some 3rd party firewall software builds upon it rather than replacing it. [I don't know what Sophos does.]
You can check if the Windows firewall is enabled using the Control Panel applet. If it is enabled, look under "advanced settings" to see if telnet is being blocked.
WRT profiles, they are configured through the "Network and Sharing" applet ... the active profile for each NIC is indicated and can be changed (loopback always uses the private profile). The major options are set under "choose homegroup and sharing" (even if you don't think you are sharing).
Hope this helps (or at least doesn't confuse more), George
I don't know whether it is due to ignorance, laziness, incompetence, anti-competitiveness, or just an attitude of "it works with our own stuff, who cares about the rest" - but Microsoft have a long history of getting /close/ to standard protocol support and then failing on the details. For many reasons, Linux folk usually have to make a much greater effort at following protocol standards as closely as possible. They might not always succeed, but it is higher priority.
Even telnet is not immune to this. The protocol may be some 40 years old, but there are differences in the way Windows telnet client works and the way Linux telnet works. I cannot remember the details, but I discovered this when writing a small server program for a Linux machine, written in Python. All my testing was with telnet from Linux - when I then tested with Windows XP telnet, nothing worked. I am afraid I cannot remember the details of the difference. It was not hard to get the server code to work with Windows XP telnet - but I did have to change it.
Given that, it would not surprise me to hear that one version of Windows telnet works, and another fails because of changes in the program from one Windows generation to the next.
If I understand you correctly, both the server and the telnet client are on the same system. Have you tried putting them on different machines with different Windows versions, and tested combinations? For example, if XP->XP works, XP->W8 works, but W8->XP and W8->W8 fails then you know the change is on the W8 client side. (It doesn't necessarily mean that's where the /problem/ lies, just the change.)
Also try different telnet clients, such as a Linux telnet, PuTTY, msys telnet, and Windows telnet programs from older versions of Windows.
If you read the Telnet RFC, you will see that the telnet options negotiation sequence is layered on top of the basic protocol and in the absence of such negotiations, the telnet client falls back to a basic telnet capabilities model.
This model is good enough to work with many normal TCP protocols such as HTTP and SMTP so you can do the following (assuming your telnet client can specify a alternate TCP port):
(22.214.171.124). Escape character is '^]'. GET / HTTP/1.0
HTTP/1.0 302 Found Cache-Control: private Content-Type: text/html; charset=UTF-8 Location:
Content-Length: 257 Date: Wed, 02 Apr 2014 11:46:14 GMT Server: GFE/2.0 Alternate-Protocol: 80:quic
302 Moved The document has moved here. Connection closed by foreign host. =====================================================================
===================================================================== telnet news.eternal-september.org 119 Trying 126.96.36.199... Connected to news.eternal-september.org (188.8.131.52). Escape character is '^]'.
200 news.eternal-september.org InterNetNews NNRP server INN 2.6.0 (20140307 snapshot) ready (posting ok) quit
205 Bye! Connection closed by foreign host. =====================================================================
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world
Hi David, there are tons of "telnet options" (or sort thing) RFC-s published mostly decades ago. I don't know if anyone has written a client to follow/implement them all correctly in one place but I seriously doubt that. Could well be the different behaviours you have observed have both been OK and intended, who knows. I am not familiar with these options - don't remember any at the moment, really. My use of telnet in DPS is restricted to having a text line sent when I want it and receiving whatever comes my way and copying it to stdo, which must have been the very initial version of telnet.... I think I also had a "tcp segment per character" mode at some moment, not sure if this was ever any useful at all. But I do remember a telnet connection over a 100 MbpS link behaving like sort of a 2400 bpS one while I was trying it out... :D .
You are conflating "TCP" with the ever expanding universe of application protocols. "T)ransmission C)ontrol P)rotocol" is the level 4 transport stream protocol defined in the standard Internet Protocol stack.
That's all "TCP" is, and that's all I intended it to mean.
Telnet can connect to any stream based IP service, however, making a connection doesn't mean you can do anything further with it. Telnet is text based - connecting to a binary interface service almost invariably means the connection either will be dropped immediately or the telnet client will crash or hang.
Windows, by default, does not provide any text based stream services - the few that are bundled must be installed separately.
Moreover, the OP has given very little information about the environment: e.g., it still is unclear to me whether there even is more than one host involved - it seems as though he is trying to make a loopback connection to an application/service on the same host. Although he has mentioned firewall software, he has said nothing about being on a LAN, having an Internet connection, or really anything to indicate that there is anything else available for telnet to connect to other than his own application.
It also appears that he has limited knowledge of networking and of the tools Windows has available. Going only by what he has told us and not making assumptions, I was trying to help him using only what Windows provides.