Hi Thomas,
I suspect you will not have to make any changes as the devices WSJT-X
Monitor is running on will be on the users subnet. WSJT-X instances in
this case will need to be configured to send multicast datagrams on the
subnet interface which is equivalent to the current way WSJT-X 2.2.2 and
earlier versions worked.
I will send you a copy of the pre-release installer to your gmail address.
73
Bill
G4WJS.
On 08/11/2020 23:05, Thomas Reynolds wrote:
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
<mailto: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 <http://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
<http://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
