?

Hello,

A message was sent to the group /g/w1eo from johnm@... that needs to be approved.

View this message online

Subject: Re: [w1eo] New file uploaded to [email protected]

I believe that the developers are sadly mistaken. There are lots of folks out there that think that any incomplete session should be logged. It's like not knowing that someone is trying to break in your house, but stopped because of some reason! I like knowing. Developers should not just decide what logging information is not needed or wanted, and they should not just change the game plan in mid-game when the strategy was working great!

My .02 and I know there are lots more of folks out there that feel that this is important but DoC is doing a good job of pounding the table.

Now that I see it going the wrong direction, I believe that it's time for everyone to speak up to "the developers!"

73, de W0VG
John Maxwell



From: "d g willard" <d.g.willard@...>
To: [email protected]
Sent: Saturday, January 12, 2019 4:16:59 PM
Subject: Re: [w1eo] New file uploaded to [email protected]



Thank you Tom.

I interpret ur comments as stating any session that does not include information exchanged in both directions are (now) considered immaterial and are (no longer) logged. (I would have classified these as failed/incomplete and significant). Conversely, any sessions with information exchanged in both directions (as determined at the Gateway) and with a “FQ” termination byte are (now) considered complete. That leaves those sessions that have information exchanged in both directions but do not terminate in an “FQ” byte – often a “>” byte. What does Winlink call those please so I can modify the Analyzer code to accommodate? It appears that these are also currently ignored. A short definitive list for all sysops would be very helpful.

De DoC




From: [email protected] [mailto:[email protected]] On Behalf Of Tom Whiteside
Sent: Saturday, January 12, 2019 23:00
To: [email protected]
Subject: Re: [w1eo] New file uploaded to [email protected]




I can only report what I have learned through talking with Phil. The only contacts I don’t see making the ADIF file here are the ones where the QSO never really gets started – where the calling station never sends anything back to the initial response from the Trimode. I can live without that in the data and could argue that it is hard to quantify what those connections that never get off the ground mean anyway.



I guess you can tell this is not a priority with the developers. Phil says he has changed nothing overtly in that release so it is a funny artifact and I can tell you we are not going to get any energy spent trying to track it down or code put in place to try to restore things. The best thing I can recommend is to adapt to it the best you can and move on. Sorry I don’t have a more positive answer for you.



Tom N5TW




From: [ mailto:[email protected] | [email protected] ] [ [ mailto:[email protected] | mailto:[email protected] ] ] On Behalf Of DoC
Sent: Saturday, January 12, 2019 4:37 PM
To: [ mailto:[email protected] | [email protected] ]
Subject: Re: [w1eo] New file uploaded to [ mailto:[email protected] | [email protected] ]




Then why did the number of failed/incomplete sessions suddenly degreased so significantly Tom? Phil apparently decided that these kinds of sessions no longer constitute failed/incomplete sessions and his code ignores them currently. UR recent attached log showed none of these. It is inconceivable that they have indeed stopped on their own. Please also note that two grid squares were added to the end of the log records at the same time as the failed sessions were eliminated. So please don’t try to tell me that Phil didn’t touch the code concerning logging.

He also has not made any mention of either of these changes in his update notes. Curious!

De DoC, W1EO




From: [ mailto:[email protected] | [email protected] ] [ [ mailto:[email protected] | mailto:[email protected] ] ] On Behalf Of Tom Whiteside
Sent: Saturday, January 12, 2019 20:39
To: [ mailto:[email protected] | [email protected] ]
Subject: Re: [w1eo] New file uploaded to [ mailto:[email protected] | [email protected] ]




Phil made no changes to that code. We are not rolling it back.



Tom




From: [ mailto:[email protected] | [email protected] ] [ [ mailto:[email protected] | mailto:[email protected] ] ] On Behalf Of DoC
Sent: Saturday, January 12, 2019 2:21 PM
To: [ mailto:[email protected] | [email protected] ]
Subject: Re: [w1eo] New file uploaded to [ mailto:[email protected] | [email protected] ]




Why is it not possible to back up to previous logging functions?




