Current version:

CAP‑Warn is a modern weather alert system designed as a full replacement for older Skywarn scripts like AutoSky. It uses the current National Weather Service (NWS) alert format and provides a far more reliable, automated experience for repeaters and AllStar nodes.

It is not Skywarn totally my own code. It is a replacement not written in python.

Because CAP‑Warn is distributed through an APT repository, your system automatically receives updates — no manual patching, editing, or file replacement required.

CAP‑Warn retrieves alerts directly from the National Weather Service CAP system and the National Hurricane Center (nhc.noaa.gov). These alerts are converted into high‑quality audio and played over your node, keeping operators informed even during rapidly changing weather conditions.

HISTORY
This is based on node manager I released in 2023 for GMRS Cap Warn was inside that as well as the CPU temp monitor
That was all based on MMWeather released in 2015. for COWP
This is a major improvement In that it no longer uses my custom installer its now using APT-GET.

2. Modern NWS API Compatibility

Although the NWS API returns alerts in GeoJSON/JSON‑LD, the underlying data is still CAP 1.2, the official federal standard for public warning messages. The API simply transforms the raw CAP XML into a clean, consistent JSON structure. This avoids the formatting issues, namespace problems, and broken XML that caused many older scripts to fail when legacy CAP endpoints were deprecated.

CAP‑Warn uses the modern, supported, and recommended NWS API format, ensuring long‑term compatibility with the current alerting system.

3. Automatic Location & Zone Detection

CAP‑Warn automatically determines your alert coverage using your device’s GPS position, then expands that location into the correct NWS forecast zone, county/parish zone, and fire weather zone.

This means the system always reports the alerts that actually apply to your area — without requiring you to manually enter UGC codes, county IDs, or zone numbers like older scripts did.

By combining point‑based alerts with zone‑level alerts, CAP‑Warn captures everything from hyper‑local polygon warnings to broader county‑wide advisories, ensuring complete and accurate weather alert coverage for your station.

Muting during nets by a chron script. This is a manual process you set timers

4. Text‑to‑Speech Options (VoiceRSS vs Piper)

CAP‑Warn supports two different text‑to‑speech engines:

VoiceRSS (Recommended) https://voicerss.org/

• Most natural, broadcast‑quality voice
• Very fast
• Requires internet
• Requires a free API key

Piper (Offline Neural TTS) asl-tts

• Works with no internet
• Included in the ASL3 repository asl-tts
• Slower and more CPU‑intensive on Raspberry Pi

If you leave the API key blank during installation, CAP‑Warn automatically switches asl-tts. Notice in testing on a pi 3b asl-tts overheated the cpu which will cause problems recommend VoiceRSS on a PI.

5. PI Hardware (Temperature, Voltage, Throttling)

CAP‑Warn includes a full Raspberry Pi hardware‑health monitoring system that checks for:

• High CPU temperature
• Low‑voltage conditions
• CPU throttling events

These alerts help identify:

• Weak or failing power supplies
• Overheating Pi boards
• Fan failures
• Heavy CPU load conditions

CAP‑Warn reads the Pi’s real‑time firmware flags to detect when the system is running too hot, when voltage drops below safe levels, or when the CPU has been throttled to protect the hardware.

PI hardware is autodetected fully Cloud server compatible

Installation Options

1. Automated Install (Recommended)

CAP‑Warn works on a wide range of systems. For example, it supports:

• ASL3
• Debian 12/13
• Raspberry Pi
• Cloud nodes
• Bare‑metal nodes

Just run:

