[pskmail] THOR mode and Fldigi 3.10 server issues

  • From: John Douyere <vk2eta@xxxxxxxxx>
  • To: pskmail@xxxxxxxxxxxxx
  • Date: Wed, 25 Mar 2009 16:02:06 +1100

Per, Rein,

Here is the result of a few hours of investigation.

Problem:

When using the THOR22 mode with the Pskmail server (Version 0.7.20), the
server would stop responding, most often at the early stages of a connect
phase. It would sometimes return to responding several hours later. This
problem is not apparent in PSK modes.

Discovered issues:

1. There was an issue with the handling of the second <EOT> generated by the
THOR mode at the end of the Pskmail blocks. This issue would show as the
server not sending any reply until restarted. The evidence would be in the
server log as an absence of any further reaction to the client's requests
(connects or others).

This was resolved by the following code change in ARQ.PM in the forked child
process which does the communication with Fldigi:

                        } elsif (ord ($rcvd) == 4) {
                            $Queue_input .= "<EOT>\n";
                            $squelch = 0;
                            if (-e "$ENV{HOME}/.pskmail/squelch.lk") {
                                unlink "$ENV{HOME}/.pskmail/squelch.lk";
                            }

                                while (-e "$ENV{HOME}/.pskmail/.input") {
                                    select undef, undef, undef, 0.01;
                                }
#JD 20-Mar-2009 - clean extra <EOT> from some mode like THOR and DominoEx by
removing blocks not stating with <SOH>
                                my $BlockStart1 = index ($Queue_input,
"<SOH>");
                                if ($BlockStart1 >= 0) {
                                    open (MOUT, ">" ,
"$ENV{HOME}/.pskmail/.input");
#JD 20-Mar-2009 Removed as does not seem to catch the extra EOT of THOR mode
blocks                                    print MOUT $Queue_input unless
$Queue_input eq     "<EOT>";
                                    print MOUT $Queue_input ;
                                    close MOUT;
                                }
                            $Queue_input = "";

2. I then discovered another issue: now that the server would respond
properly (as evidenced in the log) there was regularly the loss of
transmissions from Fldigi especially in a connect phase. Again this does not
occur with the PSK or MFSK modes.

I then inserted debugging information in the sendit routine just before the
msgsend statement and discovered that the program flow was still getting to
this point but no transmission by Fldigi would occur.

Restarting Fldigi with or without restarting the server would resolve the
issue until the problem reappeared. Once fldigi would stop transmitting it
would need a restart.

I have attached two logs of the data sent to fldigi. Each datagram sent is
preceded by ">>>>" to differentiate from a log generated CR/LF and one
embedded in the datagram.

In the THOR log that the sequence "0!!VK2ETA-1 0.7.20-IM6>" is never
transmitted by Fldigi. As expected the data sent to Fldigi is the same for
both modes. Therefore I excluded the server side as an issue.

I then reverted to Fldigi 3.03 and the problem disappeared.

So I conclude that something must have changed between version 3.03 and 3.10
of Fldigi which creates this problem and only with the THOR modes.

I am not sure how to progress from there: do you contact the author of
Fldigi or should I do it?

Regards,

John (VK2ETA)

Other related posts: