| Title: | DIGITAL UNIX (FORMERLY KNOWN AS DEC OSF/1) |
| Notice: | Welcome to the Digital UNIX Conference |
| Moderator: | SMURF::DENHAM |
| Created: | Thu Mar 16 1995 |
| Last Modified: | Fri Jun 06 1997 |
| Last Successful Update: | Fri Jun 06 1997 |
| Number of topics: | 10068 |
| Total number of notes: | 35879 |
Hi,
The following is the problem existing in one of our sites with
the following configuration alph 1000 4/200 running digital unix
version 3.2c with MFGPRO application running on it. The other alpha
server alpha 1000 4/266 running digital unix ver 3.2c with oracle
server 7.x.
the problem observed is as follows
the system physically disconnects the connection randomly for users
from system side but the process will continue to exist on the server
and the status shows as idle.
the following errors are found in daemon.log
Mar 3 16:20:05 alpha telnetd[3522]: ttloop: read: Connection reset by
peer
Mar 3 19:24:58 alpha telnetd[5175]: ttloop: read: Connection timed out
the errors seem to be pointing towards telnetd daemon.
kindly advice me on this problem and please let me if there is any
patch available for this particular problem
thanks in advance
pradeep kumar G.
MCS Bangalore
(EMAIL : [email protected])
| T.R | Title | User | Personal Name | Date | Lines |
|---|---|---|---|---|---|
| 9063.1 | NETRIX::"[email protected]" | Ann Majeske | Fri Mar 07 1997 10:56 | 4 | |
Why don't you check your normal patch channels first? I think the idea of this notes file is to help people who have problems that don't have existing released patches. [Posted by WWW Notes gateway] | |||||
| 9063.2 | Any suggestions on this problem?... | QCAV01::NRHEGDE | T&E or R&D !? | Mon Mar 24 1997 23:36 | 12 |
Hello!
We checked for the patches.
No patches are available. As per the articles mentioned in earlier
notes files we checked for the problem of duplicate addresses also.
There is no duplicate IP address on this network.
Can network guru's give suggestions on what to look in for.
We have two digital unix machines. Both are giving the same problem.
The clients used are PC/TCP V3.1,4.0 & 4.1 on windows.
| |||||
| 9063.3 | tcpdump trace needed | SMURF::DUSTIN | Tue Mar 25 1997 09:19 | 15 | |
If this is reproducible, you need to get a tcpdump trace of the
connection(s) which get broken. The trace should help narrow down
the cause of the problem, and it will tell us whether this is a
problem with the process being killed on one end, or whether it's
a protocol problem.
You may need to run tcpdump for a long time in the background
and wait for the connection to drop, so plan for enough disk space
to hold the log file. Use pfconfig +c -a on the server and then
run tcpdump host remote_name -w log to capture the raw frames.
Then once remote_name shows an error or two, re-run tcpdump
against the log file using tcpdump -r log to decode the trace.
John
| |||||