Denicomp Systems

  Print This Page
 
 Shopping Cart
   HOME | CONTACT| STORE
 

Frequently Asked Questions (FAQ)

  

 

Click to read Denicomp and Windows XP Service Pack 2 FAQ


General

Ordering/Sales

Operational/Technical

 

General

What are rcp, rsh, and rexec?

These are commands commonly found on Unix systems.  They operate over a TCP/IP network and provide a convenient method of performing remote program executions and file transfers.  They are meant to be used within a network of computers where users are generally trusted, and convenience is more important than security.

rsh stands for "remote shell" and allows you to execute a non-interactive program on another system.  The remote program's standard output and standard error output will be shown on your screen.  The other system must be running a remote shell daemon (rshd) to handle the incoming rsh command.   The rsh command does not require you to enter a password for the other system.

rexec stands for "remote exec" and like rsh, allows you to execute a non-interactive program on another system.  The difference between rsh and rexec is that rexec requires you to specify a valid password for the other system and rsh does not.  The other system must be running a remote exec daemon (rexecd).

rcp stands for "remote copy" and allows you to transfer files to and from another system over the network.  It works like a "copy" command, where you specify a source and a destination, except that the source or destination of the copy can be another system.  Unlike FTP, it is totally non-interactive and does not require you to log in or specify a password for the other system.  It can also copy multiple files and recursively copy entire directory trees.   The other system must be running a remote shell daemon (rshd) that supports rcp.

What is rshd?

rshd stands for remote shell daemon.   It is a program that services the rsh command and originated on Unix systems.  It listens for connections coming from an rsh command (over TCP/IP) and when it receives a connection, it validates access, then executes the specified program.  The remote shell daemon also handles servicing the rcp command.  The remote shell daemon does not require the client to supply a password; it grants or denies access based on host equivalence; that is, a user on one system is equivalent to a user on another system and no password is necessary.   Because of this, the remote shell daemon should only be used on networks where users are generally trusted and convenience is more important than security.

What is rexecd?

rexecd stands for remote exec daemon.   It is a program that services the rexec command and originated on Unix systems.  It listens for connections coming from an rexec command (over TCP/IP) and when it receives a connection, it validates access, then executes the specified program.  Unlike the remote shell daemon, the rexec daemon requires that the client specify a valid password before access is granted, so it is a more secure than the rshd.

Is the software Year 2000 compliant?

Yes.

Which product should I get for Windows 2000 or XP?

Use Winsock RSHD/NT and Winsock REXECD/NT under Windows 2000.

Ordering/Sales

How can I order?

You can order using these methods:

  • Online via the web using your credit card. Use Visa, MasterCard, American Express, or Discover.
  • By voice through Digibuy (a service that takes credit card orders for us) using your credit card.  Fill out our online order form, then choose BY PHONE at the bottom of the form for instructions.
  • By fax through Digibuy using your credit card.  Fill out our online order form, then choose BY FAX at the bottom of the form.  It will create a fax form on the screen that you can print, fill in your credit card information, then fax to the number shown on the form.
  • By electronic transfer to our bank account.  Send us e-mail (sales@denicomp.com) for bank information.
  • By sending us a check or money order.  The check must be in US Dollars, drawn on a US Bank.

See the Ordering page for full details.

I can't use a credit card.  What's the fastest way to pay?

If you can't use a credit card, the fastest way to make payment is by electronic transfer to our bank account.  Your bank should be able to do this for you.   Send us e-mail (sales@denicomp.com) for the necessary bank information.

What do I receive?

If you request electronic distribution (no shipping charge), you will receive e-mail that provides instructions on how you can download the registered software using your web browser.  The licensed software that you can download is exactly the same as the software you would receive on a diskette if you chose a shipping option.   The manual for the software is included on the diskette, in either ASCII format (.txt), PDF, or HTML format.  You can view it on the screen or print it.  If you order via the web using your credit card, you will receive the instructions by e-mail within a few minutes after you order.

If you choose a shipping option (additional cost), you will receive a printed manual and a diskette containing the software.

