Topics

locked WSJT-X rc2


Thomas Mills
 

Just loaded wsjtx rc2 and got a message that the network port was not working.  found this on the wsjtx release notes, so I guess 239.0.0.1 want work anymore?


 Due to  some users using  inappropriate multicast IP  addresses for
   their interoperating  servers the default behaviour now is  to only
   send multicast  UDP datagrams  to the loop-back  network interface.
   Users who  require WSJT-X UDP  Message Protocol datagrams  to reach
   other  hosts will  now  have  to configure  WSJT-X  to  send on  an
   appropriate  network interface,  and  use  an appropriately  scoped
   multicast group address for their  server applications.  If you are
   not sure then  224.0.0.1 (or ff02::1 if IPv6 is  desired) is a safe
   choice.
Thanks Tom WB4JWM


g4wjs
 

On 15/11/2020 20:25, Thomas Mills wrote:
Just loaded wsjtx rc2 and got a message that the network port was not working.  found this on the wsjtx release notes, so I guess 239.0.0.1 want work anymore?


 Due to  some users using  inappropriate multicast IP  addresses for
   their interoperating  servers the default behaviour now is  to only
   send multicast  UDP datagrams  to the loop-back  network interface.
   Users who  require WSJT-X UDP  Message Protocol datagrams  to reach
   other  hosts will  now  have  to configure  WSJT-X  to  send on  an
   appropriate  network interface,  and  use  an appropriately  scoped
   multicast group address for their  server applications.  If you are
   not sure then  224.0.0.1 (or ff02::1 if IPv6 is  desired) is a safe
   choice.
Thanks Tom WB4JWM
_._,_._,_

Hi Tom,

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.


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



g4wjs
 

On 15/11/2020 21:14, HamApps Support (VK3AMA) wrote:
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...

Laurie,

the OP claimed to be using 239.0.0.1, that is most definitely *not* in the 239.255.0.0/16 block of multicast addresses!


--
73
Bill
G4WJS.


g4wjs
 

On 15/11/2020 21:14, HamApps Support (VK3AMA) wrote:
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 ...
   

Laurie,

as I explained off list, 224.0.0.1 is a special multicast address known as the "All Hosts" address. The 224.0.0.0/8 block of addresses is also special as they are never routed. 224.0.0.1 specifically (not just any 224.0.0.0/8 address) will work with the current JTAlert because every host joins that multicast group, on every network interface, automatically without the recipient application requesting membership. 224.0.0.1, the "All Hosts" multicast address, is just one member of the 224.0.0.0/24 block of 255 multicast addresses.

I think there may be some fundamental misunderstanding here about IPv4 address notation. IPv4 addresses are 32-bit numbers which are often written as a group of 4 decimal octets (representing 8-bits each), known as dotted decimal notation. IPv4 addresses are also written as groups, or subnets, where a specified number of high order bits, the prefix, are fixed and the remaining lower order bits form he membership of the subnet group. Some common subnets are:

127.0.0.0/8 - the loop-back addresses (they all start with 127., yes >16 million of them!), of which 127.0.0.1 is the most commonly used and supported.

192.168.0.0/16 - the class C private address block, they all start with 192.168. and are not normally routed.

172.16.0.0/12 - the class B private address block, they are 172.16.0.0 thru 172.31.255.255, also not normally routed.

10.0.0.0/8 - the class A private address block, they all start with 10., also not normally routed.

224.0.0.0/4 - the multicast group addresses, they are 224.0.0.0 thru 239.255.255.255.

Multicast group addresses are further subdivided, including 224.0.0.0/8 (not routed), and 239.0.0.0/24 (routing scope determined by further subdivisions and router settings, a.k.a. administratively scoped).


--
73
Bill
G4WJS.


HamApps Support (VK3AMA)
 

On 16/11/2020 8:53 am, g4wjs wrote:
On 15/11/2020 21:14, HamApps Support (VK3AMA) wrote:
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 ...
   

Laurie,

as I explained off list, 224.0.0.1 is a special multicast address known as the "All Hosts" address. The 224.0.0.0/8 block of addresses is also special as they are never routed. 224.0.0.1 specifically (not just any 224.0.0.0/8 address) will work with the current JTAlert because every host joins that multicast group, on every network interface, automatically without the recipient application requesting membership. 224.0.0.1, the "All Hosts" multicast address, is just one member of the 224.0.0.0/24 block of 255 multicast addresses.

I think there may be some fundamental misunderstanding here about IPv4 address notation. IPv4 addresses are 32-bit numbers which are often written as a group of 4 decimal octets (representing 8-bits each), known as dotted decimal notation. IPv4 addresses are also written as groups, or subnets, where a specified number of high order bits, the prefix, are fixed and the remaining lower order bits form he membership of the subnet group. Some common subnets are:

127.0.0.0/8 - the loop-back addresses (they all start with 127., yes >16 million of them!), of which 127.0.0.1 is the most commonly used and supported.

192.168.0.0/16 - the class C private address block, they all start with 192.168. and are not normally routed.

172.16.0.0/12 - the class B private address block, they are 172.16.0.0 thru 172.31.255.255, also not normally routed.

10.0.0.0/8 - the class A private address block, they all start with 10., also not normally routed.

224.0.0.0/4 - the multicast group addresses, they are 224.0.0.0 thru 239.255.255.255.

Multicast group addresses are further subdivided, including 224.0.0.0/8 (not routed), and 239.0.0.0/24 (routing scope determined by further subdivisions and router settings, a.k.a. administratively scoped).


--
73
Bill
G4WJS.
_._,_._,_



Let's make this simple.

What Address do you recommend that will meet your requirements?

