Bill, I would also like a pre-release version of WSJT-X v.2.3.0 RC2 (Win10 or Ubuntu)
I am the author of an Android app, WSJT-X Monitor (by Feotec), which uses the UDP interface. Multicast is not supported in the Android kernel but many manufacturers build it in so we offer a special version for users who are able to utilize it. Thank you, Thomas Reynolds On Sat, Nov 7, 2020 at 11:54 AM Bill Somerville <g4...@classdesign.com> wrote: > 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 224.0.0.0/24 subnet (although these are officially > reserved for local network control these have the handy attribute that > they are never globally routed), in the 239.255.0.0/16 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. > > 73 > Bill > G4WJS. > > > > _______________________________________________ > wsjt-devel mailing list > wsjt-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wsjt-devel >
_______________________________________________ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel