Topics

pskreporting stops after some period of time


David Miller
 

Hi,

With apologies, it seems more likely that this is not a WSJT-X problem but rather a Windows configuration problem, but I don't know where else to ask.

I'm a new ham (licensed not a month ago) and am just getting into digital modes.  Got my first HF antenna up over the weekend and WSJT-X (2.2.2) installed on Windows 10 x64.  Rx works fine via Omnirig from an IC-7300.  I see FT8 messages decode, all that is fine.  (Haven't tried tx, I'm still fooling around with antennas and haven't yet sufficiently absorbed the WSJT-X manual or FT8 operator guide.)

Reporting to pskreport works, but only for a while.  After an hour or so, pskreport.info indicates that it has stopped receiving data from my station.


Shelling into my router (pfSense) and tcpdumping the relevant interfaces after starting WSJT-X, I see UDP packets being sent to 74.116.41.13:4739 on both public IP and private RFC1918 interfaces every five minutes, and then it mysteriously stops after a while.  

WSJT-X is still decoding happily, my network just isn't seeing any more packets from it.  Restarting WSJT-X fixes the problem and pskreporter once more reports data from my station.

So it's probably not a problem with my border router (eg stale/discarded NAT state).


With ProcMon (which I take to be the Windows equivalent of strace) set to filter on WSJT-X doing UDP Send operations, I can see that WSJT-X is still trying to send UDP packets after I stop seeing them on the network.  So it's (probably) not WSJT-X, either.


I recently installed Kasperski (and added a rule to permit all outbound traffic) but don't know if that's relevant.  But I paused it, killed Malware Bytes and disabled the built-in firewall.  Still nothing.  So it oughtn't be any OS-level or third-party filtering (which I would expect either always to work or never to work).  And yet these packets are still going to /dev/null after an hour.


Any clue what might be happening or what to try next?  Or else, what better venue to ask?

Thanks and 73,
David M7XVK.


Bill Somerville
 

On 18/11/2020 19:32, David Miller wrote:
Hi,

With apologies, it seems more likely that this is not a WSJT-X problem but rather a Windows configuration problem, but I don't know where else to ask.

I'm a new ham (licensed not a month ago) and am just getting into digital modes.  Got my first HF antenna up over the weekend and WSJT-X (2.2.2) installed on Windows 10 x64.  Rx works fine via Omnirig from an IC-7300.  I see FT8 messages decode, all that is fine.  (Haven't tried tx, I'm still fooling around with antennas and haven't yet sufficiently absorbed the WSJT-X manual or FT8 operator guide.)

Reporting to pskreport works, but only for a while.  After an hour or so, pskreport.info indicates that it has stopped receiving data from my station.


Shelling into my router (pfSense) and tcpdumping the relevant interfaces after starting WSJT-X, I see UDP packets being sent to 74.116.41.13:4739 on both public IP and private RFC1918 interfaces every five minutes, and then it mysteriously stops after a while.  

WSJT-X is still decoding happily, my network just isn't seeing any more packets from it.  Restarting WSJT-X fixes the problem and pskreporter once more reports data from my station.

So it's probably not a problem with my border router (eg stale/discarded NAT state).


With ProcMon (which I take to be the Windows equivalent of strace) set to filter on WSJT-X doing UDP Send operations, I can see that WSJT-X is still trying to send UDP packets after I stop seeing them on the network.  So it's (probably) not WSJT-X, either.


I recently installed Kasperski (and added a rule to permit all outbound traffic) but don't know if that's relevant.  But I paused it, killed Malware Bytes and disabled the built-in firewall.  Still nothing.  So it oughtn't be any OS-level or third-party filtering (which I would expect either always to work or never to work).  And yet these packets are still going to /dev/null after an hour.


Any clue what might be happening or what to try next?  Or else, what better venue to ask?

Thanks and 73,
David M7XVK.

Hi David,

try running Wireshark on your WSJT-X PC with a capture filter of "dst port 4739" on your local subnet network interface. That will allow you to determine if datagrams are being sent. If they stop then WSJT-X is the problem.

73
Bill
G4WJS.


David Miller
 

Hi Bill,

On Wed, 18 Nov 2020 at 20:14, Bill Somerville <g4wjs@...> wrote:
try running Wireshark on your WSJT-X PC with a capture filter of "dst port 4739" on your local subnet network interface. That will allow you to determine if datagrams are being sent. If they stop then WSJT-X is the problem.

Wireshark doesn't see them, but ProcMon suggests that WSJT-X is still making kernel calls to send UDP datagrams to report.pskreporter.info.

I wonder if this is not a bit inconclusive.  If Wireshark under Windows is anything like libpcap applications under Linux, it observes packets on the other side of the firewall, so it won't see outbound packets dropped by the firewall.

On the assumption that antivirus and/or OS firewall may be the culprit (eg purging of assumed stale state), I disabled everything (firewall, antivirus etc).  It went hours longer than it would normally have done.  Having re-enabled everything, I now can't reproduce the problem!  Either way, it seems unlikely to be a problem with either WSJT-X or pskreporter but rather either something peculiar to my system.  Kaspersky is a likely culprit, as I installed that recently.

Thanks for the suggestion.

73,
David M7XVK.