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

20010614: McIDAS and ldm and firewall/security

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: 20010614: McIDAS and ldm and firewall/security
  • Date: Thu, 14 Jun 2001 13:10:16 -0600
>From: Mike Voss <address@hidden>
>Organization: San Jose State University
>Keywords: 200106141621.f5EGLPp02317 LDM McIDAS firewall ports

Mike,

>I'm putting my ldm machine (rossby.met.sjsu.edu) behind our campus
>firewall, but I'd like to clarify a few things. I have read some of the
>support archives and it seems that as long as port 388, 500, and 503
>are open then ldm and mcidas should work fine.

That is correct.

>My network
>administrators on campus asked me if it runs on udp or tcp. I looked in
>/etc/services and saw that port 388 has two entries one for tcp and one
>for udp. Does this mean that both of these services must be available
>through this port?

Here is the response that Russ Rew sent on this subject to Dan Vietor
(Unisys) back in September of 2000:

  As far as I can tell, the only use of UDP port 388 is to provide
  support for old LDM version 4 protocol.  There is still some use of
  LDM 4 protocols at sites receiving WSI radar data via a satellite
  feed:  the host that redistributes the WSI data to a local server uses
  LDM 4 protocols.
  
  Here's an answer Glenn gave to this some time ago:
  
    The ldm version 4 protocol requires UDP for the FEEDME and NOTIFYME.
    The ldm version 5 protocol currently uses only TCP. BUT, when we
    drop support for version 4, we are going to try using UDP for
    transport.  We have some experiments and development planned using
    broadcast and multicast which will depend on udp. (The rational is
    that we are network limited, rather than CPU limited. TCP puts more
    load on the network (and the kernel) and less on the user
    process. By moving the product assembly up into user space, and
    using smallish (No network reassembly) UDP packets, we may get
    better performance.)
  
  Whether we will use UDP in this way in the future is unclear, since
  our multicast developments are still on hold.

>And for Mcidas, I noticed ports 500 and 503 had just
>tcp entries, and so can I assume that they only need tcp to run?

That is correct.  I have to chime in that one site commented that they
needed to open udp on both of these ports to get their ADDE remote
server working, but I was convinced at the time that there was
something wrong on their system.  No other site has noted that they
needed to do this, so I really don't think it should be necessary.

>Thanks for clarification,

I hope that this helped.

Tom