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

20050412: "Unable to receive" message in logfile

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: 20050412: "Unable to receive" message in logfile
  • Date: Tue, 12 Apr 2005 16:07:10 -0600
Angelo,

>Date: Tue, 12 Apr 2005 11:52:30 -1000
>From: "Alvarez, Angelo CIV NAVPACMETOCCEN JTWC" <address@hidden>
>Organization: NAVPACMETOCCEN/JTWC
>To: "Steve Emmerson" <address@hidden>
>Subject: RE: 20050412: "Unable to receive" message in logfile

The above message contained the following:

> There is a firewall b/t oahu and gw2-dmz.  Oahu sees the connection
> coming from gw2-dmz which is an interface on the firewall.  We never
> setup an "address transform" rule for the downstream system (do we need
> to in this version of LDM??).

I'm not sure what you mean by an "address transform rule", so I'll just
tell you what needs to happen and, hopefully, you'll be able to take it
from there.

A downstream LDM makes a TCP connection to port 388 on an upstream host
(so the downstream LDM must be able to reach port 388 on the upstream
host).  The TCP connection uses a temporary port on the downstream host
that was assigned to it by the operating system.  The upstream LDM uses
the same TCP connection to send data packets to the temporary port on
the downstream LDM.  The firewall must be configured so that packets on
the TCP connection are allowed to flow both ways.  The easiest way to do
this is to allow packets that have port 388 in EITHER their source or
destination addresses to flow unimpeeded.

> This used to work before when oahu was
> running ldm-5.2.binary.

Odd.  That aspect of the LDM hasn't changed.

> Does the failure of the nullproc messages mean
> that the downstream will not be able to receive from the upstream?

Very likely.

> v/r
> angelo
> 
> Angelo Alvarez
> System Administrator
> NAVPACMETOCCEN/JTWC
> https://www.npmoc.navy.mil
> email: address@hidden
> phone: 808.471.3645

Regards,
Steve Emmerson