Problems with tia on solaris
M. Hayman
>
>
>We're running tia under solaris 2.4 and are experiencing
>a lot of problems. Whenever a winsock client attempts
>to connect to a host that is currently not accessible,
>tia completely stops responding. We've tried different
>modems, different slip software, different clients -- but
>it doesn't matter; the result is the same.
>
>Everthing works great under SunOS 4.1, but unfortunately
>we need this working under Solaris 2.4.
>
>Any suggestions? Is this a known problem or unique to us?
>
Pat,
I've been trying to resolve the exact same problem, which I have
running TIA from a Solaris 2.3 system at ClarkNet (Balt-Wash area). I
can call into my brother's account on a system running TIA on SunOS 4.1.3
with absolutely no problems. I posted a detailed account of the problem
and what I thought it was to a couple newsgroups and I sent it to
tia-support on 1/6/95 and haven't heard anything back yet (10 days).
What I HAVE received, however, are about a dozen E-Mail messages from
people with the same problem on both Solaris 2.x and ULTRIX systems.
Basically, I think the problem stems from the system timeout
associated with the connect() call from TIA when it attempts to make a
socket connection. Evidently the timeout is a system parameter which is
associated with the /dev/tcp device driver - only changeable by
superuser (single users out of luck). On the Solaris system I call into,
this timeout is set to 4 minutes and 38 seconds. It's a real bitch when
I hit one of the may links on the WWW for which the host is not
responding.
To see what the timeout is for your system, type
>ftp 55.55.55.55
at your shell prompt and see how long it takes to timeout. On a SunOS
system which works it is only a couple of seconds - on the Solaris system
it is almost 5 minutes (kernel config file defaults for the 2 OSs?).
It looks like the Solaris TIA process makes a blocking connect() call,
after which the TIA data pipe goes dead until the system times out. At
any rate, TIA at my end of the SLIP connection goes COMPLETELY dead (5
<CTRL-C>s don't even terminate it) until the timeout expires. If I don't
queue up any additional TCP/IP requests from my end after requesting a
connect to an unreachable host, I can switch Trumpet Winsock to manual
mode (disable SLIP on my end), wait the ~5 minutes, Kill TIA, then start
it up again to recover. Usually I just hang up and call in again.
I posted the problem to the alt.protocols.tcp-ip group and got the
following response from W. Richard Stevens (noted TCP/IP expert):
>> My question is, as a non priveleged user is there any way to change this
>> timeout to a reasonable period of time? I presume it is a timeout
>> associated with a system connect() call to connect to a socket on a
>> remote host. Is the delay one of the parameters associated with the
>> /dev/tcp device driver? What are my options?
>
>In general no, you cannot change the system's value on most BSD-derived
>implementations, without recompiling the kernel. Some systems (e.g.,
>Solaris 2.x) provide a way (e.g., "ndd /dev/tcp tcp_ip_abort_cinterval"),
>but it's restricted to the superuser.
>
>If you do a nonblocking connect(), you can shorten the timeout (wait for
>the connect() using select() and give it a shorter timeout), but you
>cannot lengthen it from the system default.
>
> Rich Stevens
>
If this looks like your problem too, PLEASE bitch to tia-support -
since they won't answer me. I'd appreciate any help you could give me
if you find a solution.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Mark Hayman
Westinghouse Elec. Corp.
hay...@clark.net