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

[LDM #LVZ-644152]: LDM install with noaaport option



Hi Vivian,

re:
> Thanks, for all the feedback.  I just sent another support via email
> because I was not sure the attachment went through.

OK.

re: is it possible that CC was defined to be 'c89' in the environment in
which you ran 'configure'?

> Yes I did build it with the default which resorts to C89.  I just
> tried it with gcc and same errors, I also tried it before with just cc and
> same problem.

OK.  To be clear: do the errors you are seeing occur when trying to build
NOAAPort v1.7.1?  If yes, then we can drop discussion of why there are
errors since the "correct" approach is to build the NOAAPort ingest portion
of the LDM along with the LDM itself.

re: In order to run the NOAAPort ingesters, one needs to add appropriate EXEC
lines to one's ~ldm/etc/ldmd.conf file.  Did you add those lines to your 
'ldmd.conf'
file?

> Yes, I added the appropriate lines to the ldmd.conf file with the new
> noaaIngest lines, but the multicast was not working, so I tried the
> deprecated as well and still no go.  This is why I thought I would need the
> noaaport code.

It is easily possible that the NOAAPort ingest portion of the LDM build is
fine AND will work fine when everything else that could it prevent it from
working is cleared up.  The most common problem I have seen is when the
firewall on the machine running the LDM and NOAAPort ingest code is not
setup to allow the UDP traffic from the Novra S300:

- the typical setup for a NOAAPort ingest machine is for there to be two
  Ethernet ports in use:

  - one over which the machine will communicate on one's LAN

  - the other dedicated to the UDP stream output from a Novra S300

  In this setup, the machine's firewall has to be configured to
  allow traffic from the Ethernet port that is dedicated to NOAAPort
  ingest.

  NB: you/your system administrator can test to see if there is anything
  on the UDP stream from the Novra S300 using the system utility
  'tcpdump'.  For instance, if the Novra is connected to eth1, then
  one would run:

  <as 'root'>
  tcpdump -i eth1

  If 'iptables' is being used as the firewall on your machine, its
  configuration (/etc/sysconfig/iptables) should have a rule that looks
  something like:

  -A INPUT -i eth1 -j ACCEPT

- the other thing that needs to be setup on the machine is static routing
  for the UDP streams.  We do this using:

  /etc/sysconfig/static-routes

  The contents of this file on one of our Linux NOAAPort ingesters is:

  any net 224.0.0.0 netmask 240.0.0.0 gw 192.168.1.6 dev eth1

  Here, 192.168.1.6 is the IP address of the Ethernet interface into which
  the Novra output is plugged.

  You can check to make sure that your routing is setup correctly by
  running 'route' (as 'root').  Here is what our's looks like on one
  of our Linux NOAAPort ingest machines:

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         flr-n140.unidat 0.0.0.0         UG    0      0        0 eth0
128.117.140.0   *               255.255.255.0   U     0      0        0 eth0
link-local      *               255.255.0.0     U     1002   0        0 eth0
link-local      *               255.255.0.0     U     1003   0        0 eth1
192.168.1.0     *               255.255.255.0   U     0      0        0 eth1
224.0.0.0       chico.unidata.u 240.0.0.0       UG    0      0        0 eth1

  The operative line is the last one.

  This, of course, is in conjunction with how our port is setup:

# ifconfig
eth0      Link encap:Ethernet  HWaddr 00:30:48:2A:36:6A  
          inet addr:128.117.140.37  Bcast:128.117.140.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:3875507459 errors:0 dropped:321 overruns:0 frame:0
          TX packets:295392927 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:3539425512 (3.2 GiB)  TX bytes:753507176 (718.6 MiB)

eth1      Link encap:Ethernet  HWaddr 00:30:48:2A:36:6B  
          inet addr:192.168.1.6  Bcast:192.168.1.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:250455824 errors:10 dropped:0 overruns:0 frame:9
          TX packets:39 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:2588320291 (2.4 GiB)  TX bytes:2796 (2.7 KiB)

lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:29148 errors:0 dropped:0 overruns:0 frame:0
          TX packets:29148 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:22613797 (21.5 MiB)  TX bytes:22613797 (21.5 MiB)

The point I am not doing well to make is that there are several things
that could be preventing the NOAAPort ingest processes from working,
and the most likely ones are firewall preventing flow on the interface
that the NOAAPort UDP stream is coming into and static routes for
the UDP IPs.

re:
> -- Okay, I will start from scratch and follow-up tomorrow.  Initially I
> tried to use the AWIPS2 rpm, but that did not work so I decided to just us
> straight LDM.

What did not work with the AWIPS RPMs?  If it contained pre-built NOAAPort
ingesters, then I think that the problem with ingesting is more likely to
be related to the UDP flow not being allowed into the machine.

re:
> I have had great success with that and now I quite
> frustrated.  Probably starting from scratch is good and to remove all
> lingering software, otherwise it is unkown where I am starting.

Yup.  And, making sure that there really is data flowing into the
Ethernet port from the Novra (use 'tcpdump') and everything else
is setup OK.

re:
> I will begin now,
> Thanks

No worries.

Cheers,

Tom
--
****************************************************************************
Unidata User Support                                    UCAR Unidata Program
(303) 497-8642                                                 P.O. Box 3000
address@hidden                                   Boulder, CO 80307
----------------------------------------------------------------------------
Unidata HomePage                       http://www.unidata.ucar.edu
****************************************************************************


Ticket Details
===================
Ticket ID: LVZ-644152
Department: Support LDM
Priority: Normal
Status: Closed


NOTE: All email exchanges with Unidata User Support are recorded in the Unidata inquiry tracking system and then made publicly 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.