From: [ mailto:[email protected] | [email protected] ] [ [ mailto:[email protected] | mailto:[email protected] ] ] On Behalf Of Tom Whiteside
Sent: Saturday, January 12, 2019 19:18
To: [ mailto:[email protected] | [email protected] ]
Subject: Re: [w1eo] New file uploaded to [ mailto:[email protected] | [email protected] ]




Can’t you parse it without that? Not a requirement for ADIF Master to read the file. I believe that is the only way this is going to get fixed…



Tom N5TW




From: [ mailto:[email protected] | [email protected] ] [ [ mailto:[email protected] | mailto:[email protected] ] ] On Behalf Of DoC
Sent: Saturday, January 12, 2019 1:14 PM
To: [ mailto:[email protected] | [email protected] ]
Subject: Re: [w1eo] New file uploaded to [ mailto:[email protected] | [email protected] ]




Tom;

Not one |>| failed session marked in ur attachment. If u indeed tried the Abort and the P2P connections that proves my claim.

De DoC




From: [ mailto:[email protected] | [email protected] ] [ [ mailto:[email protected] | mailto:[email protected] ] ] On Behalf Of Tom Whiteside
Sent: Saturday, January 12, 2019 14:42
To: [ mailto:[email protected] | [email protected] ]
Subject: Re: [w1eo] New file uploaded to [ mailto:[email protected] | [email protected] ]




Doc,



It is a wonder with the previous and now this accusatory and frankly paranoid rants that I can get Phil to care about your program at all. I for one have spent some hours looking into this but am not encouraged to look further.



I have installed a program called ADIF Master and used that to view my ADIF files and have compared its result with my logs and see that ADIF Master has no difficulties parsing the ADIF file and it looks to me like the necessary information for me to see what happened from them is readable in them. I’d suggest taking a look at changing your parsing to pull this information out. Phil has confirmed that he has changed nothing in the software related to ADIF generation – no doubt something did change in DOT NET or some other thing to change the format.



Tom N5TW




From: [ mailto:[email protected] | [email protected] ] [ [ mailto:[email protected] | mailto:[email protected] ] ] On Behalf Of DoC
Sent: Saturday, January 12, 2019 7:02 AM
To: [ mailto:[email protected] | [email protected] ]
Cc: 'd.g.willard' < [ mailto:d.g.willard@... | d.g.willard@... ] >
Subject: Re: [w1eo] New file uploaded to [ mailto:[email protected] | [email protected] ]




Tom;

Like the cartoon vulture said, “patience hell, I’m going to kill something”.

I have the distinct sense that Phil is stonewalling the repair of this incorrect log processing for failed/incomplete connections. Since the effect is to under report the number of failed connections it has the effect of making Winlink performance appear to be better than it is in reality. While large and diverse communities of served agencies see this, it smacks of fraud. I would think The Development Team would want the logging error repaired ASAP but apparently not as it has been reported for nearly a month, since the Trimode update from version 1.3.20 to 1.3.21 on 14 December, 2018 and now 1.3.22. Proper code development procedures would provide copies of older version source code and notes concerning changes which ought to make isolation of the change straightforward.

Please start a fire under Phil and please let your extensive Gateway sysop brethren know what is going on. Our longtime support deserves to be informed.

73 de DoC, W1EO




From: [ mailto:[email protected] | [email protected] ] [ [ mailto:[email protected] | mailto:[email protected] ] ] On Behalf Of Tom Whiteside
Sent: Monday, January 07, 2019 20:08
To: [ mailto:[email protected] | [email protected] ]
Subject: Re: [w1eo] New file uploaded to [ mailto:[email protected] | [email protected] ]




No. Next step for me is seeing what Phil makes of it. I have sent him your earlier detailed note with some more annotations added.



Tom




From: [ mailto:[email protected] | [email protected] ] [ [ mailto:[email protected] | mailto:[email protected] ] ] On Behalf Of DoC
Sent: Monday, January 7, 2019 1:49 PM
To: [ mailto:[email protected] | [email protected] ]
Subject: Re: [w1eo] New file uploaded to [ mailto:[email protected] | [email protected] ]




I’m reluctant to allow an update until we lick this one Tom. Unless there is some indication that it too got fixed.

So have u tried my suggested tests?