Please note that for multiple license orders and Site/Corporate/Enterprise license orders, we ship only one manual and one diskette.  For example, if you purchase a 10-seat license for Winsock RCP/RSH/REXEC for Win32, we do not ship 10 manuals and 10 diskettes; we ship 1 of each.  You can then make the necessary number of copies of the diskette if you wish.

How is it shipped?  When is it shipped?  How long does it take?

Within the USA, the software is shipped by US Priority Mail unless you choose Federal Express shipping.  Priority Mail takes 2 to 3 days to arrive.  Outside the USA, the software is shipped by US Air Mail.  This generally takes 5 to 8 business days to arrive, although it can take longer due to customs clearance.  You may be responsible for customs charges.

Federal Express shipping is available in the US only.

The software is generally shipped on the day after we receive your order.  Please be aware of this if you choose Federal Express Next Day shipping.  You generally will not receive the software on the day after you order with this option - it will be two days after you order, since the software is not shipped until the next day.  The reason for this is that we usually do not receive the order notifications from Digibuy until late in the day or evening and there is not enough time to make the FedEx pickup time.

Please note that we ship all software.  If you order through Digibuy and you have not yet received your software and you think you should have by now, contact us (sales@denicomp.com), not Digibuy.   They know nothing about the shipment of the software - they simply take the orders and pass them along to us.

I need the software as soon as possible.  What is the fastest method?

If you need the software ASAP, choose electronic distribution.  This is the fastest method.  You will have the software within a few minutes after you order.

If you want a printed manual and diskette and need the software quickly, choose a shipping option and then send us e-mail and tell us you want electronic distribution also.  You can then get the software right away by downloading it, and then receive the printed manual and diskette later.

How long does it take to get the software by electronic distribution?

You will usually receive instructions for downloading the registered software within a minutes after you order.

If you ordered and requested electronic distribution and you have not received anything from us within 24 hours, please send us e-mail (sales@denicomp.com) to find out why.  We have had some orders where the customer gave an incorrect e-mail address and we could not send the instructions.

I am not in the USA; can I have it shipped by Federal Express?

Because we cannot predict customs charges, we do not ship by Federal Express to non-US locations.  Federal Express will bill us for customs charges, where US Air Mail will not.  If you need the software quickly, choose electronic distribution.  Or select a shipping option, then send us e-mail and tell us you also want electronic distribution also.   You can then start using the software without waiting for the package to arrive.

How much is maintenance?  How much are updates?

We do not charge for maintenance or updated versions of the software.  Updates are always free for registered users.  You should have received the necessary instructions and passwords for downloading the registered version of the software.   Use those instructions and passwords for downloading updated versions.

Can I purchase the software for one of my customers?  Or does my customer need to register the software directly with you?

Yes, you can purchase it on behalf of another user.  The license agreement included with the software states that you may transfer the software license to another user.

Although it is not required, you may want to include a note on your order that specifies the end user of the software if you are reselling it.  We can then note this in our records, so if we receive any requests for support or updates we know the user is a valid registered user.  We also include the licensee name on the diskette labels of diskettes we ship, so if you want some other name on the label (or no name), let us know.

Who is Digibuy?

Digibuy, a division of Digital River, Inc., is our e-commerce provider that takes credit card orders for us.   They takes orders for a number of software products in addition to ours.  Keep this in mind when ordering - they are just a service and know no technical details about the software.

Digibuy's web page is http://www.digibuy.com.

One other thing to keep in mind - we ship all software when you do not select electronic distribution.  If you order through Digibuy and you have not received your software and you think you should have by now, contact us (sales@denicomp.com), not Digibuy.   They know nothing about the status of your shipment.

Do I need to re-install the software when I purchase it?

Yes.  We do not use "unlock" codes or similar schemes.  The evaluation software is physically different than the licensed software, so you must re-install it after you receive it.  Re-installing does not change any options you have set already; it only overwrites the old files.

We do things this way for two reasons - first, using this method, the evaluation version cannot be "cracked".  Second, it allows us to insure that you get the very latest version of the software when you register.  Many support questions that we receive are due usage of older versions of the software caused by problems corrected long ago.  Requiring you to get the latest version helps reduce the time required to deal with old problems.

