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

[NOAAPORT #GGP-872890]: New Noaaport server with ldm

Hi Heather,

re:
> Good news!

I always like good news :-)

re:
> I rebuilt my server today with CentOS 6.10.  After A LOT of false starts,
> I was able to get the ldm running!  Both with and without my firewall!

I am assuming that you mean LDM running and NOAAPort ingest working.
Let's continue ...

re:
> Interestingly, the tcpdump still shows the UDP length of 4032,

This length is correct.  The thing that was not making any sense was
the 'bad length' indication.

re:
> but is not showing any errors:
> tcpdump -c 20 -i eth1
> tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
> listening on eth1, link-type EN10MB (Ethernet), capture size 65535 bytes
> 15:21:54.501346 IP 10.0.9.51 > ietf-1-low-audio.mcast.net: udp
> 15:21:54.501353 IP 10.0.9.51.48987 > ietf-1-low-audio.mcast.net.eoss: UDP, 
> length 4032
> 15:21:54.501604 IP 10.0.9.51 > ietf-1-low-audio.mcast.net: udp
> 15:21:54.501607 IP 10.0.9.51 > ietf-1-low-audio.mcast.net: udp
> 15:21:54.501859 IP 10.0.9.51.48987 > ietf-1-low-audio.mcast.net.eoss: UDP, 
> length 4032
> 15:21:54.502119 IP 10.0.9.51 > ietf-1-low-audio.mcast.net: udp
> 15:21:54.502122 IP 10.0.9.51 > rwhod.mcast.net: udp
> 15:21:54.502356 IP 10.0.9.51.44173 > rwhod.mcast.net.ssslic-mgr: UDP, length 
> 4032
> 15:21:54.502361 IP 10.0.9.51 > rwhod.mcast.net: udp
> 15:21:54.502621 IP 10.0.9.51 > rwhod.mcast.net: udp

This is the way the 'tcpdump' listing _should_ look.  :-)!

re:
> Now for some, not-so-good news ...

Maybe I should stop reading ;-)

re:
> While my noaaport ingest server has been down, we had been getting our 
> noaaport
> data from idd at ucar.

You are welcome ;-)

re:
> Since my ingestor is now working, I went to our decoding server and stopped 
> the
> ldm, commented out the idd request, and uncommented my npingest request.
> I cleaned out the queue, made a new one, started the ldm

OK.  You really didn't have to delete and remake the LDM queue, but no harm.

re:
> And ....
> 
> nothing.

At this point, you should immediately look at the LDM log files on both
your decode and npingest machines to see what, if any, errors/status
messages are being logged.

re:
> So I again stopped the firewall on my ingestor.  Boom!  Starting getting
> data on my decoding server.

OK.

re:
> My iptables have not changed on my decoding server.

These wouldn't make any difference unless there was a rule blocking outbound
traffic to port 388 on remote machines.  This should not have been the
case since you were successfully REQUESTing from idd.unidata.ucar.edu.

re:
> My iptables for my ingest server are the same as they were before.

Interesting.

re:
> What am I missing?

Unknown.  Are there some relevant messages in /var/log/messages?

re:
> [root@npingest ~]# cat /etc/sysconfig/iptables
> # sample configuration for iptables service
> # you can edit this manually or use system-config-firewall
> # please do not ask us to add additional ports/services to this default 
> configuration
> *filter
> :INPUT ACCEPT [0:0]
> :FORWARD ACCEPT [0:0]
> :OUTPUT ACCEPT [0:0]
> -A INPUT -i lo -j ACCEPT
> -A INPUT -i eth1 -j ACCEPT
> -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
> -A INPUT -p icmp -j ACCEPT
> -A INPUT -p tcp -m state --state NEW -m tcp --dport 22 -j ACCEPT
> -A INPUT -j REJECT --reject-with icmp-host-prohibited
> -A FORWARD -j REJECT --reject-with icmp-host-prohibited
> COMMIT

I see the problem: your iptables does not have a rule that allows traffic
on port 388.  You should add the following line immediately after the line
that has --dport 22:

-A INPUT -p tcp -m state --state NEW -m tcp --dport 388 -j ACCEPT

After adding this line, do the following:

<as 'root'>
service iptables restart

Data should start flowing from npingest to the decode machine.

re:
> 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: GGP-872890
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.