X-SecurePro Version 7.7: X-Server with SSH.
Date: 3 December 2004
Labtam is pleased to announce a new software release named XSecurePro Version 7.7. This is the third major release for the 2004 year.
X-SecurePro is our latest X-Server based software addition. Not only does it contain the key X-Server elements, it also provides Encryption Security using the SSH standard from PC to host machine. X-SecurePro brings you maximum Security to a PC and a company Lan/Wan or Intranet/Internet.
Integrating the Microsoft Windows and X-Window System environments X-SecurePro is an inexpensive but powerful and effective way to transform a standard PC into a fully functional X-terminal.
Included in the package are the X-Window System, SSH, TCP/IP, FTP, TFTP, LPR, LPD, TELNET and NFS plus a whole lot more. Everything that you need to run all your remote Unix and X applications is included.
New Features on this release include
The following enhancements have been made
- The InstallShield X is used in the installation procedure.
16-bit executables are not used from this version
- can copy files with illegal symbols using a map table
- corrected processing of the XServer DynamicDisplayNumber generation
- NFS_Server refuses to close and shut down the system if mounts are active
5. Telnet and Telnet_SSH:
- improved the viewing of the terminal output buffer
to provide correct work when terminal output is in progress
- provided more correct "rubber rect" drawing/processing
- the X11R6.6 sources are utilized
- implemented the "GLX_PixelFormat=..." manual setting into OPENGL32
ChoosePixelFormat() system call to decrease the unexpected 100-sec delay
(some especial CAD-oriented NVIDIA drivers show such an incorrect behaviour)
- implemented the "TraceFontsRequests=..." KbdMacros
to dynamically change the XServer's TraceFontsRequests mode
- implemented more correct naming/copying/renaming of the "xserver[N].out" file
- renovated the "rgb.txt" file to satisfy some new RGB color names requests
The following bugs have been fixed
- the bug when a number of inodes exceeds maximal value
- corrected the 'inremnode failed' message
2. NFS-Client for MS Windows NT4/2000/XP:
- the BSOD ("Blue Screen") may take place under the WinXP+SP2 system
after attempting to view a list of available NFS-Servers
- Telnet_S may crash when closing the session
- XServer/Single+TWEAKui: suppressed unnecessary internal SetActiveHwnd
- fixed an incorrect FontServer reconnection (with 100% CPU usage)
- implemented the "Auto-start XwpPeg Package Watcher" setting to provide the corresponding control of the XwpPeg facility;
- FTP connections (in the "non-Passive", default, mode) can be made through an existing SSH connection with the prepared Forwarded ports. This way does not require a special Telnet/SSH facility and can be used with any SSH-client which provides traditional Forwarding. All settings are made manually. Let's assume that you need to access the remote host (say, 192.168.136.41) via FTP, and an SSH connection is made with the SSH daemon which is on another remote host (say, 192.168.136.34), and each host is directly accessible one from another (192.168.136.41 <-> 192.168.136.34). Also, you should know two free ports on the local machine (say, 21 and 4444) and one on the remote host connected via SSH (say, 5555 on 192.168.136.34). At first, two forwardings must be made via the SSH-Client facility. Local-to-Remote: "21->192.168.136.41/21" (natural for FTP) and Remote-to-Local Forwarding: "4444<-5555". After that you must add two lines to the "[FTP]" section in the "xwp.ini" file: "IP_SSH_FWD=192.168.136.34" and "PORT_SSH_FWD=5555,4444" (i.e., specify the remote and local ports). Now the FTP can be started. The "host" field must contain "localhost" or "127.0.0.1". The "non-Passive" mode must be set up (i.e. the "Passive Transfer" check box must be unchecked). After "Connect" the FTP will be connected to "192.168.136.41" with no direct network access (only via SSH connection).
- the "AUTO_CHECK_ExPortmapper=1" line can be inserted into the "[NFSSERVER]" section of the xwp.ini file to check whether an external portmapper exists to use it;
- the "FL_MITXELENA=1" line can be inserted into the "[NFSSERVER]" section of the xwp.ini file to avoid a directory permission problem for some NFS-Clients (e.g. of SCO UNIX 5.0.5).
This setting changes the default directory permission from 755 to 777.
4. NFS-Client for Windows NT4/2000/XP:
- the size of network packets can be changed instead of using the fixed value of 8K;
- the full set of settings can be saved to a file and loaded from it later;
- the package is installed with the native Installation procedure (using the "Custom" installation mode) without the necessity to deal with an additional separate executable;
- the links support was implemented (3 modes are available to do this).
- to input any text into the command line before its executing, the "$(INPUTLIP)" macros can be used. E.g., if the "Command" field contains the following line:
"xterm -display $(INPUTLIP):0" then you will be prompted to input a text string (an IP address is assumed). If you enter "220.127.116.11", then the resulting command line will be:
xterm -display 18.104.22.168:0.
- the "Telnet_SSH/SSH2 (SSH-2 Client)" Start Method is similar to other methods except for the ending of a command line. The usage of the "&" sign is not recommended because of unstable results. E.g., if you need to start "xterm" remotely, then the "xterm" command line is preferable (and the "xterm&" line is not recommended).
- the "DontUse_MOTIF_WM_HINTS=1" line can be inserted into the "[XSERVERdeb]" section of the xwp.ini file to prevent the "_MOTIF_WM_HINTS" windows property from processing;
- the "DontCheckWM_SIZE_HINTSinc=1" line can be inserted into the "[XSERVERdeb]" section of the xwp.ini file to prevent the "WM_SIZE_HINTS" windows property from processing;
- the "ILikeLINUX=1" line can be inserted into the "[XSETUP]" section of the xwp.ini file to set up the LINUX's console keyboard mapping;
- the "MyIP=?" line can be inserted into the "[network]" section of the xwp.ini file to allow the manual input of a local IP address when the XServer is started.
- to control the session's restart/completion, the "ExitOnDisconnect=..." line must be added to the "[Telnet]" section of the "xwp.ini" file. The "ExitOnDisconnect=..." setting provides the following modes:
- ExitOnDisconnect=1 - to suppress the start of a new Telnet_SSH session;
- ExitOnDisconnect=2 - to suppress the "Connection lost" message (only to write it into the telnet_s.out file);
- ExitOnDisconnect=3 - to suppress the "...open forwarded connections..." message (only to write it into the telnet_s.out file).
- the uninstallation procedure does not remove components which were installed in additional (non-first) installation sessions. Such additional components should be removed manually.
- printers on the remote MS Windows NT 4 hosts are unavailable from the local host under MS Windows NT 4.
- there may be problems on PCs with several IP addresses;
- some Linux NFS-3 Clients may issue an error message (about the wrong file ID) because of wrong packets unwrapping in the Linux's "nfs3xdr.c" module.
4. NFS-Client for Windows 9x:
- PC must be restarted after you change the license file, "xwpdllid.dll";
- can fail when connecting to an NFS server on another PC under Windows 9x if both PCs have Client/Server for Microsoft Networks installed.
- drawing partial arcs can be very slow;
- the CDE/XDMCP of the HP-UX host can provide infinite waiting for connection. To avoid this, the new "HP" fonts alias directory should be included into the XServer FontPath;
- the "Forced Backing Store" setting can provide wrong screen re-displaying in some cases (e.g., Netscape scrolling).
Single User licenses are at $100.00 USD. Please visit the Software Pricing page for pricing on Multiple Licenses.
If at anytime you require any information or assistance please do not hesitate to e-mail us at: sales@Labtam-inc.com
Download and try X-SecurePro software for FREE. (Demo version runs 60 minutes at a time.)
The programs associated in this package may send and/or receive broadcast IP requests. Since such packets cannot cross the nearest firewall/gateway/router, please be sure that these IP requests are invisible from outside your network. We assume that such behavior cannot be considered as "Hacking" or "Trojan horse's action".