1. This forum section is a read-only archive which contains old newsgroup posts. If you wish to post a query, please do so in one of our main forum sections (here). This way you will get a faster, better response from the members on Motherboard Point.

Networking Problems with Telnet

Discussion in 'Embedded' started by rickman, Mar 31, 2014.

  1. 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
     
    George Neuner, Apr 6, 2014
    #41
    1. Advertisements

  2. There are a few 3rd party versions - nothing included with Windows.
    George
     
    George Neuner, Apr 6, 2014
    #42
    1. Advertisements

  3. 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
     
    George Neuner, Apr 6, 2014
    #43
  4. rickman

    rickman Guest

    That is why I was using Rawcap which will capture local loopback
    connections. It is only in this case the packets don't show.
     
    rickman, Apr 6, 2014
    #44
  5. rickman

    rickman Guest

    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.
     
    rickman, Apr 6, 2014
    #45
  6. 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
     
    George Neuner, Apr 6, 2014
    #46
  7. rickman

    Paul Rubin Guest

    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.
     
    Paul Rubin, Apr 7, 2014
    #47
  8. rickman

    rickman Guest

    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.
     
    rickman, Apr 7, 2014
    #48
  9. 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.
     
    Clifford Heath, Apr 7, 2014
    #49
  10. rickman

    rickman Guest

    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?
     
    rickman, Apr 7, 2014
    #50
  11. rickman

    rickman Guest

    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.
     
    rickman, Apr 7, 2014
    #51
  12. 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=<PPP> protocol=tcp

    where <PPP> 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:

    http://technet.microsoft.com/en-us/library/cc731643.aspx

    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, Apr 7, 2014
    #52
  13. rickman

    rickman Guest

    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?
     
    rickman, Apr 7, 2014
    #53
  14. Sorry, I was thinking of ssh, you're right.
    Yes, there is, even if it's only the loopback interface.
    I believe so.
     
    Clifford Heath, Apr 7, 2014
    #54
  15. 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<something> and
    get<something>by<key> 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
     
    George Neuner, Apr 7, 2014
    #55
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.