Date   

locked Re: Erroneous error message !

Michael Black
 

I take it you just want Log4OM logging, right?

Turn off the "Last QSO API".  You don't need it.

It sounds like you don't have the Log4OM SQLite Log pointing to the correct file.  Should be the same path you see in the lower right corner of Log4OM.
Mike W9MDB

Inline image







On Tuesday, November 17, 2020, 02:41:09 AM CST, Paul F6EXV <f6exv@...> wrote:


Hi all
No reply to this... Anyone with any idea ?
73
Paul F6EXV

Le 15/11/2020 à 23:13, Paul F6EXV a écrit :
> Hi all
> Strange behaviour...
> Using Log4OM latest version, JTDX v2.2.0-rc152 and JTAlert 2.16.15 on
> Windows 10.
> I am getting the attached error message when logging a QSO onto Log4OM.
> But the QSO is indeed logged...
>
> I have :
> Enable transmission of last QSO ticked, on port 2333 in the "Last QSO
> API" setup
> Enable Standard ADIF file logging unticked in the Standard ADIF file
> setup
> Enable Log4OM V2 logging tocked, UDP connections on IP 127.0.0.1 on
> ADIF message port #2236
> When I ask JTAlert to show Log Fields, the screen expands, but remains
> grey.
> The headline says "JTAlert 2.16.15 F6EXV {80m,FT8,LogV2,#1}
>
> If I untick "Enable Log4OM Logging", then I do not have access to
> "View log fields", and the expanded grey screen disappears, and the
> header will now show "NO LOG".
>  And the QSO IS logged onto Log4OM, without any success message....
>
> 1/ How can I get access to the log fields below the display lines ?
> 2/ The "NO LOG" indication makes reference to which log ?
> 3/ How do I get a logging success message ?
>
> Thanks + 73
> Paul F6EXV
>


--
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel antivirus Avast.






locked Re: LoTW User updates

David De Coons
 

The callsign database in JTAlert can be downloaded from www.hamapps.com

Dave wo2x


On Nov 17, 2020, at 6:38 AM, David Gould <dave@...> wrote:

I have just updated the LoTW User file in WSJT-X.

The Help file says the file come from ARRL, but does not say how it gets into JTAlert.  Do I have to do anything to get/apply the latest version?

73,  Dave   G3UEG


locked Multiple Instances JT Alert

SV8JNL SV8JNL
 

Hello i would like to know if there is a way to have 2 jtdx apps with 2 jt alert at the same pc same time.
I can have 2 jtdx but  i cant have 2 jt alert to run for each jtdx...Any help?
Thank you.


locked LoTW User updates

David Gould
 

I have just updated the LoTW User file in WSJT-X.

The Help file says the file come from ARRL, but does not say how it gets into JTAlert.  Do I have to do anything to get/apply the latest version?

73,  Dave   G3UEG


locked Re: WSJT-X rc2

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.


locked Re: New install of JTAlert keeps crashing saying "invalid callsign"

steve@...
 

Hi,

Thanks for your reply.  Strangely enough, on the third install attempt it came up with the "enter callsign" dialog box.  So, everything seems to be working!  I have no idea why it was acting strange, especially since this is a fresh and totally updated windows install.  I apologize for letting my frustration show.

73,
Steve


locked Re: Callsigns get cleared before I can see them

John KC4LZN
 

Laurie,

You were absolutely correct. Was not aware that I was that far out in updates and made the update to the current version of 2.16.15 and the call signs remain and did not clear.

John, give it an update and hopefully you'll see the same results.

73
John
KC4LZN


On Tue, Nov 17, 2020, 01:21 ray cathode via groups.io <ray_cathode1=yahoo.com@groups.io> wrote:
Laurie,


Actually they don't get cleared before I can see them (guess I misunderstood the subject)

What I was referring to was the fact that if you complete a qso and log it the callsigns go away faster than normal (about twice as fast)
I suppose it's something with the programing.


I like to log a callsign and click on another one before the callsigns go away..
Guess you could call it speed calling/clicking??


Dell Precision T5500
Intel Xeon CPU X5650 2.67 gig (6 core)
24 gig ram
Win7 Pro 64 bit


