is the [FTP] tab in the ATE configuration used for more than performing the update? Might there be a check box option in the [FTP] section, that by Default, you can use the connection options set in the [Transport] section has the connection method. This would come in handy when users change their connection method, such as login and Telnet-vs-SSH in the [Transport] section, so that they would not have to also remember to change them in the [FTP] section.
I know that it copies the settings from [Transport] to [FTP] during an initial setup of the profile, but most of our users will change the login and transport type. (I know this is not really a big deal, i was just brain storming.
If it's not something everyone else could use, let me know, and i will simply add a couple of additional lines to my 'client update ATE' documentation.

That's a good idea - adding a checkbox to disable the separate login info and use the login already stored on the Login tab.

In the case of SSH, there's almost no reason to have any option of protocol, port, passive, or login (since surely we would use the same login for SFTP as for the SSH terminal login). Only the timeout option makes any sense. So in this case, the checkbox would make sense above the file transfer protocol option.

But in the case of TELNET or TUNNEL, all of the options could be set separately from the terminal transport/login tabs, since there is no standard "TELNET" file transfer. So in this case, it might seem weird for the checkbox to be above the Protocol and Port fields (since it would really only affect the login fields). Or would it?

I would assume, that if you're using TELNET, then the default transfer method would be FTP. A lot of times, clients will use TELNET/FTP simply because SSH/SCP is not available. as far as the TUNNEL thing goes ... i'm not even sure why thats still an option.

More good points. You're quite right that if SFTP (aka FTP over SSH) is available, it's hard to come up with a reason for not using SSH for the main connection. (And if for some reason you really want to use TELNET and SFTP, you can just uncheck the option to tie the file transfer configuration to the main transport.)

nd yes, I'm not sure why TUNNEL is an option either. Is anyone using it? If so, why not use SSH instead?

The one reason I know of is that there was an intermittent spontaneous disconnect problem in the original SSH implementation, which did not affect the TUNNEL or OpenSSH options. But the original OpenSSH implementation locked up during an "su" operation, leaving TUNNEL as the only option without a known lockup/disconnect problem. However, as of 5.1.1215 (ASHNET2.DLL 2.0.202), the new OpenSSH implementation seems to have solved all the known issues, and I'm in the process of removing the option entirely.

As for the "FTP" properties panel (should this be renamed to "File Transfer"?), here's the new layout I'm planning...

(If the "Same as Main Transport/Login" checkbox is checked, then (nearly) everything below that will be fixed according to the corresponding Transport and Login options and disabled. The only exceptions would be:

- The Timeout option is always enabled

- In the case of TELNET/FTP, the Port and Passive options remain enabled.

Brilliant !

BTW, you can test it by running the ATE 5.1.1228.1 setup

no i cant.

when i execute ATE5.1 and use the drop down box to choose the profile i want - it automatically executes the profile, without giving me the opportunity to choose [configure].

i do see that i can click [configure] immediately, then once i'm in, change the "connection name" to the profile that i want to modify. So, that was a new feature that i needed to learn.

I've noticed that the 'port number' does not change appropriately when you have the 'link to Transport...' box checked.

I've also noticed that if you have SSH/SCP setup, and if the login attempt for the transfer fails, it prompts you to retype your FTP login and passwd. Obviously, this is a notification to the user that something is not setup correctly, and it needs to be fixed, but i didn't know if you wanted to do something there along the lines of allowing the user to be able to choose FTP vs SCP or not.

Try running that 1228.1 setup again. I just re-posted it (use the same link I gave above) with an updated configuration setup dialog (version 151, as seen on the Connection Properties About tab). That should dial back the "sensitive trigger" on the CONNECT button, at least a bit.

Since I often switch between several configurations (as I suspect many dealers do), rather than have a bunch of shortcuts, I like to just bring up the connection dialog, type enough letters to select the configuration I want, and hit ENTER to connect. (BTW, the ability to select from the combo with multiple keystrokes is a relatively new A-Shell enhancement; previously, and with standard combos, it only selects on the first character.)

In previous versions of the connection dialog, hitting ENTER didn't launch the connection; instead you had to hit TAB a couple of times, or use the mouse to click on the Connect dialog, which seemed excessive to me. So I turned it into a "fast combo". But admittedly, it was a bit too fast. (You could have just hit TAB to move from the combo to the various buttons, but maybe that wasn't obvious.)

Anyway, with this version, it still launches the connection on ENTER, but you should be able to use the mouse to drop down the list and select one, without it immediately launching. Let me know if it is still too sensitive - I can return it to the way it was in 148 and before.

Now, to return to your comment about the port number not changing appropriately when you click the "link to Transport" checkbox, I'm not sure I see what you're complaining about. Certainly in the case of SSH, clicking on the "Link..." checkbox will change the file transfer port to match the SSH port on the Transport panel, which seems right to me. In the case of Telnet, admittedly, the port doesn't change, and perhaps it should change to port 21, but we don't really know at this point what port your FTP answers at, so the port field remains active, allowing you to change it. (I guess I think it's better to err on the side of not automatically changing the port number if we aren't reasonably sure of what to change it to.)

But I'm open to adjusting the logic if you can explain exactly the situation you're worried about.

As for what to do at runtime if the file transfer login fails, perhaps the dialog that prompts you to enter a login should give you the option at that point to also link to the transport login, but that's all happening inside A-Shell rather than the ATE config dialog, so I'm not sure how far I want to take reproducing the logic.

Maybe adding a "Test Connection" button on the File Transfer panel might be nice though? (Adding such an option to the Transport panel seems a bit excessive, since you can test that with just two more clicks - OK, CONNECT.)

Late to this thread, sorry.

YES! We are using TUNNEL because of those spontaneous disconnects using SSH. This was a huge problem for us on our hosted server, when large chunks of data were being exhanged. Most notably when displaying large xtree grids, or displaying print files to the screen using Xtext.

Right, but that issue has been resolved in the new OpenSSH implementation (which came out in ATE 5.1.1215.0). (Feel free to verify that for yourself.)

add it to the list....

my only point before was that when you have set in your TRANSPORT page to use SSH as a protocol, and you had set in the FILE TRANSFER page to use defaults. IF you simply changed the TRANSPORT page to use TELENET, and save -- that in the FILE TRANSFER page, the Protocol had been successfully changed to match with FTP, BUT the PORT: number still reflected the previous setting of 22 and did not automatically change to 21 to match the default TRANSPORT Type of FTP.

So, i guess what i'm saying is that if you have the "Link to Transport..." option checked, that each of those settings should Pull from the other Transport and Login pages. (and to default to 21 for FTP and 22 for SSH) If for any reason, a client has to modify any of these options, the then must Uncheck "Link to Transport" and enter their specific settings.

Again, just an idea. There may be a good reason not to do that.

I think there was really only one case that needed to be fixed, and it was the one you described, where you were changing from SSH/SFTP to TELNET/FTP. The difficulty here is that we don't know for sure what the FTP port is. BUT, we do know that the FTP port can never be the same as the SSH Port (which we still have saved on the Transport panel, even after changing from SSH to TELNET). So in that case (i.e. when either linking or unlinking the file transfer protocol from the main connection protocol), it will change the FTP port to the default of 21. Otherwise it will leave will leave it alone. And as you may have noticed, it does remember the file transfer transport/login parameters from the un-linked case, so that if you link, and then un-link again, it restores the original parameters. (I'm sure you've been marveling at what a great feature that was, and just hadn't gotten around to telling me about it.)

(Re-reading the paragraph above, I think we can safely assume that hardly anyone will be able to make any sense of it, and the sequence of events that we're talking about is pretty obscure anyway, so I'm probably safe even if completely wrong.)

oh yeah, that's good stuff !!