ATE Version 6.2
Windows 10 64bit
Ashell version 6.2.1428.0
Linux version RHEL 7.3

after connecting to the system, if you use your "flip screen" button more that 15 times, your ATE window will completely disappear.

This has been happening on several of my clients, whom have upgraded to windows10.

Of course, you know I can not duplicate the problem on any of my PCs.


by the way, does everyone have to "run as administrator" when executing ATE to make changes in configuration ?


I have noticed that if you use SSH rather than TELNET, the problem goes away, but unfortunately, introduces other issues, which can be put in another thread.

can anyone duplicate this problem, or give me advise on how to resolve this.

Thank you
JMaxwell

I tried this test with...

CentOS 5 (32 bit)
A-Shell 6.2.1428.9
ATE 6.2.1428.8 (on Windows 10)
pdksh 6.2.14-37

... and wasn't able to reproduce the crash-after-15-flips problem.

I'm going to move on test this to CentOS 7 (but just to clarify, when you say RHEL 7.3 you really mean a very recent release, and not the old Red Hat 7 from a decade ago?)

In the meantime, ATE offers you the choice of configurations tied to the current user or to all users. You can see it in the ID tab of an existing config:


And when creating a new config, the first dialog gives you the choice.

The problem with the "all users" option is that you probably do need admin privileges to edit it. For that reason, I recommend using the "current user" version (assuming you want to allow users to easily edit their own configuration).

Ok, I've tested it now with CentOS 7 (which should be roughly equivalent to RHEL 7)...

CentOS 7 (64 bit) 3.10.0-327.28.3.el7.x86_64
A-Shell 6.2.1428.0
ATE 6.2.1428.8 (Windows 10)
PolyShell 1.4.165
mksh (replacement for pdksh/ksh) 46-5.el7.x86_64

Same results as before: both SSH and TELNET connections are able to swap (I tried 50 back-and-forth) without apparent issue.

Given the complications with telnet and ksh under RHEL, I'm wondering whether you had to do anything tricky to get them installed, which might be a source of differences between my CentOS test environment and your RHEL environment(s). Does RHEL even support either the telnet-server or the mksh packages?

Three more questions:

1) Can either of us connect to one of the target systems to reproduce?