Is 239.255.0.0 that I have been recommending OK or not? If not, give me a number.

de Laurie VK3AMA





g4wjs
 

On 17/11/2020 05:41, HamApps Support (VK3AMA) wrote:
On 16/11/2020 8:53 am, g4wjs wrote:
On 15/11/2020 21:14, HamApps Support (VK3AMA) wrote:
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 ...
   

Laurie,

as I explained off list, 224.0.0.1 is a special multicast address known as the "All Hosts" address. The 224.0.0.0/8 block of addresses is also special as they are never routed. 224.0.0.1 specifically (not just any 224.0.0.0/8 address) will work with the current JTAlert because every host joins that multicast group, on every network interface, automatically without the recipient application requesting membership. 224.0.0.1, the "All Hosts" multicast address, is just one member of the 224.0.0.0/24 block of 255 multicast addresses.

I think there may be some fundamental misunderstanding here about IPv4 address notation. IPv4 addresses are 32-bit numbers which are often written as a group of 4 decimal octets (representing 8-bits each), known as dotted decimal notation. IPv4 addresses are also written as groups, or subnets, where a specified number of high order bits, the prefix, are fixed and the remaining lower order bits form he membership of the subnet group. Some common subnets are:

127.0.0.0/8 - the loop-back addresses (they all start with 127., yes >16 million of them!), of which 127.0.0.1 is the most commonly used and supported.

192.168.0.0/16 - the class C private address block, they all start with 192.168. and are not normally routed.

172.16.0.0/12 - the class B private address block, they are 172.16.0.0 thru 172.31.255.255, also not normally routed.

10.0.0.0/8 - the class A private address block, they all start with 10., also not normally routed.

224.0.0.0/4 - the multicast group addresses, they are 224.0.0.0 thru 239.255.255.255.

Multicast group addresses are further subdivided, including 224.0.0.0/8 (not routed), and 239.0.0.0/24 (routing scope determined by further subdivisions and router settings, a.k.a. administratively scoped).


--
73
Bill
G4WJS.
_._,_._,_



Let's make this simple.

What Address do you recommend that will meet your requirements?

Is 239.255.0.0 that I have been recommending OK or not? If not, give me a number.

de Laurie VK3AMA

Hi Laurie,

Users pick the address, they can use any appropriate one. What is appropriate may depend on their requirements, i.e. do other applications need to access WSJT-X multicast traffic on a different host? I cannot give a definitive answer to your question, nor should you be asking for such an answer. Up until now some users have been selecting multicast group addresses that are inappropriate because the traffic may get routed outside of their local subnet when they don't intend that. Further having servers like JTAlert joining inappropriate multicast group addresses can lead to traffic from outside of the local scope being routed into the local subnet. To address these issues WSJT-X has been changed to only send multicast traffic on the loop-back interface by default. That way a user would have to change settings if they wanted some wider scope. All JTAlert has to do is join the selected multicast group on the loopback interface by default and the problem is solved. Note also that the longer this is not available, then the more users that will revert back to sending multicast traffic from WSJT-X to potentially a wider scope than is intended.

Let me summarize:

  • Some users have selected inappropriate multicast group addresses that allow traffic to be routed further than they intend.
  • Servers configured to interoperate as above can cause multicast traffic to be routed in from further afield than intended.
  • WSJT-X has been changed to stop the above happening by only sending multicast on the loopback interface by default.
  • Server authors like yourself must change their applications to join any specified multicast address on the loopback interface by default otherwise the problem is not solved. I did give warning of this change along with a test version of WSJT-X, you returned a test version of JTAlert that seemed to comply with the above but was unable to work with older versions of WSJT-X using multicast. I had assumed you were fixing that, and you stated something along those lines.

If server authors are not going to make multicast reception on the loopback interface their default then our only choice is to disable the ability for WSJT-X to send on interfaces other than the loopback one. This will be a problem for any users who wish to interoperate with applications on a different host than WSJT-X runs on, it will also be a problem for backwards compatibility for any user wishing to interoperate with servers that have not bee upgraded, but there is little other choice if that does not happen.

Here is a strategy that should be adopted by server authors:

  1. By default join any specified multicast group address only on the loopback interface.
  2. Offer a setting to join on one or more other interfaces, either in addition to the loopback interface or instead of the loopback interface.

That's it, with that the problem is behind us unless a user overrides the defaults without understanding the consequences, in that case they are on their own and we can assume they know what they are doing.

I note you do add a further complexity due to the "zero config" nature of JTAlert which reads the internal WSJT-X settings file and guesses the IP address it is expected to serve on. This complicates matters for you  but it is not insurmountable. You proposed that JTAlert could choose to join a multicast group address on the loopback interface if the WSJT-X settings appeared to specify it was going to send on the loopback interface. This strategy works for you because JTAlert currently can only operate if it is running on the same host as any WSJT-X instance it is going to interoperate with. You would have to also detect if WSJT-X instances do not intend to send multicast traffic on the loopback interface (this includes older versions), in that case you have to work out which interface to join on such that traffic will get to JTAlert. Again because JTAlert only works when run on the same host as any WSJT-X instance it wishes to interoperate with, you can choose to join on the named interface you see in the WSJT-X settings file since that will be an interface you have access to. Another strategy for JTAlert backwards compatibility might be:

  • If the WSJT-X instances you wish to interoperate with appear to not be configured to send multicast traffic on the loopback interface, either explicitly or because they are older versions than v2.3.0 RC2. Then do what you have done before now. Otherwise join the detected multicast group address on the loopback interface.

73
Bill
G4WJS.


--
73
Bill
G4WJS.