[Support #HDQ-517625]: Assistance requested for "Gap in packet sequence" log entries from noaaportIngester

Hi Gregg,

re:
>> Which 'noaaportIngester' invocation is logging to the polarsat.log file?

> This is a great question. Can you tell me how to figure this out?

Since your setup uses the system logging daemon, you will need to
examine the configuration file(s) for the system logging daemon
to figure out which log facility (e.g., local1, local2, etc.)
is setup to log to your polarsat.log file(s).  You can then match
the log facility number (e.g., 7) to the LDM configuration file 
EXEC entry.

The rsyslog configuration file you will need to examine is

either:

/etc/rsyslog.conf

or:

a file that is included by the /etc/rsyslog.conf line:

# Include all config files in /etc/rsyslog.d/
$IncludeConfig /etc/rsyslog.d/*.conf

Figuring out which rsyslog configuration file to examine will
likely take some poking around.

Aside: use of the new logging facility in newer versions of the
LDM like v6.13.11 will make the job of figuring out which
'noaaportIngester' invocation is logging to which log file
MUCH easier.  Just saying...

For instance, if you find that the log facility being used for
logging to your polarsat.log files is, in fact, '7' (seven),
then the following LDM configuration file entry(ies) you
sent earlier is(are) the one(s) creating the output:

EXEC "noaaportIngester -I 10.0.5.50 -m 224.0.1.5 -n -u 7 -s NMC3"
EXEC "noaaportIngester -I 10.0.5.50 -m 224.0.1.7  -n -u 7 -s ENC"
EXEC "noaaportIngester -I 10.0.5.50 -m 224.0.1.8  -n -u 7 -s EXP"

However, since there should be no traffic on 224.0.1.7, and since
you said that you commented out that EXEC and the one for 224.0.1.6
yesterday and restarted your LDM, then the EXEC lines that will still
match the use of the local7 log facility will be:

EXEC "noaaportIngester -I 10.0.5.50 -m 224.0.1.5 -n -u 7 -s NMC3"
EXEC "noaaportIngester -I 10.0.5.50 -m 224.0.1.8  -n -u 7 -s EXP"

Since both 224.0.1.5 and 224.0.1.8 are "active" (i.e. are used
for transmitting products), the source of the Gap messages could
be either.

Another aside plug for using the new LDM logging facility:
With the new LDM logging facility, you can specify a unique log
file for each channel being processed.  Using the system logging
daemon limits you to the number of log facilities you can use.

WAIT!

While Steve and I were doing a Google Meet, I happened to notice
that the list of PIDs your Novra S300N is configured to process
is slightly different than what we are using (and we are setup
according to a NOAA directive sent a couple of years ago).

Here is the difference:

our Novra S300N PID list:

CMCS 192.168.1.20> show pids

        MPE PIDs being processed:       101     102     103     104     105
                                        106     107     108     150     151

        PIDs being forwarded raw:

your Novra S300N PID list:

 CMCS 10.0.5.10> show pids

        MPE PIDs being processed:       101 102 103 104 105
                                        106 107 108 151

        PIDs being forwarded raw:

So, what we want you to do is to update the list of PIDs your
Novra S300N is configured to process to match ours.  This means
that you need to add the processing of PID 150.  This is done
using the Novra 'cmcs' utility when logged into the S300N
receiver.  The help listed by 'cmcs' shows:

  add pid mpe               Specify PIDs for MPE processing.

I *think* that this means that you need to run:

add 150 mpe

from the 'cmcs' command line when logged into the S300N, but I
will not guarantee that this is the correct invocation.

Since I want to get this off to you, I will close with:

I have a suspicion that your problems are being caused by the lack of
processing PID 150 while processing PID 151.  The next test that
needs to be run is to set this PID on your Novra S300N.  It may
be the case that you will have to stop/restart your LDM after
the Novra S300N configuration change is made.




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: HDQ-517625
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.