What is the difference between Winsock RCP/RSH/REXEC and Winsock RSHD/NT?

Winsock RCP/RSH/REXEC is client software.  It contains the rcp, rsh, and rexec commands.  These allow you to rcp, rsh, and rexec from your system to another system.  It contains executable (.exe) files, not DLL files.

Winsock RSHD/NT is server software.  It allows you to rsh and rcp into the system where it is running from another system.  It services the rsh and rcp commands; it does not include them.

These are two entirely different software packages, so be sure to choose what you need.   Some people want RSHD/NT (or RSHD/95) but see "RCP/RSH/REXEC" on the price list and think they are going to get lots more for less if they order that.   But they provide two different functions.

What is the difference between Winsock RCP/RSH/REXEC and the DLL products (RCMD32.DLL and RCP32.DLL, for example)?

Winsock RCP/RSH/REXEC contains executable (.exe) versions of the rcp, rsh, and rexec commands.  It does not include any DLL files.

Winsock RCMD32.DLL and RCP32.DLL are programming tools.  While together they provide the functionality of rcp, rsh, and rexec, you should only order the DLL products if you are planning on writing your own programs that need this functionality.  They are not meant to be stand-alone rsh, rexec, or rcp utilities (and in fact, the license agreement prohibits their use in that manner).

Some people want both RCMD32.DLL and RCP32.DLL and see "Winsock RCP/RSH/REXEC" on the price list and think they are going to get both DLL's for less if they order that product.  But they are different products.

How is Winsock RCP/RSH/REXEC licensed?

Winsock RCP/RSH/REXEC is licensed on a per seat basis.   That is, a license is required for each PC where it will be used (executed).   The license is not a concurrent use license.  This because the software generally only executes for short periods of time.

If you have a large number of PC's that need to use it, check into our Site, Corporate, or Enterprise license options.

How are the DLL products licensed?

The DLL products are licensed by developer (programmer) PC.  If you have three programmers developing products using the DLL's, you would need three licenses.

The DLL files can be distributed royalty-free with your application.   That is, you do not need a license for the end users of your application that uses the DLL products.

There is a clause in the DLL license agreement that you should be aware of.  It states that you may not use the DLL's in your software application if:

  • the only purpose of your application is to provide a command line or screen interface into the functions in the DLL.  That is, you cannot use the DLL to create a software product where its sole purpose is to do an rsh, rexec, or rcp.
  • the application you are creating is a programming tool that provides the end user with the ability to programmaticaly use the DLL by passing it parameters

Using the DLL in either of these ways is a violation of the license agreement.   You would be required to license the DLL(s) for each end user for the above two cases.

Can I distribute the DLL products with my application?

Yes, you can distribute the RCMD.DLL, RCP.DLL, RCMD32.DLL, and RCP32.DLL files (depending on which you have licensed) with your software product.  They can be distributed royalty-free with your application; you do not need to license them for each end user.

However, there is a clause in the DLL license agreement that you should be aware of.   It states that you may not use the DLL's in your software application if:

  • the only purpose of your application is to provide a command line or screen interface into the functions in the DLL.  That is, you cannot use the DLL to create a software product where its sole purpose is to do an rsh, rexec, or rcp.
  • the application you are creating is a programming tool that provides the end user with the ability to programmaticaly use the DLL by passing it parameters

Using the DLL in either of these ways is a violation of the license agreement.   You would be required to license the DLL(s) for each end user for the above two cases.

Operational/Technical

Why don't I see any mapped drives or get errors using mapped drives in RSHD/NT?

Because of differences between Unix (where rshd originated) and Windows, RSHD/NT does not actually log in as the same user account used on the rsh client. This is because Windows requires a password to impersonate a user, unlike Unix where a priviliged process can impersonate another user without a password.  Since rsh does not ask for a password, RSHD/NT cannot supply it to Windows to impersonate the rsh user.

By default, RSHD/NT runs all commands as the special Windows user SYSTEM (also called LocalSystem or the "System Account"). However, the SYSTEM user does not have access to network resources, which is why you cannot access the network share. If you need access to network resources, you must run the RSHD/NT service as a user who has access to them.