2) Is there anything interesting in either the server-side or ATE-side copy of ashlog.log? (It's not clear if ATE is crashing first, in which case the server will just see the SIGHUP, or the server side is crashing in which case there might be a SEGV or other message in the server ashlog.) And the ATE side ashlog may or may not have an indication of how the session was closed. (Note that 6.2.1428.7 did refine the ATE-side disconnect log messages to make it easier to distinguish between different types of disconnects.)

3. Have you tried it with ATE 6.3?

i actually now have ATE 6.3 on my PC.
profile set to "current user"
and telnet to Centos5
and my flip screen kicks me out.

wait a minute...

If I execute ashell WithOut the "-x" then my flip screen works fine.

can you test.

Sorry, that should be: execute PSHELL

Can you execute: pshell -x -l2
and see if your screen disappears in 16 `

Bingo - you found the Easter egg!

I have no idea (yet) what the problem is, but surely it will reveal itself now that we can reproduce it. Thanks for the detective work!

When this wild and crazy Undocumented Feature is destroyed, I will need a new RHEL7 version with TW catalog.

Even though it seems you've provided a road map to the precise problem, and despite working on it for quite a while over the weekend, I'm chagrined to report that it is still a mystery. Here's what I can tell you:

1. It doesn't seem to affect SSH, only TELNET. (It also doesn't occur on the console.) Given that TELNET offers no advantages over SSH in the Linux world (in fact, it's harder to install and is universally deprecated by anyone with concerns about security), perhaps we should take at as a message and just leave it there.

But if that doesn't completely satisfy our curiosity...

2. It doesn't seem related to the version of A-Shell, PolyShell, or ATE. I've tried combinations going back to 6.0 with the same results. (Which raises the question why this was never noticed before?)

3. It doesn't seem related to the version of Linux; at least it occurs in CentOS 4, 5, and 7. (It does not occur with AIX though.)

4. It doesn't seem related to the version of ksh. I have pdksh 5.2.14-30.3 on CentOS 4, 5.2.14-37.el5_8.1 on CentOS 5, and mksh 46.5.el7.x86_64 on CentOS 7. (The telnet-server versions also vary from CentOS release to release, although the range is small - from 0.17.60 to 0.17-60)

5. It's not even dependent on the pshell -x switch. (I thought that would make it easy to track down, since there's only a single conditional in the entire package. But even without -x, the same thing happens after hitting the "polykey" 15 times. (You don't even have to toggle between sessions, just go back and forth between one session and the PolyShell menu.) It also doesn't seem to matter what the "polykey" is - I've tried {, }, and ` with same results.

6. It does, however, seem to be related to the ATE telnet client implementation, since it doesn't occur with the Putty telnet implementation.

7. There's no obvious crash or error on either side of the connection. ATE gets the error that the server terminated the connection, while A-Shell on the server gets a SIGHUP indicating the connection was dropped (somewhere). Unfortunately, UNIX signals do not reveal the sender to the receiver, so it's hard to track down the circumstances of the SIGHUP signal. But there are no obvious stack overflows, invalid memory references, etc. based on running various system trace tools on either side, and nothing mysterious reported in any of the logs.

There are still some things that I haven't checked, including whether there is any connection to the Windows version or socket library version. And I haven't yet run a packet trace. But I may need to give it a a breather first. If you can identify a version that doesn't have the problem, please me know, as that might be a useful clue.

This issue does not happen when you use Windows XP. This is why, for a long time, I thought the issue was a windows 8/10 issue. Rather than an ATE issue, even though, the problem did not occur when using putty or zterm. and the problem did not occur when connected to AIX.

It's a real bummer. In the past, I have just changed ATE to use SSH instead of Telnet for these one off issues. The reason I bring this up, is due to looking at moving a couple of our really big clients from AIX to Centos, and they of course have Lots of users currently configured with Telnet. Touching each computer will be a very large task.

As always, thank you very much Jack, for taking the time and effort to look into this issue.

This is not (necessarily) an attempt to avoid fixing the problem, but assuming you did see the wisdom in moving the users from TELNET to SSH, it wouldn't be difficult to convert existing ATE configurations from TELNET to SSH under application control. There's a handy subroutine for this, ATEREG , and here\'s a sample program illustrating how easy it is to use.

You could first retrieve the current transport setting, and if TELNET, switch it to SSH (along with a handful of related configuration settings, such as the port, file transfer options, etc.)

I would be very much be interested in that. Could you write the "easy" program to switch Telnet to SSH. Also, could this program change the "allow all users" to "only this user".

As the song goes, the difficult (first part) I'll do right now, the impossible (second part) will take a little while...

The issue with second part is that it isn't an option within the configuration like any of the others; instead it determines where the configuration is stored in the registry. While it might be possible to retrieve all the settings from the current (all user) area and rewrite them into the "current user" area, we generally wouldn't have privileges to update the "all users" profile unless the session had been launched as administrator. And that also explains why the first part might be difficult, since if the configuration is "all user", then we probably can't update it. I should have thought of that before making my suggestion...

But, let me ponder this. It may well be that the existence of a "this user only" version of the configuration would make the "all user" version effectively invisible, which case both parts of the problem collapse to one (i.e. copying the "all user" config to the "this user" area).

Ok, I posted a new utility to the SOSLIB - ATEREGCVT.BP which you can use to convert the existing profile from "all-user" to "current-user-only", and/or from TELNET to SSH.

It requires the latest ATEREG.SBX (You might as well install the entire SOSLIB just to make sure you have all the pieces to compile it, although it only needs a couple of files from SOSFUNC: and the ASHELL.DEF).

And that requires a reasonable version of ATEAPX.SBX, but you probably already have that that. With those two SBX's in BAS: (on the server), just RUN SETATECVT. If all goes well, from an existing all-users/TELNET connection, it should respond like this:

If the configuration is already current-user, but still TELNET, it looks like this:

And if it's already both, it looks like this:

The program is reasonably self-documenting so you can probably edit it as needed to make other changes to the configuration.

thank you very much jack for working on this for me. this will make converting the ATE setting much easier. I have been working on a way to do this using regedit, but there are many ways that could go wrong. The solution you are providing seems much much better, and will work on all platforms.

Deer in the headlights moment ...
It appears that I am not near as smart as you think I am. i am going to need more hand-holding step-by-step instructions on how to download these new programs, and get them to a working state, so that i can type: run setatecvt. I am completely lost in the instructions you gave earlier, especially the part about compiling them. and when i click on the links, they take me to your open ascii source code, not sure if you meant for that.

Once you go through that door Jason, there's no going back!

Indeed I may have assumed that you were more familiar with these programming obscurities.

The links to the source code were intentional, with the idea that casual readers can review the code online, while people who want to actually use it can either cut and paste it into their local file editor, or just download the entire repository using the Downloads link in the Navigation panel on the left of the repository screen. (Unzip it into the [90?,*] directories in your development environment where they can be easily referenced.)

But since it sounds like you're not doing much coding and just want the compiled modules so you can run them, I've posted them here . (Just download them all into your BAS: directory.)

However: to get the maximum benefit of this idea, you may want to edit the program to make further adjustments to some of the configuration settings.
Although ultimately you should get the real SOSLIB repository set up on your computer in order to enable programming with it, I'll email you a separate zip of just the pieces you need for this project.

I know this is beating a dead horse, but ... I wanted to add some detail just in case.

This issue does not happen when running on Windows XP.

Also, I loaded an old version (5.1.1217) of ashell and 5.1(somthing) of ATE, running on a windows 10 computer, and got the following message when the screen bombed :

Windows telnet socket read error #10053: An established connection was aborted by the software in your host machine.


by the way, the ateregcvt that you gave me works Great !! I was even able to make a copy, make modifications, compile, and got that to work too. Thanks soo much for your help.

Thanks for the update. I've been a little derelict in not getting to the bottom of what exactly is going wrong, but the existence of the workaround has allowed me to downgrade the priority slightly.

As your further research shows, although the issue is tied to ATE, or at least the version of the Windows network socket library used by ATE, it has been around for a long time (at least as far back as 5.1), only surfacing in a Windows update some time after XP. The error #10053 dialog is essentially reporting that ATE thinks the server disconnected the session (which is probably accurate). But from the server side, it looks like something is sending a SIGHUP signal to the current session, as if it was ATE (or maybe the telnet service, or ksh) that initiated the disconnect.

The fact that it varies with the version of Windows suggests that it really is a problem in the socket library, which is essentially in the middle between ATE and the server, so that both ends see the other end as the problem.

The silver lining is that it provides motivation to do something that really should be done anyway, i.e. switch from telnet to SSH.

But it's still on my list to investigate further, perhaps with a packet trace.