locked Re: WSJT-X rc2

HamApps Support (VK3AMA)

On 16/11/2020 7:51 am, g4wjs wrote:

you appear to be one of the users using an inappropriate multicast address that has caused this change to be made. Until a version of JTAlert is available that will receive multicast traffic on the loop-back network interface, you can restore functionality by choosing your local subnet network interface in WSJT-X "Settings->Reporting->UDP Server->Outgoing interface".

Multicast addresses in the block are potentially globally routed, that is not a good choice for getting traffic to a server on the same host or your local subnet.



JTAlert will work with a multicast address. Try it.

From my JTAlert Help->About ...

FWIW, the original choice of the subnet for the JTAlert multicast support was based on your recommendations in this posting
Hi Tag and Ed,

modern multicast routing does not rely on TTL values to restrict routing span, best to use an administratively scopes address. I use addresses which is site local, it is a bit like or addresses. better still use IPv6 multicast group addresses like ffx5::/16 which are all site local multicast addresses, e.g. ff05::, ff05::1, ..., ff05::ff:ff, ff15::, ff15::ff:ff, ...

To which Tag responded in this posting
I have started recommending to my user base.

I followed your lead in recommending as the Multicast address to use for WSJT-X inter-operating with JTAlert.

What do you recommend now as a suitable address within the subnet?

Since the "goal posts" have changed with now being recommended, I'll update the JTAlert documentation to use an address in the now recommended range.

de Laurie VK3AMA

Join Support@HamApps.groups.io to automatically receive all group messages.