?

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

?

?

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

?

?

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

?

?

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

?

?

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

?

?