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
Multicast addresses in the 18.104.22.168/16 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 22.214.171.124/16 multicast address. Try it.
From my JTAlert Help->About ...
FWIW, the original choice of the 126.96.36.199/16 subnet for the
JTAlert multicast support was based on your recommendations in this
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 188.8.131.52/16 addresses which is site local, it is a bit
like 192.168.0.0/16 or 10.0.0.0/24 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 184.108.40.206 to
my user base.
I followed your lead in recommending 220.127.116.11 as the Multicast
address to use for WSJT-X inter-operating with JTAlert.
What do you recommend now as a suitable address within the
Since the "goal posts" have changed with 18.104.22.168/16 now being
recommended, I'll update the JTAlert documentation to use an address
in the now recommended range.
de Laurie VK3AMA