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

Hi Heather,

re:
> So it is warm and sunny here and we had a lot of melting.  My novra stats are 
> back to normal:
> Carrier to Noise C/N: 14.9dB
> Signal Strength:      -49 dBm

It looks like reception should be back to normal.

re:
> I really thought that my server would ingest!  But, alas it is not : (

Rats!

re:
> I did another tcpdump on eno2.  Yesterday's output looked good, but when I 
> ran it again today, it looked bad again:
> 15:05:56.309648 IP 10.0.9.51.48987 > ietf-1-low-audio.mcast.net.eoss: UDP, 
> bad length 4032 > 1472
> 15:05:56.309651 IP 10.0.9.51 > ietf-1-low-audio.mcast.net: udp
> 15:05:56.309925 IP 10.0.9.51 > ietf-1-low-audio.mcast.net: udp
> 15:05:56.310155 IP 10.0.9.51.48987 > ietf-1-low-audio.mcast.net.eoss: UDP, 
> bad length 4032 > 1472
> 15:05:56.310158 IP 10.0.9.51 > ietf-1-low-audio.mcast.net: udp
> 15:05:56.310404 IP 10.0.9.51 > ietf-1-low-audio.mcast.net: udp

I am not sure why there are 'bad length' messages.  4032 is the correct
length.  Here, for comparison, is a bit of 'tcpdump -i eth1' output from
one of our NOAAPort ingest machines:

20:57:49.334690 IP 10.0.9.51.48987 > ietf-1-low-audio.mcast.net.eoss: UDP, 
length 4032
20:57:49.334911 IP 10.0.9.51 > ietf-1-low-audio.mcast.net: udp
20:57:49.335017 IP 10.0.9.51 > ietf-1-low-audio.mcast.net: udp
20:57:49.335150 IP 10.0.9.51.48987 > ietf-1-low-audio.mcast.net.eoss: UDP, 
length 4032
20:57:49.335290 IP 10.0.9.51 > ietf-1-low-audio.mcast.net: udp
20:57:49.335422 IP 10.0.9.51 > ietf-1-low-audio.mcast.net: udp
20:57:49.335600 IP 10.0.9.51.48987 > ietf-1-low-audio.mcast.net.eoss: UDP, 
length 4032

What is the output from the following:

<as 'root'>
ethtool -k eth1 | grep udp-fragmentation-offload

re:
> I checked and the netstat looks good, and the firewall and iptables are both 
> disabled.
> [root@npingest ~]# netstat -rn
> Kernel IP routing table
> Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
> 0.0.0.0         10.2.15.1       0.0.0.0         UG        0 0          0 eno1
> 10.2.15.0       0.0.0.0         255.255.255.0   U         0 0          0 eno1
> 10.2.15.0       10.2.15.1       255.255.255.0   UG        0 0          0 eno1
> 192.168.0.0     0.0.0.0         255.255.255.0   U         0 0          0 eno2
> 224.0.0.0       192.168.0.10    240.0.0.0       UG        0 0          0 eno2

I vaguely remember (possibly dreamed) another user that was positive that
their firewall was turned off when it was, in fact, on, and that turned
out to be the cause of their ingest problem.  I am not saying that you
are incorrect in your assertion that your firewall is off, but the
firewall being on would explain not being able to ingest the UDP output
from the Novra S300N on your eno2 Ethernet interface

What is the output from:

<as 'root'>
systemctl status firewalld

re:
> I just don't know what to do next.

I'm in no better shape :-(

I am at home today.  Perhaps we could do a Google Hangout?  I
yes, I'll need to boot up my Windows laptop; please let me know.

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: Open
===================
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.