[FEATURE 802] multicast options in wsjtx relay download request

[alanhargreaves]

What does this PR do?

Makes it easier to use multicast with the wsjtx-relay code addressing #802

The change

• Adds a configuration setting wsjtxRelayMulticast with default { enabled: false, address: '224.0.0.1' }
• Allows this to be edited on the Stations panel within settings
• Uses this information in PSKReporter to pass a multicast address to the server API if one is set
• Updates server/routes/wsjtx
  • to modify the downloaded start script to include the multicast address if it has been provided
  • fixes a bug that mktemp doesn't work on macOS the same way that it works on linux for the downloadable run script
• Updates wsjtx-relay/relay.js
  • replaces instances of 127.0.0.1 with the supplied multicast address if it was given one
• The PSKReporter panel for WSJT-X, when a relay is not running
  • shows the multicast address if it has been set
  • has a link to the Installation instructions (wsjtx-relay/README.md) in the main branch on GitHub
• Updated the installation instructions in wsjtx-relay/README.md
• addressed a markdown lint issue in the main README.md

Type of change

• Bug fix
• New feature
• Performance improvement
• Refactor / code cleanup
• Documentation
• Translation
• Map layer plugin

How to test

Note that I've only tested this on MacOS. It should be absolutely fine on Linux and Windows as the only thing I've done in the start script is to add an argument for multicast if it is necessary. It might be nice if someone could check Windows.

Assuming that you do not currently have wsjt-x being listened for in your server

1. Verify that the Multicast settings are present on the Station page of Settings
2. Check the checkbox to enable it
3. Go to the WSJT-X tab in the PSK Reporter Panel
4. You should see
   • the multicast address listed
   • A link to the Installation instructions. Clicking this should open a new tab. Note that before merge, this will be the unchanged wsjtx-relay/README.md.
5. Click the box with your OS to download the run script
6. Look at the downloaded script in your Downloads folder
7. If you are on MacOS or Linux, you need to add execute permission to the script.e.g.

chmod +x start-relay.sh

8. Run the script. e.g.

./start-relay.sh

9. Once the script is running, and you have wsjt-x configured to send to a multicast address, you should see the reporter screen start to populate.

It would probably also be useful to follow the instructions in wsjtx-relay/README.md to ensure their correctness.

Checklist

• App loads without console errors
• Tested in Dark, Light, and Retro themes
• Responsive at different screen sizes (desktop + mobile)
• If touching server.js: caches have TTLs and size caps (we serve 2,000+ concurrent users)
• If adding an API route: includes caching and error handling
• If adding a panel: wired into Modern, Classic, and Dockable layouts
• No hardcoded colors — uses CSS variables (var(--accent-cyan), etc.)
• No .bak, .old, console.log debug lines, or test scripts included

Screenshots (if visual change)

WSJT-X Panel before:

WSJT-X Panel after

Station Settings Panel

[alanhargreaves]

For the What's New, I think worth noting that our longer term goal is to replace wsjtx-relay with the rig-bridge code. This was done to simplify getting multicast working with the existing code in the interim.

[accius]

Hey @alanhargreaves, thanks for this — multicast support is a great addition. Found a few issues during review:

1. Operator precedence bug in Windows script (breaking)

In server/routes/wsjtx.js, this line:
'echo Address: ' + multicastAddress ? safeMulticastAddress : '127.0.0.1' + ' Port: 2237,'
Due to JS operator precedence, 'echo Address: ' + multicastAddress evaluates first as a truthy string, so the
ternary always picks safeMulticastAddress — even when multicast is disabled. Needs parens:
'echo Address: ' + (multicastAddress ? safeMulticastAddress : '127.0.0.1') + ' Port: 2237'
Also there's a stray comma at the end of 2237, inside the string.

2. Double multicast join in relay.js

socket.addMembership(config.maddr) is called twice — once around line 518 (before bind) and again in the bind callback
around line 650. The first one will fail since the socket isn't bound yet. The pre-bind call should be removed.

3. Commented-out code in relay.js

// Bind to all interfaces so WSJT-X can reach it from any address
// socket.bind(config.port, '0.0.0.0');
This dead code around line 516-517 should be cleaned up.

4. No multicast address validation

req.query.multicast is shell-sanitized but never validated as an actual multicast address. Should check that the first
octet is 224-239:
const parts = multicastAddress.split('.').map(Number);
if (parts.length !== 4 || parts[0] < 224 || parts[0] > 239) {
return res.status(400).json({ error: 'Invalid multicast address (must be 224.0.0.0–239.255.255.255)' });
}

5. Missing prop default in PSKReporterPanel

The new wsjtxRelayMulticast prop doesn't have a default value. If a layout doesn't pass it,
wsjtxRelayMulticast.enabled will throw. Add a default:
wsjtxRelayMulticast = { enabled: false, address: '224.0.0.1' },

Everything else looks good — the macOS mktemp fix, reuseAddr: true, shell sanitization, and the config/settings
integration are all solid. Just need these fixes before we can merge. 73!

[alanhargreaves]

1. Oops, I thought I caught all of those.
2. There is only one call to socket.addMembership() and that is on line 523. It succeeds as we don't get a caught error. The call on line 660 is to socket.setMulticastLoopback(). "The setMulticastLoopback(flag) method controls whether multicast packets sent by the local application are also received by local sockets on the same machine. This is useful if you have multiple processes or multiple sockets within the same process that need to receive the same multicast data."
3. Done
4. I had meant to do that. Good catch. It would be nice to do it in the settings page, but the way that the input works makes it difficult.
5. I did make sure that everything that currently uses PSKReporterPanel passes it, but your point is well taken

So basically, I've addressed all but item 2, which was not an issue.

[alanhargreaves]

I've just merged the current staging in to this branch (no conflicts).