From: [ mailto:[email protected] | [email protected] ] [ [ mailto:[email protected] | mailto:[email protected] ] ] On Behalf Of Tom Whiteside
Sent: Monday, January 07, 2019 19:36
To: [ mailto:[email protected] | [email protected] ]
Subject: Re: [w1eo] New file uploaded to [ mailto:[email protected] | [email protected] ]




I’m sorry – I misunderstood about what you were stopping. Agree stopping a client is a legit test. And yes, looks like one of my Trimode instances updated to .22





Tom




From: [ mailto:[email protected] | [email protected] ] [ [ mailto:[email protected] | mailto:[email protected] ] ] On Behalf Of DoC
Sent: Monday, January 7, 2019 1:25 PM
To: [ mailto:[email protected] | [email protected] ]
Subject: Re: [w1eo] New file uploaded to [ mailto:[email protected] | [email protected] ]




I am stopping an across-the-desk client by clicking its abort button. The client call sign is not the same as my Gateway so I don’t see how that would be different from any other client aborting Tom. That process used to work on the previous version, so should be a valid option now.

My logs definitely show an update in version number in the except I sent earlier today.

Do I see a new version of Trimode being used? 1.3.22.0???

De DoC




From: [ mailto:[email protected] | [email protected] ] [ [ mailto:[email protected] | mailto:[email protected] ] ] On Behalf Of Tom Whiteside
Sent: Monday, January 07, 2019 19:07
To: [ mailto:[email protected] | [email protected] ]
Subject: Re: [w1eo] New file uploaded to [ mailto:[email protected] | [email protected] ]

From what Colin said, I’m not so sure this really started with version 1.3.21.0. And I’m not sure how things should be logged that you stop yourself… I will pass along what you have sent which is helpful and maybe it will be enough for Phil to spot something.

Tom




From: [ mailto:[email protected] | [email protected] ] [ [ mailto:[email protected] | mailto:[email protected] ] ] On Behalf Of DoC
Sent: Monday, January 7, 2019 12:41 PM
To: [ mailto:[email protected] | [email protected] ]
Subject: Re: [w1eo] New file uploaded to [ mailto:[email protected] | [email protected] ]




Tom;

I think I have done exactly that already. Snapshots of Trimode panel and snapshots of adi log files, including my most recent where Trimode version changed. I really don’t know what else I can do to identify the issue except perhaps offer to look in the source code myself if Phil would make it available to me (unlikely). I’d compare code segments that generate the ‘Connection Summary’ line in 1.3.20.0 and 1.3.21.0 versions. A further clue might be where the two new GS were added at the end of the adi record. Although I can think of no connection they did appear at the same time.

I ask again, have u tried causing an incomplete session by clicking the abort button or selecting one of the P2P options or having one of ur clients do either? Pretty simple test to perform on ur own Gateway Tom.

And do u agree with my description of what ought to happen and what used to happen previously as presented in my immediately previous message to this topic?

I just got back from a morning of errands – should be here for the remainder of the day. Want to watch things here?

De DoC




From: [ mailto:[email protected] | [email protected] ] [ [ mailto:[email protected] | mailto:[email protected] ] ] On Behalf Of Tom Whiteside
Sent: Monday, January 07, 2019 14:50
To: [ mailto:[email protected] | [email protected] ]
Subject: Re: [w1eo] New file uploaded to [ mailto:[email protected] | [email protected] ]




I’m trying to nail down as specifically as possible what is different from what you saw before to now and when it occurs. That is the sort of information Phil will need to see what to look for in the code. Just saying go back to a previous version without knowing what broke is not realistic.



Can you spell out with very specific examples of where it is working today and where it is not working with examples of what is different from the previous version – make it as clear as possible to help him see the problem and give him a better idea where to look.



Tom




From: [ mailto:[email protected] | [email protected] ] [ [ mailto:[email protected] | mailto:[email protected] ] ] On Behalf Of DoC
Sent: Monday, January 7, 2019 8:30 AM
To: [ mailto:[email protected] | [email protected] ]
Subject: Re: [w1eo] New file uploaded to [ mailto:[email protected] | [email protected] ]