You can accomplish this in three ways.  The first way is to use the User Equivalency table in RSHD/NT to equate a remote user with a Windows user/password.  Another way is by either entering a user and password for the RSH User and RCP User in the RSHD Control Panel applet or you can change the service startup to run the service as a non-SYSTEM user.  See the RSHD/NT reference manual for more details.

Keep in mind that even when doing this, mapped drive letters will not be available to RSHD/NT because Windows does not establish the mapped drive letters for services.  There are reasons for this - Windows is not a multi-user system in the classic sense, especially when it comes to drive letters.  Drive letters are global on an Windows system.  That is, one process cannot map N: to one share and another process map N: to a different share.  All processes see N: as being mapped to the same share once it is mapped.  However, only the login session that created the map can access the mapped drive. (Note: This is not true with Windows XP.  With XP, each login session gets its own set of drive letters.)

This is important to understand.  If the interactive user on the Windows console logs in and creates a mapped drive "N:", processes executed through RSHD/NT will see N: as mapped, but they will not be able to use it.  This is because processes executed through RSHD/NT run in a different login session than the interactive user who created the map.

RSHD/NT allows you to create a file (AUTOMAP.INI) so that you can establish mapped drives for using by programs executed through RSHD/NT, but you must take care that they never conflict with the interactive user ( again, except for Windows XP).  There are also problems with multiple rsh commands executing simultaneously trying to use the same mapped drive.  That will not work because each rsh executes within its own login session.

The only foolproof way of  accessing network resources through RSHD/NT is to use Universal Naming Convention (UNC) path names.  That is, instead of mapping N: to \\server\share, then accessing N:\dir\file, just use \\server\share\dir\file.  No mapped drive letter is necessary and there will be no conflicts.

There are additional details in the RSHD/NT reference manual on using mapped drives through RSHD/NT, so look there for more information and possible solutions.

I specified a Security File in the RSHD/NT (or REXECD/NT or RSHD/95) Control Panel applet and I should be given access, but it denies access to me. What is happening?

Assuming that you really have set up the security file so that you should be given access, it could also be:

  • You misspelled the name of the security file in the Control Panel.
  • You placed the security file on a network drive. It must be on a local drive (i.e. C:).
  • You did not save the file as an ASCII text file.  It must be pure ASCII (not Unicode or any other format).

If you specify a security file name in RSHD/NT's Control Panel applet and RSHD/NT cannot find or access the file, it denies all users access as a security measure.

If you still cannot figure out why it won't grant access, use the RSHD Control Panel applet and enter a filename in the Message File field and enter a 4 in the Message Level field.  Then issue a command that should work, then view the Message File.  It will contain a trace showing what it is looking for (and finding) in the security file.

My program is not working when I run it through RSHD/NT (or REXECD/NT), but it works when I log into the system and run it interactively.  Why isn't it working?

One possible reason is that the program needs to access a network resource, such as a networked drive, printer, or other object, such as a database. If you are running the RSHD/NT Service as the default System user and have not specified an alternate user/password for rsh commands in the RSHD/NT Control Panel, programs run through rsh will not have access to any network resources. Windows does not allow the System user to have access to the network. See the previous question and the section on RSHD/NT and Windows Security for more details.

Why does it sometimes take a few seconds for RSHD/NT to execute a program from an rsh or to copy a file from an rcp command?

This could be due to one of two things. First, it could be due to a slow or inaccessible DNS server if you are using DNS. If you enter a filename in the Security File, Message Log, Request Log, Deny Log, or Error Log fields in the RSHD/NT Control Panel applet, RSHD/NT will attempt to obtain a hostname for the client based on its IP address. If you have specified DNS server(s) in your TCP/IP setup, it will attempt to use them to obtain the hostname. Otherwise, it will use the HOSTS file (e.g. c:\winnt\system32\drivers\etc\hosts).

If the DNS server is down, inaccessible, or simply does not know a hostname for the client's IP address, there could be a long delay before this is determined. If this is the case, there are a few things you can do to resolve the problem:

  • Correct the problem with the DNS server.
  • Enter hostnames and IP addresses of the client systems in the HOSTS file
  • Clear the filenames in the Security File, Message Log, Request Log, Deny Log, and Error Log fields
  • If you need the Security File and logs, create the following registry entry using REGEDIT:

    HKEY_LOCAL_MACHINE\SOFTWARE\DenicompSystems\WRSHDNT\Setup\DisableHostLookup

