Anne Wilson wrote:
>
> First, my assumption is that the question you are asking is, "Does it
> typically take longer to make an LDM connection if the *portmapper
> connection* does not work." All LDM connections are via RPC - there are
> no non-RPC connections occuring.
OK, so you are saying that all communication is via RPC, and that first
LDM tries to use port 388, and then tries to get a dynamic port thru the
portmapper.
>
> Second, my understanding is that you wish to feed from moonbow to some
> machine X, and that linus.atd.ucar.edu and spol-nssl each also feed from
> moonbow without the delay you're experiencing. Please correct me if I'm
> wrong about this.
Sorry if I wasn't clear :
spol-nssl is in Norman, for a field project. It gets LDM feeds from
linus.atd.ucar.edu
moonbow.rap.ucar.edu
eldm.fsl.noaa.gov
Only the connection to moonbow shows the intermittent errors about RPC
failures.
>
> It is hard to say what is "typical" because configurations across
> machines vary so much. I can tell you that an LDM client does not
> require that port 111 be available on the remote machine as long as port
> 388 is available. The client will try port 388 first. If port 388 is
> not available, then the client will try to contact the remote portmapper
> on port 111. If neither are available the client will give up.
>
> It seems like your client machine X is either not trying port 388 first
> or is not allowed there initially but is allowed through later. (It is
> also apparently not allowed via the portmapper.) I can't explain this.
> Is your name service working properly on X? Can you do a forward and
> reverse lookup to moonbow? What happens if you using moonbow's IP
> address instead of its name in your request?
Yes, forward and reverse name lookup works to moonbow. If the problem
re-occurs, I'll use moonbow's IP address, rather than its name.
>
> You can try ldmping to moonbow from X. ldmping will report the state of
> the connection. Here are the states the client will go through in
> increasing order:
>
> typedef enum {
> H_NONE = 0, /* ground state (empty) */
> NAMED, /* initialized, a service is defined */
> ADDRESSED, /* we got an network address (nameservice okay) */
> PMAP_CLNTED, /* CLNT handle to remote portmap or rpcbind */
> MAPPED, /* and we got remote address (port) */
> H_CLNTED, /* clnt side handle */
> RESPONDING /* clnt is responding okay */
> } remote_state;
>
> (The code will jump across the state PMAP_CLNTED on the first try.)
> Please let me know the result of your ldmping test. Also, please let me
> know the name of machine X, and I will try some diagnostics myself.
Here's the result:
$ ldmping moonbow.rap.ucar.edu
May 09 19:22:22 State Elapsed Port Remote_Host
rpc_stat
May 09 19:22:22 RESPONDING 0.050303 388 moonbow.rap.ucar.edu
May 09 19:22:47 RESPONDING 0.020030 388 moonbow.rap.ucar.edu
May 09 19:23:12 RESPONDING 0.020033 388 moonbow.rap.ucar.edu
I'm assuming the state can be "RESPONDING", even if the portmapper is
unreachable.
