Networking Problems with Telnet

As Simon mentioned already, 0.0.0.0 means the application is listening on all interfaces [it's the same as in Unix/Linux].

The telnet client's SYN_SENT state means the listener didn't respond to the connection request. You mentioned somewhere that turning off the firewall didn't help, so this may be indicative of a problem in the application code.

Random thought: you mentioned that this application has been around for a while ... does it install Ws2_32.dll (aka Winsock)? If so, you might be working with a version that isn't completely Win8 compatible.

[An incompatible DLL shouldn't work at all, but weird things can happen if there are multiple versions of the DLL available : e.g., both in the system folder and in the application folder.]

George

There are a few 3rd party versions - nothing included with Windows. George

That's as I expected ... shows telnet is working. The garbage is just an error saying that you didn't send a valid HTML command.

I'm not familiar with Sophos, but most firewalls only log the initial connection handshake and whether it was allowed. They don't keep a log of every packet exchanged. Since telnet is allowed to call out to anyone, that is all the firewall will log.

There are some 3rd party versions, but nothing included with Windows. You'll need to Google for them.

Loopback traffic is special: the existence of the connection is recorded normally [so netstat et al works], but loopback connections don't go through normal IP packet processing - they go through a separate fast path that essentially just copies data between the buffers of the sender and receiver.

This sniffer may not be able to see loopback if it is hooked into the IP stack lower down where real packets are processed. In the loopback case, there simply aren't any real packets involved.

[Of course, I still think a sniffer should be able to handle that.]

George

That is why I was using Rawcap which will capture local loopback connections. It is only in this case the packets don't show.

--

Rick

Yep, it looks like it. Here is the line from the source.

winlibrary ws2_32.dll

Do you think I have enough evidence to point a finger at this app? I started by asking the folks in that group and we got to a point where they said I should google and I came here. I think the guy helping me there doesn't have Win8 on a machine.

BTW, even though I am feeling very frustrated with my total lack of experience with networking, I greatly appreciate the help from everyone. I especially appreciate that no one has gotten impatient with me and my lack of knowledge of even the basics.

--

Rick

From your netstat results I [think I] understand that your application is running on Win32Forth. I don't use Forth so I can't help you much if the application is the problem.

However, from glancing at Win32Forth docs, "winlibrary" simply is syntax for dynamically linking the application to the named DLL.

What I mean is: does your application bundle some version of ws2_32.dll which is copied into the host's file system when the application is installed? I.e. is there more than 1 copy of this DLL on the host?

Unless there are multiple winsock DLLs, the application code is where I would focus further attention.

George

Yes, I'm sure that is what that is.

I don't think they provide a copy of ws2_32.dll. That should be on the windows machine already, no? But I can't say for sure.

I wrote the application code, but that code has very little control over the functions of the winsock interface. There are some three or four routines called to open the socket, query the socket and close the socket. Even the code that is part of the Forth kernel isn't very complex and is unlikely the cause of the problem. This code has been running on several machines for several years with no problems until I tried to run it under Win8.

I'll try asking in the Forth community a bit more.

--

Rick

Were you never able to get Wireshark to monitor the loopback interface? When I start it, on the start screen it says "Choose one or more interfaces to capture from, then start", and loopback is one of the choices presented.

No, it never worked for me. The web site says it won't monitor loopback traffic under Windows or maybe it is Windows8, I don't remember. I used Rawcap which captures to a file, but it doesn't show any traffic with this set up. It does capture ping messages. Netstat shows telnet in a state of waiting for messages and it looks like Win32Forth is listening for a message from telnet.

--

Rick

Sorry to come in late to this conversation, but you *do* realize that the new Windows "advanced" firewall has outbound rules as well as inbound ones? Open an administrator command shell on both systems, and save and scrutinise the output of this command:

netsh advfirewall firewall show rule name=all

That will dump the entire set of firewall rules, not just the ones you see in the GUI.

Clifford Heath.

Thanks. I tried this and it did dump a boat load of items. They all start with the line

Enabled: No

I assume this means the firewall is off?

--

Rick

I dug a bit more and found the screen was cutting the list short. There are a number of entries with Enabled: Yes. Does this mean the windows firewall *is* operating? The gui controls say it is off.

--

Rick

Sorry, not sure. Redirect the output to a file and search through for the Telnet ports. Or just explicitly open Telnet as an output port and see if that changes things:

netsh advfirewall firewall add name=pass_telnet dir=out action=allow remoteport=22 profile= protocol=tcp

where is one of public private domain any. Try "any" first, that way it won't depend on what firewall profile has been assigned to your network interface. If you want to learn about profiles, read this:

Basically it's a way for Windows to apply different sets of rules to different kinds of network interfaces.

You can use a version of the above command to explicitly open Telnet as an input port on the other end as well, just change to dir=in and localport=22.

You can delete these rules using the name you gave them (I used pass_telnet, but you can use almost anything). Read the help:

netsh advfirewall firewall help

--
Clifford Heath 

> I dug a bit more and found the screen was cutting the list short.  There 
> are a number of entries with Enabled: Yes.  Does this mean the windows 
> firewall *is* operating?  The gui controls say it is off.

Thanks for all the help. Two things are not clear (at least). Why port=22? I thought the telnet port was 23?

This is all running on the same machine. There is no network interface involved. So your comment about setting the "other end" is not so clear. Do I need both settings on the same machine?

--

Rick

Sorry, I was thinking of ssh, you're right.

Yes, there is, even if it's only the loopback interface.

I believe so.

Because telnet is stuck in SYN_SENT, it is likely the call to accept() is failing. However that could be because bind() did something stupid previously ... we know that bind() didn't simply fail because the application is in LISTEN.

Socket programming generally is pretty simple, but that it has been working doesn't mean it doesn't have a bug. The get and getby family of functions are frequent sources of bugs because they are subject to OS configuration and the information you asked for may not be available.

One thing in particular to check for is the version of Winsock requested in the WSAStartup call: you have to specify a minimum and maximum version for desired code compatibility.

There were a number of incompatibilities introduced between 1.1a and

2.2 ... mainly they were thread related in the asynchronous API but there also were changes to the sockaddr structure that affected using bind() and something [I forget what] that affected using select() in a single thread.

If the code was written for a version of Winsock prior to 2.2, then under certain circumstances, possibly through no fault of your own, you may experience some very strange problems.

George