Create this as a new String Value and set it to a value of "1". This will disable the look up of the client's hostname. However, you will then only see IP addresses in the logs and you may only use IP addresses (no hostnames) in the Security File when this is set to 1.

The second possible cause is not as simple to explain. It is due to a missing "feature" in the Windows TCP/IP implementation.

NOTE: The explanation below applies to Windows NT 3.51 and 4.0 without Service Pack 6 installed.  It appears that Service Pack 6 (SP6) for Windows NT 4.0 has corrected this delay issue in TCP/IP.  It also appears to be OK in Windows 2000.

Often, your first rsh/rcp will be fast, then subsequent commands will be delayed by a few seconds. This delay is not caused by RSHD/NT. It takes NT a few seconds at times to notify RSHD/NT that there is a connection waiting. RSHD/NT processes the request very quickly once it is notified.

To illustrate this, restart your NT system, then issue an rsh command from another system to the NT system. It will be quick. Then immediately issue another rsh; it will be delayed by a few seconds.

The root of this problem can be explained somewhat, although technical. After you issue the first rsh, the TCP/IP connection (a "socket") is closed and it goes into the TIME_WAIT state, which is normal. You can see this by typing the netstat command on the NT system after you do an rsh to it.

As long as there are closed sockets in the TIME_WAIT state which were created by RSHD/NT, you will experience the delay. It takes up to four minutes (a TCP/IP constant) for them to go out of the TIME_WAIT state. Once they do, the next rsh from the same client will be quick. Then the cycle repeats; you need to wait another four minutes for it to be quick again.

The reason for this is that the NT TCP/IP stack is strictly RFC compliant regarding the TIME_WAIT socket state. Most UNIX TCP/IP stacks, which are derived from BSD, have a non-standard-extension dealing with the TIME_WAIT state and new connections.

BSD-derived stacks allow a new connection request to arrive for a connection that is in the TIME_WAIT state if the new sequence number is greater than the final sequence number from the previous incarnation of the connection. Usually the sequence number for the new incarnation is set to the final sequence number from the previous incarnation plus 128,000.

This feature allows a client and server continually reuse the same port number at each end for successive incarnations of the same connection, but only if the server does the active close, which is always the case with an rshd (or rexecd).

NT's TCP/IP stack does not support this feature and this causes the delay sometimes experienced. The delay is at the TCP/IP stack level and not in Winsock RSHD/NT, so there is no work-around that we can employ to resolve it. It would require a change to NT's TCP/IP stack.

Since it only occurs on subsequent rsh/rcp commands during the TIME_WAIT interval, which is four (4) minutes by default under NT, as long as there are at least four minutes between each rsh/rcp from the same client, the delay will not occur. You can also lessen its effect by changing an NT registry option that allows you to reduce the TIME_WAIT interval from the standard four minutes down to 30 seconds. This registry entry is:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\tcpip\Parameters\TcpTimedWaitDelay

Create this entry as a new DWORD item (or edit if it already exists). Set it to any value between 30 and 300, which represents the number of seconds. The default is 240 (4 minutes). The smallest value allowed is 30 (seconds). You must restart Windows NT after adding/changing this entry for it to take effect.

So, if you set this entry to 30, as long as there are at least 30 seconds between each rsh/rexec from the same client, you will not experience the delay.  You can also try installing NT 4.0 Service Pack 6 and that should help.

When I try to link my Visual C++ program, it can't find RCMD32.DLL or RCP32.DLL functions even though I am linking in the .LIB file.  Why?

The rcmd32.h and rcp32.h files are C header files with C declarations, not C++.   To use them in a C++ programs, you need to prefix them with extern "C".  For example:

extern "C" {
#include "rcmd32.h"   (or #include "rcp32.h")
}

I tried to rsh or rcp to another system and it says "connection refused".   What does that mean?

The "connection refused" error is a TCP/IP error that means that nothing is "listening" on the other end of the connection.  For rsh and rcp, it means that no remote shell daemon (rshd) is running on the system you have specified.

