[NOAAPORT #BGK-918302]: NOAAPort ingest not working

Hi,

I moved this inquiry into our NOAAPort support department since it is
not related to the previous ldm-mcidas inquiry.

re:
> Most of our LDM problem in porting to new machines are resolved.

Very good.

re:
> The only problem is NOAA port. I configured the NOAA port, created the
> routes and ldmd.log is showing running, but there is FIFO empty message.

I would not expect any FIFO empty messages.

re:
> I
> listened the eth where the port is connected and data is flowing but there
> is an err or, which is bad UDP packet size 4032 > 1472. I am assuming
> the 1472 comes from the eth MTU minus the ipv4 header (20) + UDP head
> (8). As per ldm configuration manual, I set the ipv4 fragmentation to
> 4096 but the problem still persists.

Our recommendation is to set the following in /etc/sysctl.conf:

# Disable IPv6
net.ipv6.conf.all.disable_ipv6=1
net.ipv6.conf.default.disable_ipv6=1

#
# Enable DVBS reception
#
net.ipv4.conf.default.rp_filter = 2

#
# DVBS multicast fragment reassembly 
#
net.ipv4.ipfrag_max_dist = 0

The bad UDP packet size messages are typically an indication that the version of
'tcpdump' being used is old/out of date.  However, the last interaction we had
with a user trying to get their NOAAPort ingest working and seeing bad UDP
length messages showed that their tcpdump was current/up to date, and should
not have shown bad UDP packet lengths.  They were trying to get their NOAAPort
ingest running under CentOS 7.x.  After trying a LOT of different things, they
dropped back to using CentOS 6.10, and all of their problems went away.

Questions:

- what OS/version are you using?

- what version of 'tcpdump' are you using?

- did you make sure that the firewall on your machine was configured to
  allow all traffic from the Ethernet interface that your Novra S300N
  (I assume you are using a Novra S300N) is connected to?

  This has tripped up a number of sites setting up NOAAPort ingest.

- what does your routing look like

  The easiest way to answer this is to send us the output from
  'netstat -rn'.

- what are your LDM configuration file, ~ldm/etc/ldmd.conf, entries for
  running NOAAPort ingest?

  Ours look like:

# 20170313 - changed set of noaaportIngester instances to match:
#            
http://www.nws.noaa.gov/noaaport/document/Multicast%20Addresses%201.0.pdf
#            CHANNEL PID MULTICAST ADDRESS Port DETAILS
#            NMC     101     224.0.1.1     1201 NCEP / NWSTG
#            GOES    102     224.0.1.2     1202 GOES / NESDIS
#            NMC2    103     224.0.1.3     1203 NCEP / NWSTG2
#            NOPT    104     224.0.1.4     1204 Optional Data - OCONUS Imagery 
/ Model
#            NPP     105     224.0.1.5     1205 National Polar-Orbiting 
Partnership / POLARSAT
#            EXP     106     224.0.1.8     1208 Experimental
#            GRW     107     224.0.1.9     1209 GOES-R Series West
#            GRE     108     224.0.1.10    1210 GOES-R Series East
#            NWWS    201     224.1.1.1     1201 Weather Wire
#
exec    "noaaportIngester -n -m 224.0.1.1  -l /data/tmp/nwstg.log"
exec    "noaaportIngester -n -m 224.0.1.2  -l /data/tmp/goes.log"
exec    "noaaportIngester -n -m 224.0.1.3  -l /data/tmp/nwstg2.log"
exec    "noaaportIngester -n -m 224.0.1.4  -l /data/tmp/oconus.log"
exec    "noaaportIngester -n -m 224.0.1.5  -l /data/tmp/nother.log"
exec    "noaaportIngester -n -m 224.0.1.8  -l /data/tmp/nother.log"
exec    "noaaportIngester -n -m 224.0.1.9  -l /data/tmp/nother.log"
exec    "noaaportIngester -n -m 224.0.1.10 -l /data/tmp/nother.log"

- are the permissions on LDM executables correct?

  There are 4 routines in an LDM build that must have setuid root
  privilege:

-rwsr-xr-- 1 root ustaff  60025 May 14 19:10 ldmd
-rwsr-xr-- 1 root ustaff  11460 May 14 19:10 hupsyslog
-rwsr-xr-- 1 root ustaff 407007 May 14 19:10 noaaportIngester
-rwsr-xr-- 1 root ustaff 324768 May 14 19:10 dvbs_multicast

  Does your build have the correct permissions for these routines?
  Please send the output of:

  <as 'ldm'>
  cd ~ldm
  ls -alt bin/

re:
> Could you please help on that?

Sure, but we are going to need information about your system in order to
troubleshoot.

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: BGK-918302
Department: Support NOAAPORT
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.