Conference 7.286::vtstar

219.0. "First TELNET connection takes minutes on NT/Intel" by AIMT10::SMITH (Tom Smith MRO1-3/D12 dtn 297-4751) Sun Feb 02 1997 22:27

    I've got a peculiar problem I didn't see discussed anywhere else in
    here, but I might have missed it.
    
    I have been running the 16-bit version of VT320e V1.13 on Intel/NT
    V4.0. I have just laid the files in the Intel/NT directory on
    \\prnsy5\public on top of it with no change.
    
    For about a month after I originally installed it in December,
    everything was fine. About 2 weeks ago, it began to take _minutes_ to
    make the first TELNET connection after starting up. The target host
    does not matter. During the startup process, there are no messages, and
    the login proceeds normally once the connection is made. Also during
    this time, if the VT320 windows are occluded and uncovered, they do not
    refresh themselves until the actual login begins. Other TCP/IP
    appplication startups during that time, such as Netscape or WS_FTP,
    have no problems connecting, even if it is to the same host. Subsequent
    TELNET connections after the first are completely normal.
    
    I'm using MS's "Dial-up networking" with PPP (TCP/IP only). Everything
    else about that seems to be perfectly normal. The Win 3.1 box right
    next to it with the same (original) 16-bit version of VT320e over
    Trumpet has never had any such problem. Both boxes use the same
    make/model of modem and dial into the same server on the same phone
    line.
    
    I vaguely recall reading a note somewhere about a similar "first TELNET
    connection" problem unconnected with VT320e, but I can't remember what
    or where.
    
    Any ideas?
    
    -Tom

    Duh.
    
    Well, I'll leave this here in case somebody else runs into it.
    
    There's also an ethernet connection between the NT and Win 3.1 boxes.
    If the Win 3.1 box is up and running, the VT320e connection on the NT
    box proceeds without delay, so it looks like a routing/timeout problem.
    If somebody knows how/where the routing information (other than the
    default route) is kept in NT, I'd appreciate some mail (CFSCTC::SMITH).
    
    I'm also cross-checking all the NT service/adapter/protocol bindings to
    remove the extraneous ones that have somehow crept in.
    
    -Tom