This archive contains answers to questions sent to Unidata support through mid-2025. Note that the archive is no longer being updated. We provide the archive for reference; many of the answers presented here remain technically correct, even if somewhat outdated. For the most up-to-date information on the use of NSF Unidata software and data services, please consult the Software Documentation first.
Hi Heather, I just finished talking to our system administrator about your struggles getting NOAAPort to work. Here are some ideas: - if you simply added the two lines I sent you previously to /etc/sysctl.conf, it may be the case that one of the settings is replicated, and the original one is the one that is being used Please check your /etc/sysctl.conf file and make sure that there is only one line that sets net.ipv4.conf.default.rp_filter If you have more than one line, please comment out the line that is NOT: # # Enable DVBS reception # net.ipv4.conf.default.rp_filter = 2 If you have to comment out another line that is setting net.ipv4.conf.default.rp_filter, you will need to reboot to effect the change (this is not strictly true, but it is the simplest, most straightforward way to get to where you want!) - instead of sending the output of 'route', please send the output of: netstat -rn This will show the same sort of listing, but it will not try to resolve IP addresses into host names. - the last time that we helped a site get NOAAPort ingest up and running under CentOS 7, we found that, in spite of their belief that firewalld was disabled or configured to allow all traffic on the Ethernet interface to which the Novra was connected, the firewall was, in fact, still on and it was blocking the traffic I commented previously that one way to test this is to turn off the firewall completely and then see if the LDM can read the UDP stream being sent from the Novra. Since I seem to recall that all of your machines are behind a security perimeter (true?), turning off the firewall for a test should not cause a security uproar. - one last thing that just occurred to me: is the LDM build complete? What I'm getting at is: did you give the 'root' password or 'ldm's password for sudo during the LDM build and install process? Several LDM routines _MUST_ get setuid root permissions in order to run correctly. For a LDM that is built with NOAAPort (--with-noaaport specified to 'configure'), the set of LDM utilities that need setuid root permission is: ldmd hupsyslog noaaportIngester dvbs_multicast Since you are using noaaportIngester, you don't need to care about dvbs_multicast, but the rest you absolutely do have to be concerned with. A long listing of the ~ldm/bin directory should show these files with the setuid root permission set: <as 'ldm'> ls -alt ~ldm/bin drwxr-xr-x 2 ldm ustaff 4096 Feb 3 15:09 . ... -rwsr-xr-- 1 root ustaff 61332 Feb 3 15:09 ldmd ... -rwsr-xr-- 1 root ustaff 11484 Feb 3 15:09 hupsyslog ... -rwsr-xr-- 1 root ustaff 405240 Feb 3 15:09 noaaportIngester ... -rwsr-xr-- 1 root ustaff 323636 Feb 3 15:09 dvbs_multicast If these routines do not have the setuid root capability set, the LDM and NOAAPort ingestion will not work/work correctly. 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.