[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[NOAAPORT #BGK-918302]: NOAAPort ingest not working
- Subject: [NOAAPORT #BGK-918302]: NOAAPort ingest not working
- Date: Tue, 18 Jun 2019 10:56:38 -0600
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.