I can’t tell without catching a connection in progress Tom. However, see my most recent message in this topic which shows several successive incomplete record logs under the Trimode version 1.3.20.0 – there are very short ones ~~3 seconds and very long ones ~~60 seconds.

Is it not possible for Phil to back up to 1.3.20.0 to repair log processing? Looks like he needs a beta tester. It is very hard to get good code without one – I lost mine a while ago and really miss him. During my code development I have had instances where I had to back up a version or two and make a fresh start which is why I maintain all my old version source codes. It is my contention that any connection session that does not include a termination byte of ‘FQ’ should be considered failed/incomplete and result in a log entry showing termination byte of ‘>’. Otherwise if ‘FQ’ that should be shown in a log entry and considered complete. All connections, failed or complete should result in a log entry – as it used to under 1.3.20.0 version.

De DoC




From: [ mailto:[email protected] | [email protected] ] [ [ mailto:[email protected] | mailto:[email protected] ] ] On Behalf Of Tom Whiteside
Sent: Monday, January 07, 2019 13:49
To: [ mailto:[email protected] | [email protected] ]
Subject: Re: [w1eo] New file uploaded to [ mailto:[email protected] | [email protected] ]




I went back through a bunch of logs and what I am seeing is no summary if the connection fails early on but a consistent summary if it terminates after getting the initial traffic listing started or later. Does that match what you are seeing?



Tom N5TW




From: [ mailto:[email protected] | [email protected] ] [ [ mailto:[email protected] | mailto:[email protected] ] ] On Behalf Of DoC
Sent: Sunday, January 6, 2019 8:26 PM
To: [ mailto:[email protected] | [email protected] ]
Subject: Re: [w1eo] New file uploaded to [ mailto:[email protected] | [email protected] ]





Yes that’s normal Tom But below is not. An incomplete connection without a ‘Connection Summary’ line and no log record entry.





\


<call:5>N5BLP<qso_date:8>20190106<time_on:6>144837<time_off:6>145105<mode:7>ARDOP20<gridsquare:6>FN00JF<band:3>40M<freq:8>7.104500<comment:145>0|2019-01-06 14:51:05|RMS Trimode|1.3.21.0|CMS|W1EO|N5BLP|[RMS Express-1.5.17.1-B2FHM$]|ARDOP20|7104500|706|252|FQ|0|1|213|1993|148|FN00JF|FN42IM<eor>


