www.dl2rum.de

Hello All,

I am having an issue with RUMlogNG correctly detecting multicast UDP packets from WSJT-X. This setup was working properly just a few days ago, and to the best of my knowledge none of the software pieces have been updated in any meaningful way.

With WSJT-X set to broadcast UDP reports on 224.0.0.1 (or any multicast address), default port of 2237, I see "WSJT-X checked in" on the Network Status window, but then about 15 seconds later I see "WSJT-X: connection lost". WSJT-X might "check in" again, but that is always followed by a "lost connection" message. It's as if RUMlogNG is only receiving one UDP packet every now and then.

Other programs that are built to work with WSJT-X's UDP API, such as GridTracker and JT-Bridge, receive multicast UDP packets correctly.

If I change WSJT-X to broadcast on a unicast address, like 127.0.0.1, RUMLogNG does not lose the connection and all QSOs/DX spots are displayed and logged as one would expect. But, I would like to have GridTracker open at the same time, so a multicast address is preferred. So, I think this is an issue either with RUMlogNG or somewhere else on my network. But if it were my network, why do the other programs see the UDP traffic properly?

Is this a known issue, or is there something I can do to fix it?

Thanks!

As far as I know, JT_Bridge works fine with RUMlog. So Grid Tracker may cause the problem. What happens when you quit this app?
You can try to set the broadcast address inn WSJT-X to 192.168.1.255 or the equivalent in your network.

DL2RUM wrote: ↑Thu 31. Dec 2020, 00:54 As far as I know, JT_Bridge works fine with RUMlog. So Grid Tracker may cause the problem. What happens when you quit this app?
You can try to set the broadcast address inn WSJT-X to 192.168.1.255 or the equivalent in your network.

Thanks, Tom! I reset the UDP broadcast port in WSJT-X to 192.168.20.255 (255.255.255.0 netmask on a subnet of 192.168.20.1/24), and reset the corresponding ports in JT-Bridge & RUMlogNG.

JT_Bridge picks up the traffic just fine, but even with GridTracker closed, RUMlogNG still behaves the same way as before. Normal behavior upon starting up WSJT-X is to see an immediate stack of messages in the Network Status window, with the last one being "WSJT-X Checked in", and the "station" in the same window showing "localhost" or something similar, with FT8 as the mode (or whatever WSJT-X is currently set to).

However, the behavior I'm seeing with a multicast address is: No status in the "Network Status" window until about 20 seconds after starting WSJT-X. Then, it might show "WSJT-X checked in", and the "station" is my computer's local IP address (192.168.20.32 in this case), and the "mode" always shows "JT9", no matter what mode I'm actually using.

Does this info offer any clues? Thanks for your quick reply...

However, the behavior I'm seeing with a multicast address is: No status in the "Network Status" window until about 20 seconds after starting WSJT-X. Then, it might show "WSJT-X checked in", and the "station" is my computer's local IP address (192.168.20.32 in this case), and the "mode" always shows "JT9", no matter what mode I'm actually using.

This sounds normal to me. WSJT-X sends every 15 - 20 seconds a status message (Here I am), this message initiates the Checked in message. RUMlog doesn't show always the WSJT-X mode, the mode will be saved with a logging a QSO. But this depends on your CAT configuration.

A screen shot would be helpful.

DL2RUM wrote: ↑Thu 31. Dec 2020, 10:13
This sounds normal to me. WSJT-X sends every 15 - 20 seconds a status message (Here I am), this message initiates the Checked in message. RUMlog doesn't show always the WSJT-X mode, the mode will be saved with a logging a QSO. But this depends on your CAT configuration.

A screen shot would be helpful.

Thanks Tom, I've attached a couple of screenshots here. The first shows unicast behavior of the Network Status window a few seconds after starting WSJT-X. In the screenshot there is also a wireshark instance running, showing that WSJT-X is indeed broadcasting UDP packets on that address. After WSJT-X decodes its first set of messages, the DXSpotter Window pops up and populates the callsigns appropriately.



The second screenshot shows the exact same scenario, except WSJT-X is broadcasting on 224.0.0.1, and RUMlogNG is listening on the same port. RUMlogNG does not detect the "I am here" initial status from WSJT-X, and it never detects when a set of messages has been decoded and broadcast. Again, the wireshark instance shows the exact same packets being sent to the multicast address as to the unicast address. About 20 seconds after the "checked in" message, the status window reports a "connection lost" message, even though packets are still being broadcast. And, this is without JT_bridge or Gridtracker running (or any other UDP programs for that matter).



I did test this while disconnected from my LAN (no DHCP address present on any interface), and I didn't see any change in behavior.

FWIW, I am using CAT to control my KX2, and that always works flawlessly.

Any ideas? Thanks and happy new year!

except WSJT-X is broadcasting on 224.0.0.1, and RUMlogNG is listening on the same port.

What happens when you keep the multicast address field empty in RUMlog? This may not work as expected.

DL2RUM wrote: ↑Thu 31. Dec 2020, 15:31
What happens when you keep the multicast address field empty in RUMlog? This may not work as expected.

If I leave the multicast field empty, there is no change in behavior for either scenario. Both JT-Bridge and GridTracker are picking up the UDP traffic from WSJT-X on the multicast address, though.

I set up WSJT, RUMlog and GridTracker to listen to 224.0.0.1. Sitting here on the couch, I have no radio connected. When entering a callsign and a grid, these information become visible asap in both apps. It seems it works as expected.
You said, it worked before on your side?

DL2RUM wrote: ↑Thu 31. Dec 2020, 16:43 I set up WSJT, RUMlog and GridTracker to listen to 224.0.0.1. Sitting here on the couch, I have no radio connected. When entering a callsign and a grid, these information become visible asap in both apps. It seems it works as expected.
You said, it worked before on your side?

Yes! That is good to hear. It must be on my side. I'll start with a re-install and see if that works. I am, in fact, glad it's just me!

Reinstalling is not the best idea on a Mac. Do you use Little Snitch?