If the system is a Unix system, it could mean that the rshd has been disabled in the /etc/inetd.conf file.  Sometimes this is done for security reasons by a system administrator.

If the system is a Windows system, be aware that no version of Windows includes a remote shell daemon.  You would need to run a third-party rshd on that system, such as our Winsock RSHD/95 or RSHD/NT.

If you have installed Winsock RSHD/95 or Winsock RSHD/NT, perhaps it is not started or there is some TCP/IP configuration issue that is not allowing it to start.  Or you could be specifying an incorrect hostname or IP address in your command.  Ping the hostname you are using and record the IP address.  Then go to the Windows system and run this command at a command prompt:  (Windows NT/2000/XP):  ipconfig  (Windows 95/98/ME): winipcfg

See if the IP address shown reflects the same address displayed when you ping'ed the hostname.

I am trying to use RCP32.DLL to transfer files to my Windows server, but I am receiving errors.  Why?  It is running an FTP server.

Winsock RCP32.DLL uses the rcp protocol, which is completely different than and incompatible with the ftp protocol.  You must run our Winsock RSHD/NT on the Windows system in order to use RCP32.DLL to send or receive files from that Windows system.

Does RSHD/95 work under Windows 98 or Windows ME?

Yes.

Does RSHD/95 work under Windows NT/2000/XP?

No.  It may run and work properly for many things, but ideally you should use Winsock RSHD/NT.  RSHD/95 will require you to log in to Windows in order to run it and Windows will kill it when you log off.  RSHD/NT runs constantly in the background (as a service) even when no one is logged on to Windows.

Does RSHD/NT work under Windows 95/98/ME?

No.  It runs as a Windows service.  Windows 95/98/ME does not support Windows services.  There are also other internal differences that will not work under 95/98/ME.

I am using a firewall.  What ports do rsh, rcp, and rexec use?

rsh uses port 514.  rcp executes through an rsh connection, so it also uses port 514.  rexec uses port 512.  rsh and rexec also use a secondary port for standard error output.  This port number is dynamically assigned.  For rsh, it is a port number between 515 and 1023 (it starts with 1023 and probes downward until it finds an unused port).  For rexec, the port is a random port numbered 1024 and above.

You cannot predict which port number it will use.  With light rsh usage, you can be fairly safe in allowing something like ports 1000 through 1023 or a smaller range (ending with 1023 always).

You can use the -c option on our rsh and rexec commands in our Winsock RCP/RSH/REXEC for Win32 package to combine stderr onto stdout and avoid the use of the secondary connection.  The 16-bit RCP/RSH/REXEC and RCMD32.DLL do not use the secondary connection at all at this time.

Please don't complain to us about this - we didn't design the protocol!

Rsh is not working - could it be because I am using NAT?

Yes.  When you rsh (or rexec) to a host system, the rsh/rexec command then listens for a connection to come back from the host system to the client for standard error output.  So the host system must be able to connect back to the client system using the client's IP address.  If the host cannot connect to your system by its IP address, rsh/rexec will not work.

You can try using the -c option of our rsh or rexec in our Winsock RCP/RSH/REXEC for Win32 package.  This combines stderr onto stdout and avoids the secondary connection, so the host does not need to connect back to the client.

When I rsh/rcp to my Unix host, I receive a "Login incorrect" error.   Why?

The user login name being sent to the host is not a valid user on the host.  Our rsh and rcp uses the following steps to obtain a user name to use at the host:

  1. If a user is specified on the command line (-l option in rsh, user@host in rcp), that is used.
  2. If no user is specified on the command line, it looks at the user specified in the R-Commands Control Panel applet (32-bit).
  3. If no user is found there, it converts the current Windows user to lowercase and uses that.

If you are not sure what user login is being used, enter a Trace Output Level of 1 in the R-Commands Control Panel applet and enter a filename in the Trace Output File field.  Then issue an rsh or rcp command, then look at the trace file.   It will show you what user is being transmitted to the host.

When I rsh/rcp to my Unix host, I receive a "Permission denied" error.   Why?