curl -sSL [https://raw.githubusercontent.com/tmastersmart/cap-warn/main/install_capwarn.sh](https://raw.githubusercontent.com/tmastersmart/cap-warn/main/install_capwarn.sh) | bash

Once executed, this installer:

• installs the GPG key
• adds the repo
• installs dependencies
• installs CAP‑Warn
• places you in the correct directory
• tells you to run setup.sh

2. Manual Install (For those who prefer full control)

Step 1 — Install required PHP modules and tools

asterisk-core-sounds-en-gsm sounds may not be needed if you already have sounds.
We need numbers and sounds from the normal ast sounds.

sudo apt install php-cli php-curl php-xml php-mbstring php-json sox curl logrotate asterisk-core-sounds-en-gsm

core sounds may not be needed if you already have sounds.

Step 2 — Install the GPG key manually

curl -sSL [https://raw.githubusercontent.com/tmastersmart/cap-warn/main/debian/public.key](https://raw.githubusercontent.com/tmastersmart/cap-warn/main/debian/public.key) \
  | sudo gpg --dearmor -o /usr/share/keyrings/capwarn.gpg

Step 3 — Add the APT source manually

sudo nano /etc/apt/sources.list.d/capwarn.list

Add:

deb [arch=all signed-by=/usr/share/keyrings/capwarn.gpg] [https://raw.githubusercontent.com/tmastersmart/cap-warn/main/debian](https://raw.githubusercontent.com/tmastersmart/cap-warn/main/debian) stable main

After saving, continue with the next steps.

Step 4 — Update APT

sudo apt update

Step 5 — Install CAP‑Warn

sudo apt install cap-warn

Step 6 — Run setup

cd /usr/share/cap-warn
sudo bash setup.sh

At this point, installation is complete.

What About HamVoIP?

CAP‑Warn is now designed for Debian‑based systems. Originally, it was written for HamVoIP GMRS nodes, but much has changed since 2023. Today, the recommended platforms are:

• ASL3
• Debian 12/13
• Raspberry Pi OS

Final Thoughts

CAP‑Warn is built for hams who want:

• reliable weather alerts
• modern CAP parsing and hurricane support
• clean audio
• easy installation. You don’t have to know how to edit files.
• active maintenance. There will be updates.
• compatibility with ASL3 and Debian 12/13
• Works with apt-get and apt-get update cap-warn

Ultimately, CAP‑Warn provides a dependable, modern solution for weather alerts on AllStar systems.

CAP-Warn is a modern weather alert system for AllStar nodes that utilizes Common Alerting Protocol formats. It provides automated updates via APT-GET and retrieves weather data directly from the National Weather Service and National Hurricane Center. The software converts alerts into audio for broadcasting on repeaters and nodes.

The system supports Debian-based platforms, including ASL3 and Raspberry Pi OS, through automated or manual installation processes. While originally developed for HamVoIP, current versions prioritize newer operating systems for better maintenance and reliability. The software aims to offer a dependable replacement for legacy weather scripts.

Updates:

You will get updates through the update repo. Im still testing so there will be several updates until I am satisfied with the results. As time goes by I need to test this in actual storms not just with test data. If you see any strange errors or problems. or suggestions please write a comment.

Manual Upgrade Instructions (for existing CAP‑Warn installs)

To manually upgrade CAP‑Warn to the latest version, run the following commands: After running the first command you should see a message if the version has changed. Then run the second command it will not override your setup.

Code

sudo apt-get update
sudo apt-get install --only-upgrade cap-warn or just 

sudo apt-get update cap-warn

That’s it — this will pull the newest package from your repository and upgrade CAP‑Warn without touching your configuration or logs.

If you see it doing anything strange please report. I use it myself so I should notice bugs but sometimes you may be setup different than me and the weather service may use different alerts in your area.

There is a file located at /var/log/cap-warn/words_to_add.log which will show the auto upgrade for any new alerts NWS.
Sending me this log will help so those sound files can be added to the release.

Cyclone Alerts. Tested in the past but this is new reformatted code, so it needs to be tested with a active storm. It should read the alerts as they come in and not repeat them. Expecting this will need to be adjusted.

UPDATES:

1. GPS support for the $17 gps units so your mobile node will report the local alerts not those back at your home. Great for travelers and truck drivers. Should be easy setup just plug in.
2. Pushover support. Pushover would work great at remote sites instead of over the air messages temp and low voltage messages they could be sent to your phone.
3. APRS I have working code for this just not sure how im going to configure yet. Im leaning toward privacy mode so you have to be a set distance from your home location before it starts posting. And it will post with a error factor so its not exact. Much later after GPS is all tested and working. APRS would post into the net server not over the air so it will work everywhere. optional. (This is going to be a separate install for all-star,Pi-Star & WPSD nodes look for it soon.)
4. Create a special desktop version for non hams to mimic a weather radio.(later still working on this code)
   
   

The post CAP‑Warn: Modern Weather Alert Software for AllStar & ASL3 — A Reliable Storm Replacement System first appeared on Louisiana Nationwide.

EchoLink is now LIVE on the Main Hub!

You can now join the system from anywhere using EchoLink. Just connect to:

KJ5MZL‑L

This links you straight into the Main AllStar Hub, the DVSwitch server, and TGIF DMR Talkgroup 28100 — all fully bridged together.

Perfect for mobile, HT, travel, or quick check‑ins. Jump in and say hello.

The post Echolink server is now online for Louisiana Nationwide first appeared on Louisiana Nationwide.

Take apart the radio. Remove the knobs remove the screws on the back.
Under the battery is a connector is a connector we will remove later. This will allow wires to enter the radio without removing the LED as you see in the old mod.

Remove the 2 belt clip screws and the plastic under them you will use these 2 screw holes to mount the radio to your case so it stays upright and stable.

We will not use the battery you cant use the charger and battery so what we do is use a regulator set for 3.7 volts this runs the radio just fine. Remember these batteries could explode if overcharged so don’t use it.

Once taken apart you can un sorder the speaker so you can remove the front.

Unsorder the connector for the battery so we can run in power round and cos. You may wish to use shielded wire for cos connection as noise may be on the wire.

There are several different versions of the BF888 so the COS point can be in several different locations. But its on pin 1 of the chip on the back side of the board. Take care in running the wire from behind around to the top because we want to reinstall the back which is the sheild and we don’t this wire to get pinched.

All audio in and out and PTT is handled by the mic cable so nothing else to modify. Get a mic cable off amazon i have been looking for uncoiled but cant find that the coined one will need some space to fold it around.

More photos later check back..

You need a voltage regulator likely a LM2596 However some packages may create noise. So you might try more than one version one of my LM2596 caused a buzz when I shared power with the pi. Position is very important place the pi a foot away from the radio in like a amno box. Some people lower the power in the radio but if thats what your gona do then just use a usb radio and dont use the bf888. we need max power in our moble so we can go inside wallmart and still get a signal.

Orginaly i built these with 5v in. But some cars will have low voltage so im now using 12v in and a 12v to 5vusb regulator this allows a 12v fan as on this old one it has a 5v pi fan. Fans are needed in cars it gets very hot when you not in the car. And i suggest the script to report hi temp back to you on the link..

The high temp alarm is built into my node manage but im going to release it as a stand alone script in a few weeks.

There is a new cable that works on VOX and has a built in sound card for those that dont want to modify at all.

https://www.amazon.com/dp/B0DF8GSB4C?th=1

The post Modifying Bf888 for Allstar better mods first appeared on Louisiana Nationwide.

Here’s what’s actually happening, why it’s happening, and what it means for your nodes, hotspots, and packet setups.

What Linux Is Really Removing

The Linux kernel team is removing a handful of very old, unmaintained drivers that haven’t been updated in 10–20 years. These include:

• Obsolete AX.25 kernel drivers
• Old Baycom‑style serial modem drivers
• Legacy packet radio TNC interfaces
• Experimental soundmodem drivers nobody maintains

These drivers were written for hardware from the 1980s and 1990s — ISA cards, parallel‑port TNCs, and early packet radio devices that almost no one uses today.

They were removed because:

• They no longer compile cleanly
• They have no active maintainer
• They contain outdated or insecure code
• They clutter the kernel with dead modules

This is normal housekeeping, not an attack on amateur radio.

What Linux Is Not Removing

This is the part that gets lost in the panic.

Linux is not removing:

• AX.25 networking support
• KISS TNC support
• Direwolf compatibility
• USB sound cards
• USB serial CAT control
• Hamlib
• AllStar / Asterisk
• Pi‑Star hotspot support
• DMR / D‑Star / YSF digital modes
• APRS tools
• Winlink tools
• Anything used by modern ham radio systems

If your setup is newer than 2005, you are completely unaffected.

Will My Nodes Still Work?

Yes — 100% yes.

Your:

• AllStar node
• Pi‑Star hotspot
• Direwolf packet node
• APRS iGate
• Winlink RMS
• M17 reflector
• JS8Call / FT8 / WSJT‑X station

…all rely on user‑space software, standard USB/serial drivers, and ALSA sound.
None of that is being removed.

The removed drivers were for hardware that predates the Raspberry Pi by two decades.

Why People Think “Ham Radio Is Being Erased”

A few posts online took a kernel patch note like:

“Remove unmaintained AX.25 legacy drivers.”

…and turned it into:

“Linux is removing ham radio support!”

That’s not what’s happening.

The kernel team is removing dead code, not removing amateur radio from Linux.

Modern Ham Radio on Linux Is Alive and Well

In fact, Linux is still the strongest platform for:

• Digital modes
• Packet radio
• Hotspots
• SDR
• Remote rig control
• APRS
• Winlink
• AllStar
• M17

And the most important ham radio tools — Direwolf, WSJT‑X, fldigi, Hamlib, and Asterisk — are actively maintained and widely used.

Linux remains the backbone of ham radio infrastructure.

Bottom Line

Linux is not dropping ham radio support.
Linux is not erasing amateur radio.
Linux is not breaking your nodes.

What’s being removed are ancient, unmaintained drivers for hardware that almost no one uses anymore.

Your modern ham radio software and hardware will continue to work exactly as they always have.

The post Is Linux Really “Removing Ham Radio Support”? Here’s What’s Actually Going On first appeared on Louisiana Nationwide.

Many HAMS & GMRS users believe they need to buy a static IP address from their ISP to run a home node, hotspot, or DVSwitch server. Good news: you don’t. In almost every case, a simple and free tool called Dynamic DNS (DDNS) solves the problem completely.

Below is a clear explanation you can share with anyone setting up a home node, AllStar, DVSwitch, or any remote‑access ham radio system.

So someone told you you had to have a static IP to use DVSWITCH or remote connect to your node.
This is incorrect. This problem was solved way back in the 90s. Everyone should know this.

Why People Think They Need a Static IP

Most home internet connections use a dynamic IP address. This means:

• Your IP stays the same for long periods
• It can change after a modem reboot or power outage
• It is not guaranteed to stay the same forever

If you try to connect to your home node using the raw IP address, and it changes, your connection breaks. This leads people to think they need a static IP.

But they don’t.

Dynamic DNS (DDNS) Fixes the Problem

Dynamic DNS gives your home network a permanent hostname, such as:

myshack.ddns.net mycallsign.duckdns.org mynode.no-ip.org

This hostname never changes, even if your home IP does.

Your router or Raspberry Pi automatically updates the DDNS service whenever your IP changes. So instead of connecting to: 11.11.11.18
You connect to: myshack.ddns.net
And it always points to the correct IP.

DDNS Works Perfectly With DVSwitch and Home Nodes

DVSwitch, Analog_Bridge, AllStar, Pi‑Star, and other ham radio tools don’t care whether you use:

• A static IP
• A dynamic IP
• A DDNS hostname

They only care that the hostname resolves.

Port Forwarding Still Works the Same

DDNS does not replace port forwarding — it only replaces the IP address you connect to.

If your node needs ports like:

• 30001 UDP
• 30002 UDP
• 4569 UDP (AllStar)
• 62030 TCP

…you still forward those ports in your router.

But instead of connecting to your changing IP, you connect to your DDNS hostname.

DDNS Is Free, Fast, and Reliable

Popular free DDNS providers include:

• DuckDNS.org (simple, free forever)
• No-IP Free (works well, requires periodic confirmation)
• Dynu (free tier available)

Most routers support DDNS natively. If not, a Raspberry Pi can update it automatically.

When Do You Actually Need a Static IP?

Only in rare cases:

• You’re hosting a large public reflector
• You need reverse DNS (PTR records)
• Your ISP blocks DDNS updates
• You’re running a commercial service

For 99% of ham radio home setups, DDNS is the correct solution.

Summary

• You do not need a static IP
• DDNS gives you a permanent hostname
• DVSwitch and home nodes work perfectly with DDNS
• Port forwarding still works normally
• DDNS is free and takes only a few minutes to set up

Static IPs are expensive and unnecessary for almost every ham radio use case. DDNS is the modern, simple, and reliable solution.

Absolutely — here’s a clear, practical explanation you can drop straight into your WordPress article. It explains how a DDNS client works, why it solves the “I need a static IP” myth, and exactly how to use DuckDNS on a Raspberry Pi to keep a home node or DVSwitch server reachable.

I’ll keep it clean, readable, and formatted for WordPress.

How a DDNS Client Works (and Why You Don’t Need a Static IP)

Dynamic DNS (DDNS) is the secret weapon that makes home nodes, DVSwitch servers, and remote‑access systems work without needing a static IP address. The idea is simple: instead of connecting to your home’s changing IP address, you connect to a permanent hostname that always points to your current IP.

A DDNS client is the small program that keeps that hostname updated.

What the DDNS Client Actually Does

A DDNS client (like the one from DuckDNS) runs on your Raspberry Pi or router and performs three simple jobs:

1. Detect your current public IP

Your Pi asks an external service:

• “What is my public IP right now?”

This is usually done by checking:

https://api.ipify.org

or DuckDNS’s own IP check.

2. Compare it to the last known IP

If the IP hasn’t changed, nothing happens.

If it has changed (after a reboot, power outage, ISP refresh, etc.), then:

3. Update your DDNS hostname

The client sends a secure update request to DuckDNS:

https://www.duckdns.org/update?domains=YOURDOMAIN&token=YOURTOKEN&ip=YOURIP

DuckDNS instantly updates your hostname, so:

myshack.duckdns.org

always points to your current home IP — even if it changes.

This is why you don’t need a static IP.
Your hostname stays the same, and the DDNS client keeps it pointed at the right place.

Using DuckDNS on a Raspberry Pi (Simple Setup)

DuckDNS is one of the easiest DDNS services to use, and it’s completely free.
Here’s how to set it up on your Pi.

1. Create your DuckDNS domain

Go to:

Sign in with:

• Google
• GitHub
• Twitter
• Reddit

Choose a domain name, for example:

myshack

Your hostname becomes:

myshack.duckdns.org

Copy your token — you’ll need it.

2. Create the DuckDNS update script on your Pi

On your Pi:

mkdir -p ~/duckdns
cd ~/duckdns
nano duck.sh

Paste this inside:

echo url="https://www.duckdns.org/update?domains=YOURDOMAIN&token=YOURTOKEN&ip=" | curl -k -o ~/duckdns/duck.log -K -

Replace:

• YOURDOMAIN with your DuckDNS name
• YOURTOKEN with your DuckDNS token

Save and exit.

3. Make the script executable

chmod 700 duck.sh

4. Add a cron job to update every 5 minutes

crontab -e

Add this line:

*/5 * * * * ~/duckdns/duck.sh >/dev/null 2>&1

This keeps your hostname updated automatically.

How This Helps DVSwitch, AllStar, and Home Nodes

Once DuckDNS is running, you no longer connect to your home IP.
You connect to your hostname:

myshack.duckdns.org

This works for:

• DVSwitch Mobile
• Analog_Bridge
• AllStarLink
• Pi‑Star
• Private dashboards
• Remote control apps
• Custom reflectors

Your Pi stays reachable even if your ISP changes your IP.

Why This Eliminates the Need for a Static IP

A static IP is only needed if:

• You’re hosting a large public reflector
• You need reverse DNS
• You’re running a commercial service

For home ham radio use:

• DDNS is free
• DDNS is automatic
• DDNS works with every node and hotspot
• DDNS solves the “changing IP” problem completely

This is why you do NOT need a static IP to run DVSwitch or a home node.

The post How to use dvswitch without a static IP address first appeared on Louisiana Nationwide.

The post Online ham test first appeared on Louisiana Nationwide.

Shortly before you took office, the FCC stopped GMRS repeaters from being linked, even though this had been allowed for many years. Internet linking gave families a way to talk to each other across cities and states, and during hurricanes it provided vital backup when phones were down.

We contacted Congress but were ignored. I submitted comments directly to the FCC:

• https://www.fcc.gov/ecfs/document/10802544719909/1
• https://www.fcc.gov/ecfs/document/1042511135974/1
• https://www.fcc.gov/ecfs/document/10426037020584/1

We also organized a petition:

• https://www.lagmrs.com/wp/2024/08/20/petition-to-congress-to-restore-gmrs-linking/

The FCC’s response was to post on their GMRS page that repeater linking is “not in the public interest” and might cause interference. But how does a linked repeater cause more interference than one that is not linked? No interference study has ever been done, and GMRS users have already shown that linking works safely and effectively.

Unlike amateur (ham) radio, GMRS allows an entire family to use the system under one license. There is no good reason GMRS users should be blocked from linking repeaters, especially when this restriction undermines family communication and disaster response.

I ask for your help in reversing this political decision and ending the FCC’s unfair bias against GMRS users.

Respectfully,

The post Letter to the president on GMRS linking. first appeared on Louisiana Nationwide.

I recently discovered a serious security issue affecting some default Hamvoip node setups. This is likely in all nodes based on that image and needs to be fixed or you need to take your nodes webpage off the internet. Close your ports.

This may explain why some users have to reboot everything after a while to stop jitter and sluggish nodes. As rebooting will give you a new IP and stop the abuse for a while.

Certain Apache proxy modules are enabled by default, which allows your node to be used as a proxy by anyone on the Internet. This can lead to massive, unintended bandwidth usage and potentially put your node at risk of abuse or blacklisting.

At this time I don’t know which nodes have this proxy enabled likely all of them. But running this script will tell you if yours is affected or not.

In our tests, we observed extreme bandwidth consumption:

Clearly, leaving these modules enabled can lead to enormous, unmonitored network usage, potentially incurring charges or throttling from your ISP.

From the nodes webserver logs
64.xxxxxxxxx- – [30/Aug/2025:08:35:17 -0500] “GET http://api.xxxxxxx.org/?format=json HTTP/1.1” 302 –
64.xxxxxxxxx- – [30/Aug/2025:08:35:19 -0500] “CONNECT www.xxxxxxxx.org:443 HTTP/1.1” 302 –

In the above example they are using the node as a proxy to download files for them. And who knows what they are doing ( hacking, spam, illegal traffic). All of which will be coming from your IP

To prevent this, I have created a safe script to fix your node:

1. change to tmp

cd /tmp

2. Download the fix script

curl -sSL -o fix_proxy.sh https://raw.githubusercontent.com/tmastersmart/gmrs_live/refs/heads/main/fix_proxy.sh

3. Inspect it before running

less fix_proxy.sh

4. Run the script

bash fix_proxy.sh

Above is on a old GMRSLive node I converted to GMRSHUB.
This fully explains most all the problems we have had for years.
Jitter, Sluggish and lockups. Ever had to reboot your router? this is why.

this is why.

What the script does:

• Scans your Apache configuration for active proxy modules.
• Comments out all potentially unsafe proxy modules.
• Displays messages showing which modules are being disabled.
• Reboots your node to apply the changes.

Why you should act immediately:

Leaving these proxy modules active exposes your node to external abuse, which can:

• Consume massive amounts of bandwidth.
• Slow down your node for legitimate GMRS use.
• Create potential legal or ISP issues if your node is used for malicious activity.

We strongly encourage all GMRS Hamvoip node operators to review their Apache configuration and run this fix script to ensure their nodes are secure.

Manual Instructions for Advanced Users

If you prefer to manually inspect and fix your node:

1. Check which proxy modules are loaded

httpd -M | grep proxy

2. Open your Apache config file

nano /etc/httpd/conf/httpd.conf

or wherever your Hamvoip Apache config is located.

3. Comment out all potentially unsafe proxy modules by adding a # at the start of lines like:

LoadModule proxy_module modules/mod_proxy.so
LoadModule proxy_connect_module modules/mod_proxy_connect.so
LoadModule proxy_ftp_module modules/mod_proxy_ftp.so
LoadModule proxy_http_module modules/mod_proxy_http.so
LoadModule proxy_fcgi_module modules/mod_proxy_fcgi.so
LoadModule proxy_scgi_module modules/mod_proxy_scgi.so
LoadModule proxy_wstunnel_module modules/mod_proxy_wstunnel.so
LoadModule proxy_ajp_module modules/mod_proxy_ajp.so
LoadModule proxy_balancer_module modules/mod_proxy_balancer.so
LoadModule proxy_express_module modules/mod_proxy_express.so

4. Save and exit, then restart Apache:

systemctl restart httpd

5. Verify the modules are disabled:

httpd -M | grep proxy

You should only see modules that are intentionally enabled, and none of the risky proxy modules.

Takeaway: Act immediately. Leaving these proxy modules active exposes your node to abuse, which can consume massive amounts of bandwidth and may lead to network or legal issues.

I would be interested in finding out if you node is affected and which release it is. Please add your comment here. Perhaps some don’t have this but I suspect they all.

Final thought is after finding how bad this software is setup, even after patching I would not expose any ports to the internet if you need a status page you need a hub in the cloud or a hub running on a desktop. Don’t use a pi image for a hub. And don’t expose the port 222 as I am sure this old ssh also has problems. I am in the process of Harding the Louisiana Image since its also hamvoip based, to this and will have a new release tonight.
It would be interesting to see who activated this proxy by seeing which images have it.

Vulnerability of HAMVOIP and other pi images to Proxy Exploits

The Hamvoip system, particularly when configured default or unsecure settings exhibits notable vulnerabilities proxy functionalities. These weaknesses primarily stem from the default enabling certain Apache proxy modules, which can be exploited malicious actors to the node as an open proxy.

Exploitation of this vulnerability allows unauthorized users to leverage the node bandwidth for malicious activities such as illegal file transfers, spam distribution, or hacking attempts. Consequently, this can lead to bandwidth consumption, network slowdown, and potential blacklisting by service providersFurthermore the exposure of modules increases the risk of external abuse which may result in legal complications or of ISP policies. It is imperative operators to review configuration settings diligently and disable any unnecessary proxy modules mitigate these risks.

Proactive measures include running scripts designed to identify and comment out active proxy modules within the Apache configuration. Manual inspection and disabling of these modules are recommended for advanced users aiming to fort their against potential proxy exploits.

summary, while Hamvoip offers robust communication capabilities, its default proxy configurations pose significant security concerns necessitate immediate attention and remediation to prevent misuse and safeguard operational integrity.

The post Critical Security Update for Hamvoip proxy first appeared on Louisiana Nationwide.

You must have a license. obtaining-your-gmrs-license/

Notes it does reach 167 s not sure about west court

Predicted maps. Not yet in operation

Test at 35ft

Test at 100 ft .

However based on actual ABSD tracking history i get a different plot

Looking at the inner ring which is up to 999ft that almost matches the 100ft prediction

Using actual plot and reducing it down to what should be a 30 ft area i get my prediction
Only a prediction I would be shocked if I could reach the interstate. Or Natchitoches.

Just an experiment need to do actual testing

32 Ft mapping test

So above is expected actual coverage

The post Winnfield La GMRS range test Archived first appeared on Louisiana Nationwide.

GMRShub – A GMRS Radio Linking Project

GMRShub is all about freedom:

1. Freedom to Communicate:
   • On GMRS hub, you can talk to whom you want to talk. There are no restrictions or limitations on who you can connect with.
   • Unlike some other networks, GMRS hub doesn’t impose passwords or barriers. It’s a community-driven effort where members enjoy open communication.
2. Freedom to Move Around the Network:
   • Feel like changing things up? No problem! GMRS hub allows you to move around the network as you please.
   • Whether you’re exploring new areas or just want a change of scenery, GMRS hub gives you the freedom to roam.
3. Freedom to Use Your Preferred Equipment:
   • Use the radio equipment you love. GMRS hub doesn’t dictate what gear you should use.
   • Whether it’s handheld radios, mobile units, or repeaters, the choice is yours.
4. Freedom to Add Features:
   • Want to enhance your experience? GMRS hub lets you add features without limitations.
   • Whether it’s linking to other systems, integrating weather updates, or experimenting with new functionalities, you’re free to explore.
5. Community-Driven and Supportive:
   • The users on GMRS hub are fantastic. They help each other out, answer questions, and contribute to making the network better.
   • It’s a collaborative effort that keeps growing and improving over time.
6. Create Your Own Thing:
   • GMRS Live encourages creativity. If you have ideas or want to try something different, this is the place.
   • Whether you’re an experienced user or just starting out, GMRS hub welcomes you.
7. No Bad Attitudes:
   • Say goodbye to negative vibes. GMRS hub fosters a positive environment where everyone can enjoy themselves.
8. How to Get Node Numbers:
   • Visit the GMRS HUB website to learn more and request your node number.
   • Do not request a node number unless you have a node or are setting on up. Node numbers are not for DV switch or your phone.
   • Explore the community, connect with fellow enthusiasts, and enjoy the freedom of GMRS Live!

Remember, GMRS Live is more than just a network—it’s a community of radio enthusiasts who value freedom and collaboration. So whether you’re a seasoned GMRS user or a curious newcomer, give Louisiana Nationwide a try!

The post GMRS HUB and Louisiana Nationwide A GMRS Radio Linking Project first appeared on Louisiana Nationwide.