73,

W9RF - Joe






On Monday, November 16, 2020, 11:58:31 PM CST, HamApps Support (VK3AMA) <vk3ama.ham.apps@...> wrote:


On 17/11/2020 1:08 pm, ray cathode via groups.io wrote:
BTW my computer is not slow either.


That means nothing. It may not be slow in your eyes, but without quoted CPU core count, speed and Memory installed, it is impossible to offer any informed commentry as to what is causing your issue.

What is your CPU load when WSJT-X is decoding?
Is WSJT-X still producing decodes into the next time period?

de Laurie VK3AMA


locked Re: unsuccessful contacts with 7q7ru

Tom Melvin
 

Does any of this have anything to do with JTAlert?  

Since it seems to be 100% related to wsjt-x would it not be better moving this over to the WSJTX mailing list.

Tom
GM8MJV

On 17 Nov 2020, at 02:58, ray cathode via groups.io <ray_cathode1@...> wrote:

Joe,



I'll do that but I pretty much know what I will find..



73,

W9RF - Joe





On Monday, November 16, 2020, 8:38:50 PM CST, Joe Subich, W4TV <lists@...> wrote:



> Has the F/H protocol changed since WSJT-X 2.0?

This would be a question for K1JT on the WSJTX list - not here
as it is not a function of JTAlert.

Why don't you check the change log/Release Notes:
  <https://physics.princeton.edu/pulsar/k1jt/Release_Notes.txt>

73,

    ... Joe, W4TV


On 2020-11-16 8:01 PM, ray cathode via groups.io wrote:
>  Here is my latest test with
> JTalert ver 2.16.15WSJT ver 2.2.2F/H mode30 meters
>
> 235315 Tx 1114 ~ 7Q7RU W9RF EM57
> 235330 -14 -0.3 349 ~ W9RF 7Q7RU -04
>
> 235345 Tx 349 ~ 7Q7RU W9RF R-14
>
> 235415 Tx 649 ~ 7Q7RU W9RF R-14
>
> 235445 Tx 649 ~ 7Q7RU W9RF R-14
>
> 235500 -14 -0.3 349 ~ EA2KB 7Q7RU -09
>
> 235515 Tx 649 ~ 7Q7RU W9RF R-14
>
> 235545 Tx 649 ~ 7Q7RU W9RF R-14
>
> 235600 -14 -0.3 349 ~ W9RF 7Q7RU -04
>
> 235615 Tx 349 ~ 7Q7RU W9RF R-14
>
> 235630 -9 -0.3 289 ~ W9RF 7Q7RU -04
>
> 235645 Tx 289 ~ 7Q7RU W9RF R-09
>
> 235700 -11 -0.3 289 ~ W9RF 7Q7RU -04
>
> 235715 Tx 289 ~ 7Q7RU W9RF R-11
>
> 235730 -9 -0.3 289 ~ CQ 7Q7RU KH67
>
> 235745 Tx 589 ~ 7Q7RU W9RF R-11
>
>
> sent into never never land
> 2nd try
> JTalert ver 2.16.15WSJT ver 2.2.2F/H mode TURNED OFF
> 30 meters
>
>
> 005830 -4 0.0 289 ~ CQ 7Q7RU KH67
> 005845 Tx 1325 ~ 7Q7RU W9RF EM57
>
> 005900 -6 -0.1 289 ~ W9RF 7Q7RU -01
>
> 005915 Tx 1325 ~ 7Q7RU W9RF R-06
>
> 005930 -6 -0.1 289 ~ W9RF 7Q7RU RR73
>
> 005945 Tx 1325 ~ 7Q7RU W9RF 73
>
> 010000 -8 -0.2 289 ~ CQ 7Q7RU KH67
>
>
>
>
>
>      On Monday, November 16, 2020, 5:09:11 PM CST, ray cathode via groups.io <ray_cathode1=yahoo.com@groups.io> wrote:

>    Laurie,
>
> Has the F/H protocol changed since WSJT-X 2.0?
>
> 73,
> W9RF - Joe
>

