[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
20040322: strange ADDE issue on newpsn (RH 9) (cont.)
- Subject: 20040322: strange ADDE issue on newpsn (RH 9) (cont.)
- Date: Mon, 22 Mar 2004 12:22:26 -0700
>From: Robert Mullenax <address@hidden>
>Organization: UCAR/Unidata
>Keywords: 200403190340.i2J3enrV010796 McIDAS ADDE ident port 113
Hi Robert,
>I looked at the .TXT files on both machines (home and Universal..RH WS 3
>and RH 9) and they looked fine, but I just deleted them anyway and redid
>them.
Good. This is the quickest way to test if there is a problem with the
name/IP mapping in the files.
>I now
>can access newpsn.nsbf.nasa.gov, but the response is slow (30 second
>delay). What was the setting you talked about that could cause this?
I had to talk with our system administrator, Mike Schmidt, to refresh
my memory about what is going on. The following reflects the conversation
he and I just had:
What is happening is that the server (newpsn in your case) is first
doing a forward and reverse name lookup for the requesting client, and
then it is trying to contact the ident (auth) server on the client to
verify its identity. The ident server connection is using port 113, so
if this port is blocked on the client side, the connection will fail by
timing out, and the timeout period is 30 seconds. One solution to the
problem is to open port 113 on the client machine(s). This will work
even if there is no service that will respond on that port (so there is
no security hole). The server will succeed in connecting to port 113,
but it will not find a ident server, so it will fail quickly, and the
transaction will continue.
Mike seems to recall that there might be a configuration option on tcp
wrappers on the server side that would either turn the timeout period
way down (to 1 second instead of 30, for instance), or not do the
ident/auth checking. He took a quick look at man pages on Linux, but
did not see anything that looked promising. You may want to check
further.
>I just did a stock McIDAS install. The slowness doesn't happen when
>connecting from uldbldm.nsbf.nasa.gov to newpsn.nsbf.nasa.gov. uldbldm is
>a Solaris 8 SPARC box. It seems to me that any box that has McIDAS compiled
>with gcc/g77 responds slowly to newpsn.nsbf.nasa.gov.
The slowness has nothing to do with the set of compilers used to build
the McIDAS distribution. One community machine I used for testing on
Saturday used gcc/g77 to build McIDAS. The reason it had fast access
to newpsn was it did not have port 113 blocked.
>The only machine
>that gets a quick response is the Solaris 8 SPARC box. I also tried
>a couple of gcc/g77 Solaris x86 boxes.
Again, it is not a compiler-related issue, but, rather, it is related
to ident (auth) processing on the client side.
>Thanks,
No worries.
Tom
--
NOTE: All email exchanges with Unidata User Support are recorded in the
Unidata inquiry tracking system and then made publically available
through the web. If you do not want to have your interactions made
available in this way, you must let us know in each email you send to us.
>From address@hidden Mon Mar 22 13:18:26 2004
Okay, thanks. I will see about port 113.
There is still something weird going on with newpsn that is ADDE related,
I think (not access from external but in getting data), but I don't have
enough info yet to formulate a question.
Thanks, Robert