This is an error that is being relayed back to you from the Unix system.  The problem is a setup issue on the Unix system.  Most likely, it is because:

  1. Your PC's hostname does not appear in the /etc/hosts.equiv file or the .rhosts file in the user's home directory.
  2. The Unix system does not know a name for your PC's IP address.  Add your PC's IP address and name to /etc/hosts.
  3. You are using the .rhosts file and the .rhosts file does not have permissions of 0600 and is not owned by the user or by root.  The Unix rshd requires this.
  4. The user's home directory is inaccessible or missing.
  5. You are trying to rsh/rcp as root and you have not set up the /.rhosts file.  The Unix rshd does not use /etc/hosts.equiv when you rsh/rcp as root.  It only uses /.rhosts for root.  Also be sure that /.rhosts has permissions of 0600 and is owned by root.

For more details about what Unix requires to allow a connection, type "man rshd" at a Unix prompt.

When I rsh/rcp to my Unix host, I receive a "Hostname unknown for your address" error.  Why?

The Unix system cannot find a hostname associated with your IP address.  If you are using a DNS server, your PC's IP address must be added to the DNS server's database.   If you are not using DNS, you can add your PC's hostname to the /etc/hosts file on the Unix system.

The Unix rshd requires that it be able to find a hostname for your IP address; this is not one of our requirements.  If you get a different IP address each time you boot your PC, you will have to enter every possible IP address you can get along with a hostname in /etc/hosts.  If you are connected through an ISP and you are assigned a different IP address each time you connect, you will need to set up your Unix system to use DNS and hope that your ISP has registered names for each IP address he assigns to connections so Unix can find a name for you.  Or you can get a fixed IP address from your ISP (usually an additional cost).

There is no way around this requirement; all Unix rshd's are like this.

When I rsh/rcp to my Unix host as root, I receive "Permission denied".   I can do it as another user and /etc/hosts.equiv is set up properly.  Why doesn't it work as root?

The Unix rshd does not use /etc/hosts.equiv for connections as root.  It only uses /.rhosts.  Add your system's hostname to /.rhosts on the Unxi system.  Also be sure that /.rhosts has permissions of 0600 and is owned by root

I want to start a program on a Unix system with rsh, but I don't want rsh to wait for it to complete.  I have ended the command with "&", but rsh still waits until it ends.  How can I do this?

The Unix rshd keeps the connection open as long as stdout, stderr, or stdin are still open.  You must redirect them to /dev/null to close them so rshd will release the connection.

If you are using the Bourne shell or Korn shell, use something like:

   rsh host "your_command ..... </dev/null >/dev/null 2>&1  &"

If you are using the C-Shell, use something like:

   rsh host "your_command .... </dev/null >&/dev/null   &"

This redirects stdin, stdout, and stderr to /dev/null.  Of course, you can redirect them to or from files if necessary also.  Be each must be redirected somehow.

When I run a program on an Windows system running your RSHD/REXECD, the rsh/rexec does not end until the program ends.  I don't want the rsh/rexec command to wait for the program to end.   Can I do this?

Yes.  By default, RSHD and REXECD attempt to redirect the stdin, stdout, and stderr of the program executed.  In order to do this, it must keep the rsh/rexec connection opened for the duration of the program's execution.  If you don't want rsh/rexec to wait for the command to end, use one of these methods:

  • If you only occasionally want to do execute a program without waiting for it to end (you usually want to redirect stdin, stdout, and stderr over the connection), add the "<[WIN]>" directive to your rsh/rexec command.  For example:

        rsh host "<[WIN]>" notepad

         This disables the standard I/O redirection for this command only.

  • If you usually do not want to wait for programs to complete, uncheck the option labeld Attempt Redirection on Every Command? in the RSHD (or REXECD) Control Panel applet.   This disables standard I/O redirection for all rsh (or rexec) commands, and therefore it will not wait for them to end.  Should you want to do standard I/O redirection for a program, add the "<[CON]>" directive to your rsh/rexec command.  For example:

        rsh host "<[CON]>" dir

        This enables standard I/O redirection for this command only.

How do I do an REXEC using RCMD.DLL or RCMD32.DLL?

