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 239.0.0.0/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.


--
73
Bill
G4WJS.

Bill,

JTAlert will work with a 224.0.0.0/16 multicast address. Try it.

From my JTAlert Help->About ...
   

FWIW, the original choice of the 239.255.0.0/16 subnet for the JTAlert multicast support was based on your recommendations in this posting
Quote...
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 239.255.0.0/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
Quote...
I have started recommending 239.255.0.1 to my user base.


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

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

Since the "goal posts" have changed with 224.0.0.0/16 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.