<call:5>VP9NM<qso_date:8>20190106<time_on:6>190603<time_off:6>191257<mode:8>WINMOR16<gridsquare:6>FM72NG<band:3>30M<freq:9>10.144500<comment:146>0|2019-01-06 19:12:57|RMS Trimode|1.3.21.0|CMS|W1EO|VP9NM|[RMS Express-1.5.17.0-B2FHM$]|WINMOR16|10144500|1270|152|[T|1|0|820|88|413|FM72NG|FN42IM<eor>


<call:5>W2UTR<qso_date:8>20190106<time_on:6>210235<time_off:6>210433<mode:8>WINMOR16<gridsquare:6>FN20XR<band:3>80M<freq:8>3.597900<comment:144>0|2019-01-06 21:04:33|RMS Trimode|1.3.21.0|CMS|W1EO|W2UTR|[RMS Express-1.5.17.1-B2FHM$]|WINMOR16|3597900|303|230|FQ|0|0|208|83|117|FN20XR|FN42IM<eor>


<call:4>NN1G<qso_date:8>20190106<time_on:6>222130<time_off:6>222322<mode:0><gridsquare:6>FN33UP<band:4>160M<freq:8>1.845000<comment:143>0|2019-01-06 22:23:22|RMS Trimode|1.3.21.0|CMS|W1EO|NN1G|[RMS Express-1.5.17.0-B2FHM$]|Pactor 2|1845000|149|327|FQ|0|0|207|76|111|FN33UP|FN42IM<eor>


<call:6>KC3DSO<qso_date:8>20190106<time_on:6>223102<time_off:6>223235<mode:4>Vara<gridsquare:6>FM19AU<band:3>80M<freq:8>3.597900<comment:139>0|2019-01-06 22:32:35|RMS Trimode|1.3.21.0|CMS|W1EO|KC3DSO|[RMS Express-1.5.17.0-B2FHM$]|Vara|3597900|630|244|FQ|2|0|0|111|93|FM19AU|FN42IM<eor>


<call:5>K1JOZ<qso_date:8>20190107<time_on:6>012239<time_off:6>012308<mode:4>Vara<gridsquare:6>FM18KI<band:3>80M<freq:8>3.597900<comment:137>0|2019-01-07 01:23:08|RMS Trimode|1.3.21.0|CMS|W1EO|K1JOZ|[RMS Express-1.5.17.0-B2FHM$]|Vara|3597900|676|229|FQ|0|0|0|83|29|FM18KI|FN42IM<eor>





Note the time between the Trimode panel and the adif log entries – no entry for this failed connection.


And notice the two GS at the end of the log entries. New to version 1.3.21.0 so Phil had to have changed something Tom.


de DoC


From: [ mailto:tomw@... | Tom Whiteside ]


Sent: Sunday, January 06, 2019 22:27


To: [ mailto:[email protected] | [email protected] ]


Subject: Re: [w1eo] New file uploaded to [ mailto:[email protected] | [email protected] ]





Here is an earlier example of what I’m seeing here:



2019-01-06 20:06:04 1.3.21.1 FF

2019-01-06 20:06:04 1.3.21.1 FC EM EAAMMCAMWSZB 15987 10441 0

2019-01-06 20:06:05 1.3.21.1 F> 88

2019-01-06 20:06:25 1.3.21.1 FS Y

2019-01-06 20:06:25 1.3.21.1 [Transferring binary data to Pactor TNC]

2019-01-06 20:29:03 1.3.21.1 [CmsLink.OnDisconnectFromCms] Remote Host = 192.168.213.10

2019-01-06 20:34:08 1.3.21.1 *** Disconnected from KC2IOV at 2019-01-06 20:34:08 UTC, CMS link ended

2019-01-06 20:34:08 1.3.21.1 --Connection Summary-- 2019-01-06 20:34:08 Mode: Pactor 3 Bytes Confirmed Sent: 15579 Bytes To CMS: 549 Peak Bytes Per Min: 969 Last Command: [T Session Time: 45.3 min

2019-01-06 20:34:08 1.3.21.1 *** Disconnected from KC2IOV at 2019-01-06 20:34:08 UTC, New Link direction: Disconnected

2019-01-06 20:36:43 1.3.21.1 Error induced restarts: Pactor=0 WINMOR=0 Vara=0 Robust Packet=0



Is that not normal?



Tom N5TW




From: [ mailto:[email protected] | [email protected] ] [ [ mailto:[email protected] | mailto:[email protected] ] ] On Behalf Of DoC
Sent: Sunday, January 6, 2019 4:11 PM
To: [ mailto:[email protected] | [email protected] ]
Subject: Re: [w1eo] New file uploaded to [ mailto:[email protected] | [email protected] ]





I think even without the ADIF box checked, there will be missing record log entries for each failed connection Tom.





From: [ mailto:tomw@... | Tom Whiteside ]


Sent: Sunday, January 06, 2019 22:03


To: [ mailto:[email protected] | [email protected] ]


Subject: Re: [w1eo] New file uploaded to [ mailto:[email protected] | [email protected] ]





Will let you know. For now am waiting for someone to have a failed connect to observe the symptoms now that I have adif logs enabled.



Tom




From: [ mailto:[email protected] | [email protected] ] [ [ mailto:[email protected] | mailto:[email protected] ] ] On Behalf Of DoC
Sent: Sunday, January 6, 2019 4:00 PM
To: [ mailto:[email protected] | [email protected] ]
Subject: Re: [w1eo] New file uploaded to [ mailto:[email protected] | [email protected] ]





would it help if we used SKYPE and Team Viewer to have u observe it here?





From: [ mailto:tomw@... | Tom Whiteside ]


Sent: Sunday, January 06, 2019 21:46


To: [ mailto:[email protected] | [email protected] ]


Subject: Re: [w1eo] New file uploaded to [ mailto:[email protected] | [email protected] ]





I’m not sure aborting a connection yourself should count or is counted but with current conditions there should be plenty of log entries reflecting problems if the code is working properly. I recently had to rebuild my Winlink machine and had neglected to check the adif log selection. I have fixed that and will watch for connections with problems.



Tom N5TW




From: [ mailto:[email protected] | [email protected] ] [ [ mailto:[email protected] | mailto:[email protected] ] ] On Behalf Of DoC
Sent: Sunday, January 6, 2019 3:27 PM
To: [ mailto:[email protected] | [email protected] ]
Cc: d.g.willard < [ mailto:d.g.willard@... | d.g.willard@... ] >
Subject: Re: [w1eo] New file uploaded to [ mailto:[email protected] | [email protected] ]





That is really unbelievable Tom. Several other sysops have noticed and reported it happening. As I suggested in my original message on this thread, the sysop can cause a message to fail or be incomplete by either clicking the abort button during the early stages of an across-the-table connection or by selecting a P2P mode while doing the same. Alternatively, he can have a client do that for him. Then watch the Trimode panel and u will see no ‘connection summary’ line and there will be no entry in the log. If u r running a Gateway, please try that urself.


Other sysops reading this thread, please chime in with ur observations.


de DoC





From: [ mailto:tomw@... | Tom Whiteside ]


Sent: Sunday, January 06, 2019 21:04


To: [ mailto:[email protected] | [email protected] ]


Subject: Re: [w1eo] New file uploaded to [ mailto:[email protected] | [email protected] ]





Phil says he has never even looked at the code that generates the .adi files – so no changes to Trimode we are aware of.



Tom N5TW




From: [ mailto:[email protected] | [email protected] ] [ [ mailto:[email protected] | mailto:[email protected] ] ] On Behalf Of DoC
Sent: Sunday, January 6, 2019 10:47 AM
To: [ mailto:[email protected] | [email protected] ]
Cc: 'd.g.willard' < [ mailto:d.g.willard@... | d.g.willard@... ] >
Subject: Re: [w1eo] New file uploaded to [ mailto:[email protected] | [email protected] ]




Most of the failed/incomplete record log entries are missing Tom. Lately a few of the apparently complete connections do not result in a ‘connection summary’ line in the Trimode panel and no record adi log entries. These changes/errors were introduced with update to version 1.3.21.0! I have passed this information on to Phil and the WDT but have not received any response. Very frustrating. See my original message in this thread.

I hope u can help get us back to version 1.3.20.0 logging.

Thanks in advance for anything u can do de DoC, W1EO




From: [ mailto:[email protected] | [email protected] ] [ [ mailto:[email protected] | mailto:[email protected] ] ] On Behalf Of Tom Whiteside
Sent: Sunday, January 06, 2019 16:34
To: [ mailto:[email protected] | [email protected] ]
Subject: Re: [w1eo] New file uploaded to [ mailto:[email protected] | [email protected] ]




Is it just the failed or incomplete contacts that you see missing? I will get the information to W4PHS but want to describe it as completely as possible.



Tom N5TW




From: [ mailto:[email protected] | [email protected] ] [ [ mailto:[email protected] | mailto:[email protected] ] ] On Behalf Of DoC
Sent: Sunday, January 6, 2019 10:20 AM
To: [ mailto:[email protected] | [email protected] ]
Subject: Re: [w1eo] New file uploaded to [ mailto:[email protected] | [email protected] ]




Any suggestions as to what to do about RMS Analyzer? It is no longer very informative when Trimode adi logs are missing important information. It seems futile to make any further updates now. .I do hope these WDT actions are not intentional. Eliminating the log records for failed/incomplete connections to make the Winlink network performance appear better than it really is seems to border on being fraudulent.
73 de DoC, W1EO

A complete copy of this message has been attached for your convenience.

View this message online

To approve this using email, reply to this message. You do not need to attach the original message, just reply and send.

To reject this message using email, and to have the sender notified of this, forward this message to:

[email protected]

To delete this message using email, forward this message to:

[email protected]

NOTE: The pending message will expire after 14 days. If you do not take action within that time, the pending message will be automatically rejected.

Thank you for choosing Groups.io Groups

Cheers,
The Groups.io Team