To use RCMD.DLL/RCMD32.DLL to rexec, use a port number of 512 for the Port parameter and pass the user in the LocalUser (3rd) parameter and pass the user's password in the RemoteUser (4th) parameter.

What is the difference between REXEC and RSH?

The rexec protocol requires you to specify a password for the user on the host system; rsh does not.  Security is enforced in a different method on the host for rsh.   Other than this, they are very much the same.

Why would I want to use RCP instead of FTP to transfer files?

RCP has a few potential advantages over FTP.  First, it does not require you to specify (or store) a password for the host system.  Second, it is non-interactive and entirely command-line driven, which makes it easier to use in shell scripts and batch files.  Third, it allows you to copy multiple files (using wildcards or a list of filenames on the command line) or recursively copy entire directory trees.

How do I uninstall Winsock RSHD/95?

Use Add/Remove Programs in the Control Panel to remove RSHD/95.   If for some reason RSHD/95 does not appear there, use the following steps:

  1. Stop RSHD/95 using the RSHD Control Panel applet's Service Control Button.  In the Service Control window, click on the Stop button, then the Remove button.  Then close the Service Control window and Control Panel.
  2. Delete the RSHD/95 installation directory (usually c:\wrshd95).
  3. Delete the file wrshd95.cpl in the Windows System directory (usually c:\windows\system)

How do I uninstall Winsock RSHD/NT?

Use Add/Remove Programs in the Control Panel to remove RSHD/NT.   If for some reason RSHD/NT does not appear there, use the following steps:

  1. Stop RSHD/NT using the RSHD Control Panel applet's Service Control Button.  In the Service Control window, click on the Stop button, then the Remove button.  Then close the Service Control window and Control Panel.
  2. Delete the RSHD/NT installation directory (usually c:\wrshdnt).
  3. Delete the file wrshdnt.cpl if it exists in the Windows System directory (usually c:\winnt\system32)

How do I uninstall Winsock REXECD/NT?

Use Add/Remove Programs in the Control Panel to remove REXECD/NT.   If for some reason REXECD/NT does not appear there, use the following steps:

  1. Stop REXECD/NT using the REXECD Control Panel applet's Service Control Button.  In the Service Control window, click on the Stop button, then the Remove button.  Then close the Service Control window and Control Panel.
  2. Delete the REXECD/NT installation directory (usually c:\wrexecnt).
  3. Delete the file wrexecnt.cpl if it exists in the Windows System directory (usually c:\winnt\system32)

Will Winsock RSHD/NT and REXECD/NT work under Windows 2000? Windows XP?

Yes and Yes.

How do I find out what version of RSHD/NT I am running?

Starting with version 2.20, use the RSHD Control Panel applet and look on the Service Control tab for the version.

If you do not have a Service Control tab, Get to a Command Prompt, CD to the RSHD/NT installation directory (usually C:\WRSHDNT) and type:

wrshdnt /v

This will display the version number.  Also, starting with version 2.18, you can use Windows Explorer and right click the wrshdnt.exe file in the RSHD/NT installation directory and choose Properties.  The version will display on the Version tab.

How do I find out what version of REXECD/NT I am running?

Starting with version 2.20, use the REXECD Control Panel applet and look on the Service Control tab for the version.

If you do not have a Service Control tab, get to a Command Prompt, CD to the REXECD/NT installation directory (usually C:\WREXECNT) and type:

wrexecnt /v

This will display the version number.  Also, starting with version 1.05, you can use Windows Explorer and right click the wrexecnt.exe file in the REXECD/NT installation directory and choose Properties.  The version will display on the Version tab.

How do I find out what version of RCP/RSH/REXEC for Win32 I am running?

Get to a Command Prompt, CD to the RCP/RSH/REXEC for Win32 installation directory (usually C:\RCPRSH32, but you do not need to CD if it is in your PATH).  Then type:

rsh -v

This will display the version number.  You can do this with the rcp and rexec commands also - they will all display the same version number.  If you receive an error message, you are executing the Windows NT/2000 version of rsh, rcp, or rexec instead of ours.

 

Home | Contact | Store | Copyright © 2003 Denicomp Systems. All Rights Reserved.