[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: 20061027; ldmadmin start/stop problems at SSEC

This archive contains answers to questions sent to Unidata support through mid-2025. Note that the archive is no longer being updated. We provide the archive for reference; many of the answers presented here remain technically correct, even if somewhat outdated. For the most up-to-date information on the use of NSF Unidata software and data services, please consult the Software Documentation first.

  • Subject: Re: 20061027; ldmadmin start/stop problems at SSEC
  • Date: Sat, 28 Oct 2006 11:57:39 -0600
Tom,

>Date: Sat, 28 Oct 2006 10:21:11 -0600
>From: Unidata Support <address@hidden>
>Organization: UCAR/Unidata
>To: address@hidden,
>To: address@hidden
>Subject: 20061027; ldmadmin start/stop problems at SSEC

The above message contained the following:

> I thought that this is the situation that you had been working on
> at SSEC.

The problem appears to be caused by a firewall rule that's discarding
packets destined for port 111 (the portmapper port).  If they're not
going to run a portmapper, then they should allow packets destined for
the portmapper to be rejected by the OS. This would allow programs such
as the LDM to quickly discover that a portmapper is unavailable rather
than having to deduce that from the connection attempt timing-out.

> Also, I don't think that having to turn on the portmapper
> is needed; true?

It's only necessary to run a portmapper if the LDM isn't running on port
388 AND the downstream LDM-s don't know what port it's using.

Regards,
Steve Emmerson