>
>      On Monday, November 16, 2020, 5:04:14 PM CST, Jim Cooper <jtalert@...> wrote:

>  Their website says they are using WSJT-X v2.0 which is very old and might explain some of the oddities of operation ...
>
> One would think that, embarking on such a long-distance and expensive DXpedition, they would be sure to have the most up to date version of all their software ...  but apparently not.   Apparently Malawi is the safest place in the world to be this week, so we do owe a lot of thanks for them to follow thru on the DXpedition.
> jim  w2jc
> On 16 Nov 2020 at 17:24, Joe Subich, W4TV wrote:
>> Are you sure 7q7ru is using WSJTX> and not a [garbage] clone like MSHV or> JTDX? > > Some of the clones do not implement> the F/H protocol correctly but do> allow for multiple simultaneous> QSOs.  It may be that 7q7ru is using> one of the incompatible software> packages and using the *NON F/H* mode> in WSJTX is the correct way to> operate!
>   
>
>
>
>
>
>







locked Re: New install of JTAlert keeps crashing saying "invalid callsign"

HamApps Support (VK3AMA)
 

On 17/11/2020 7:23 pm, steve via groups.io wrote:
I have installed JTAlert countless times.  After about 60 seconds, it says "cannot continue with no callsign."  Then when I go to the change callsign start menu option, it won't accept my callsign and says Contact Support.  So I am, please excuse me but this is irritating.

Does the error message say "Invalid Callsign" or "Missing or Invalid Callsign"? I suspect the latter.
If that is the case either the Callsign is missing from the Registry or JTAlert is being prevented by your protection software from reading the Registry entry.

See this post on suggested fixes. https://hamapps.groups.io/g/Support/message/26600

de Laurie VK3AMA





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

Koike Toshiya
 

TNX Laurie,

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

JL1JVT Toshiya


locked New install of JTAlert keeps crashing saying "invalid callsign"

steve@...
 

Hi,
I have installed JTAlert countless times.  After about 60 seconds, it says "cannot continue with no callsign."  Then when I go to the change callsign start menu option, it won't accept my callsign and says Contact Support.  So I am, please excuse me but this is irritating.


locked Re: Erroneous error message !

Paul F6EXV
 

Hi all
No reply to this... Anyone with any idea ?
73
Paul F6EXV

Le 15/11/2020 à 23:13, Paul F6EXV a écrit :
Hi all
Strange behaviour...
Using Log4OM latest version, JTDX v2.2.0-rc152 and JTAlert 2.16.15 on Windows 10.
I am getting the attached error message when logging a QSO onto Log4OM.
But the QSO is indeed logged...

I have :
Enable transmission of last QSO ticked, on port 2333 in the "Last QSO API" setup
Enable Standard ADIF file logging unticked in the Standard ADIF file setup
Enable Log4OM V2 logging tocked, UDP connections on IP 127.0.0.1 on ADIF message port #2236
When I ask JTAlert to show Log Fields, the screen expands, but remains grey.
The headline says "JTAlert 2.16.15 F6EXV {80m,FT8,LogV2,#1}

If I untick "Enable Log4OM Logging", then I do not have access to "View log fields", and the expanded grey screen disappears, and the header will now show "NO LOG".
 And the QSO IS logged onto Log4OM, without any success message....

1/ How can I get access to the log fields below the display lines ?
2/ The "NO LOG" indication makes reference to which log ?
3/ How do I get a logging success message ?

Thanks + 73
Paul F6EXV
--
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel antivirus Avast.
https://www.avast.com/antivirus


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

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?

See https://hamapps.groups.io/g/Support/message/32275

de Laurie VK3AMA


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

Koike Toshiya
 

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


locked Re: Callsigns get cleared before I can see them

Joe - W9RF
 

Laurie,


Actually they don't get cleared before I can see them (guess I misunderstood the subject)

What I was referring to was the fact that if you complete a qso and log it the callsigns go away faster than normal (about twice as fast)
I suppose it's something with the programing.


I like to log a callsign and click on another one before the callsigns go away..
Guess you could call it speed calling/clicking??


