Description:
Is your feature request related to a problem? Please describe.
Currently, the Raven bridge operates as an open, unfiltered gateway between Meshtastic/Meshcore (Part 15) and AREDN (Part 97). For US amateur radio operators, running this software as-is places the control operator in direct violation of several FCC Part 97 regulations, making it legally hazardous to deploy on an active RF link.
Specifically, the current architecture introduces three major compliance liabilities:
§97.113(c) Prohibited Retransmissions: The bridge automatically routes traffic from unlicensed Part 15 users to a Part 97 network without validating if the originating station is a licensed amateur.
§97.113(a)(4) Encryption: Meshtastic traffic is natively encrypted. Passing encrypted payloads blindly over an AREDN RF link violates the prohibition on transmitting messages encoded to obscure their meaning.
§97.119 Station Identification: By spoofing the origin node to make it appear native to the AREDN mesh, the gateway obfuscates the true origin of the traffic and fails to append the control operator's callsign, who is ultimately liable for the third-party transmission.
Describe the solution you'd like
To make Raven viable for US AREDN operators, the software needs a "Strict Gatekeeper" mode (which should ideally be the default when bridging to Part 97 interfaces). This requires:
Callsign Ingress Filtering: A mechanism to parse the Meshtastic longName/shortName and drop packets that do not match a valid amateur callsign regex, or preferably, a strict whitelist.conf system.
Cleartext Enforcement: Logic to inspect the Meshtastic protobufs and explicitly drop packets originating from encrypted channels; only pure cleartext payloads should pass to AREDN.
Gateway Identity Appending: Instead of spoofing a new AREDN node for the Part 15 user, the daemon should inject the traffic using the Gateway's actual AREDN node ID, modifying the payload text to read: [MeshtasticCallsign via GatewayCallsign]: .
Describe alternatives you've considered
The alternative is requiring operators to manually police a live, automated bridge 24/7, which is physically impossible, or simply prohibiting the use of Raven on US AREDN networks entirely.
Operational Caveats to Keep in Mind
As the agent noted at the very end of its output, there are a few real-world limitations you should be aware of once this is deployed.
- The "Spoofed Sender" Loophole
Because Meshtastic does not enforce cryptographic identity tying a node to a license, any unlicensed user can change their Meshtastic longName to a valid FCC callsign.
The fix: The regex check satisfies the systemic compliance of filtering obvious Part 15 traffic, but relying strictly on the allowed_callsigns array (the whitelist) is the only way to ensure you actually know the operators crossing your RF link.
- Regex Constraints
The regex /^([A-Z]{1,2}[0-9][A-Z]{1,3})$/ strictly matches US amateur callsigns.
The fix: If your mesh ever links with international operators (or if someone uses a legal prefix/suffix like W6XYZ/R), this regex will silently drop them. For your local operational area, this is likely perfectly fine, but it's worth noting in the pull request description so the maintainer knows the limitation.
- Headless Logging
The patch makes good use of DEBUG0 and DEBUG1. Since you'll likely be running this headless, ensure your OpenWrt logging daemon (logd) is configured to capture these outputs efficiently. If someone is spoofing a callsign and getting dropped, you'll want to be able to trace that back to their Meshtastic node ID.
Additional context
Adding these features would make Raven a highly valuable, legally compliant tool for cross-network emergency communications, rather than a regulatory liability. I have a fork PR.
Description:
Is your feature request related to a problem? Please describe.
Currently, the Raven bridge operates as an open, unfiltered gateway between Meshtastic/Meshcore (Part 15) and AREDN (Part 97). For US amateur radio operators, running this software as-is places the control operator in direct violation of several FCC Part 97 regulations, making it legally hazardous to deploy on an active RF link.
Specifically, the current architecture introduces three major compliance liabilities:
§97.113(c) Prohibited Retransmissions: The bridge automatically routes traffic from unlicensed Part 15 users to a Part 97 network without validating if the originating station is a licensed amateur.
§97.113(a)(4) Encryption: Meshtastic traffic is natively encrypted. Passing encrypted payloads blindly over an AREDN RF link violates the prohibition on transmitting messages encoded to obscure their meaning.
§97.119 Station Identification: By spoofing the origin node to make it appear native to the AREDN mesh, the gateway obfuscates the true origin of the traffic and fails to append the control operator's callsign, who is ultimately liable for the third-party transmission.
Describe the solution you'd like
To make Raven viable for US AREDN operators, the software needs a "Strict Gatekeeper" mode (which should ideally be the default when bridging to Part 97 interfaces). This requires:
Callsign Ingress Filtering: A mechanism to parse the Meshtastic longName/shortName and drop packets that do not match a valid amateur callsign regex, or preferably, a strict whitelist.conf system.
Cleartext Enforcement: Logic to inspect the Meshtastic protobufs and explicitly drop packets originating from encrypted channels; only pure cleartext payloads should pass to AREDN.
Gateway Identity Appending: Instead of spoofing a new AREDN node for the Part 15 user, the daemon should inject the traffic using the Gateway's actual AREDN node ID, modifying the payload text to read: [MeshtasticCallsign via GatewayCallsign]: .
Describe alternatives you've considered
The alternative is requiring operators to manually police a live, automated bridge 24/7, which is physically impossible, or simply prohibiting the use of Raven on US AREDN networks entirely.
Operational Caveats to Keep in Mind
As the agent noted at the very end of its output, there are a few real-world limitations you should be aware of once this is deployed.
Because Meshtastic does not enforce cryptographic identity tying a node to a license, any unlicensed user can change their Meshtastic longName to a valid FCC callsign.
The fix: The regex check satisfies the systemic compliance of filtering obvious Part 15 traffic, but relying strictly on the allowed_callsigns array (the whitelist) is the only way to ensure you actually know the operators crossing your RF link.
The regex /^([A-Z]{1,2}[0-9][A-Z]{1,3})$/ strictly matches US amateur callsigns.
The fix: If your mesh ever links with international operators (or if someone uses a legal prefix/suffix like W6XYZ/R), this regex will silently drop them. For your local operational area, this is likely perfectly fine, but it's worth noting in the pull request description so the maintainer knows the limitation.
The patch makes good use of DEBUG0 and DEBUG1. Since you'll likely be running this headless, ensure your OpenWrt logging daemon (logd) is configured to capture these outputs efficiently. If someone is spoofing a callsign and getting dropped, you'll want to be able to trace that back to their Meshtastic node ID.
Additional context
Adding these features would make Raven a highly valuable, legally compliant tool for cross-network emergency communications, rather than a regulatory liability. I have a fork PR.