locked After updating WSJT-X to 2.3.0-rc2, it is not reflected in JTAlert

Toshiya Koike

JTAlert does not display anything like the attached image.
Is there a solution?
Maybe this has something to do with it?

From: Bill Somerville <g4wjs@cl...> - 2020-11-07 19:50:30

Hi all,
the next release of WSJT-X (v.2.3.0 RC2) will change the way UDP datagrams are sent by WSJT-X when being sent to a multicast group address.
Until now multicast datagram have been sent on the operating system preferred network interface, which in most cases will be the network with the default route, i.e. the local subnet. The new version will send to the loop-back interface by default. This change is intended to limit the scope of multicast traffic to no further than necessary, and the vast majority of users will be running WSJT-X instances and other interoperating application servers like JTAlert and Gridtracker on the same host. For this the loop-back interface is available to all applications and datagrams need not be sent any further afield.
I foresee that applications that join a multicast group to receive WSJT-X UDP datagrams will need to be changed to join the selected multicast group on the loop-back interface. For backwards compatibility it would seem wise to also optionally join the group on the local subnet network interface, as they do now, in addition to joining on the loop-back interface. This will both allow interoperation with older versions of WSJT-X (pre-v2.3.0 RC2), and with WSJT-X instances configured to send datagrams on a different network interface than the loop-back interface; so applications running on other hosts in the network can interoperate. The latter allowing more complex configurations to be set up when necessary.
This change has been prompted by some users apparently selecting inappropriate multicast group addresses that in some circumstances may be more widely routed than expected. Good choices of multicast group addresses are in the subnet (although these are officially reserved for local network control these have the handy attribute that they are never globally routed), in the range, or IPv6 multicast addresses in the ffx1::/16, ffx2::/16, and ffx3::/16 ranges. 
Other multicast addresses may be routed further afield if remote servers join the chosen group address, although as I understand it ISPs in general do not route *any* multicast datagrams *from* their subscribers. 
Some ISP utilize a "flat" internetworking structure where many subscribers (possibly thousands) are placed on the same subnet, I believe  this more common amongst cable based ISPs. In those cases multicast datagrams may travel across the extended subnet if not blocked by subscriber firewalls.
Note that applications that are only able support unicast UDP are not affected by this change.
I have sent pre-release versions of WSJT-X with this enhancement to the authors of JTAlert and Gridtracker, if any other software authors require a copy then let me know please.

HamApps Support (VK3AMA)

On 17/11/2020 6:38 pm, Toshiya Koike wrote:
JTAlert does not display anything like the attached image.
Is there a solution?


de Laurie VK3AMA

Toshiya Koike

TNX Laurie,

I will investigate with reference to this.
Thank you as always.

JL1JVT Toshiya

Toshiya Koike

JTAlert (and GridTracker) worked fine.
The setting is like this.
(WSJT-X 2.3.0-rc2 Settings Reporting Tab)

(JTAlert 2.16.16 Settings)
Resend UDP Port 2334

(Grid Tracker 1.20.0927 Settings)
Received UDP Port 2334
Multicast is OFF.

JL1JVT Toshiya