Dell Precision T5500
Intel Xeon CPU X5650 2.67 gig (6 core)
24 gig ram
Win7 Pro 64 bit


73,

W9RF - Joe






On Monday, November 16, 2020, 11:58:31 PM CST, HamApps Support (VK3AMA) <vk3ama.ham.apps@...> wrote:


On 17/11/2020 1:08 pm, ray cathode via groups.io wrote:
BTW my computer is not slow either.


That means nothing. It may not be slow in your eyes, but without quoted CPU core count, speed and Memory installed, it is impossible to offer any informed commentry as to what is causing your issue.

What is your CPU load when WSJT-X is decoding?
Is WSJT-X still producing decodes into the next time period?

de Laurie VK3AMA


locked Re: Callsigns get cleared before I can see them

HamApps Support (VK3AMA)
 

On 17/11/2020 1:05 pm, John Peck wrote:
Laurie, thanks for your prompt response, and here is more information. I haven't been on the air since May. Winter is here and I aim to pick up the hobby once again. I figured all my software was out of date so I downloaded and installed WSJT-X v2.2.2 and JTAlert 2.16.4. I think they are the current versions. I am sure whatever is happening is my fault, probably something got screwed up with the re-installs. What I believe is happening is that JTAlert displays the very first stations decoded, but clears those fields when the next batch of signals is decoded, then clears the display again when the final batch shows up. This three level decoding is new to me, so I'm sure I am misinterpreting something. I just don't see what benefit there is to the "early" decoding if it flashes on and off the screen too fast for me to read it, let alone click on it. Sorry to be a bother. I spent several hours today trying to figure this out and I am stumped. John
_._

Your description of the callsign clearing is the reason I asked about Versions.

Your JTAlert 2.16.4 version is the culprit.

A new build of JTAlert had to be released that took into account the new early and 3-pass decoding of WSJT-X 2.2.0. That was JTAlert version 2.16.5

From the 2.16.5 release notes...
  Changes:

    - WSJT-X 2.2.0 FT8: Callsign clearing time adjustments for early decodes.

Upgrade your JTAlert version and the premature clearing of decoded callsigns will be resolved.

de Laurie VK3AMA


locked Re: Callsigns get cleared before I can see them

HamApps Support (VK3AMA)
 

On 17/11/2020 1:08 pm, ray cathode via groups.io wrote:
BTW my computer is not slow either.


That means nothing. It may not be slow in your eyes, but without quoted CPU core count, speed and Memory installed, it is impossible to offer any informed commentry as to what is causing your issue.

What is your CPU load when WSJT-X is decoding?
Is WSJT-X still producing decodes into the next time period?

de Laurie VK3AMA


locked Re: Callsigns get cleared before I can see them

HamApps Support (VK3AMA)
 

On 17/11/2020 1:01 pm, John KC4LZN wrote:

I'm running 2.16.1 and WSJT-X (Ver 2.2.2) goes through what appears a second sweep checking for missing signals and when it finds them, it posts them and JTAlert seems to clears the first sweep and posts the results of the second sweep.

Make sense?

73
John
KC4LZN

That's to be expected because you updated WSJT-X to the new early (@ 12 secs) and multi-pass decoding version but didn't bother to update your JTAlert version.
A new build of JTAlert had to be released that took into account the new early decoding of WSJT-X 2.2.0. That was JTAlert version 2.16.5

From the 2.16.5 release notes...
  Changes:

    - WSJT-X 2.2.0 FT8: Callsign clearing time adjustments for early decodes.

Upgrade your JTAlert version and the premature clearing of decoded callsigns will be resolved.

de Laurie VK3AMA



locked Re: JTAlert did stop reporting QSO upload to HRD #HRD

HamApps Support (VK3AMA)
 

On 17/11/2020 3:38 am, asobel@... wrote:
My JTAlert v2.16.15 did stop the display of the QSO upload report to HRD. This did happen after a change to the HRD logbook database machine.

How do I get it back. It is very useful.

Two possible places in the Settings. I don't know which you may have altered.





de Laurie VK3AMA


locked Re: WSJT-X rc2

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




4301 - 4320 of 36454