![[Contents]](icons/contents.gif){kind=icon}
![[Index]](icons/index.gif){kind=icon}
![[Prev]](icons/prev.gif){kind=icon}
![[Next]](icons/next.gif){kind=icon}
This chapter discusses the applications that provide remote network access. VxWorks supports the following:1
VxWorks provides an implementation of the client side (but not the server side) of the RSH protocol. VxWorks also provides an implementation of both the client and the server sides of the FTP protocol.
Using RSH, a VxWorks application can run commands on a remote system and receive the command results on standard output and standard error over socket connections. To execute commands remotely, RSH requires that the remote system supports the server side of RSH and that the remote system grant access privileges to the user specified in the RSH request. On a UNIX system, RSH server support is implemented using the rshd shell daemon, and access privileges are controlled by a .rhosts file. On a VxWorks host, there is no equivalent to rshd. Thus, remote systems cannot use RSH to run commands on a VxWorks host.
You can use both RSH and FTP directly, but you can also use them indirectly to download files through the mediation of the netDrv library. Using netDrv in this way is especially convenient when a target needs to download a run-time image at boot time.
That netDrv can use FTP to download a file is not surprising, given that FTP is a protocol designed specifically for file transfer. Specifically, netDrv uses the FTP RETR and STOR commands to retrieve and store the entire requested file. That netDrv can use RSH to download a file is less obvious. RSH has no built-in commands dedicated to file transfer. However, netDrv executes a remote cat on the file it wants to download.
All FTP and RSH requests to a remote system include the user name. All FTP requests include a password as well as a user name. From VxWorks, you can specify the user name and password for remote requests by calling iam( ):
iam ("username", "password")
The first argument to iam( ) is the user name that identifies you when you access remote systems. The second argument is the FTP password. This is ignored if RSH is being used, and can be specified as NULL or 0 (zero).
For example, the following command tells VxWorks that all accesses to remote systems with RSH or FTP are through user darger, and if FTP is used, the password is unreal:
-> iam "darger", "unreal"
For a VxWorks system to have access to a particular file on a host, you must set up permissions on the host system appropriately. The user name seen from the host must have permission to read that file (and write it, if necessary). That user name must also have permission to access all directories in the path. The easiest way to check this is to log in to the host with the user name VxWorks uses, and try to read or write the file in question. If you cannot do this, neither can the VxWorks system.
Using the VxWorks RSH implementation, a VxWorks target can execute commands on remote systems that run an rshd shell daemon. The command results return on standard output and standard error over socket connections.
|
|||||||||||||||||||
Included in an RSH request is the name of the requesting user. The receiving host can then honor or ignore the request based on the user name and the site from which the request originates. How you set up a receiving system to allow access to particular users and sites depends on the specifics of the receiving system's OS and networking software.
For Windows hosts, support for RSH is determined by your version of Windows and the networking software you are using. See that documentation for details.
For UNIX hosts, an RSH request is honored only if it originated on a known system by a user with local login privileges. The list of known systems is specified in either of two locations. The first location, the /etc/hosts.equiv file, maintains a list of all systems from which remote access is allowed for all users that have local accounts. The second location, a ~userName/.rhosts file, maintains a list of systems from which remote access is allowed for that particular user, userName.
Which location you use depends on your security needs. In most environments, adding system names to the /etc/hosts.equiv file is considered too dangerous. Thus, for most environments, the preferred method is to add system names to a ~userName/.rhosts file. The format for this file is one system name per line.
The FTP protocol, unlike RSH, specifies both the user name and password on every request. Therefore, when using FTP, the UNIX system does not use the .rhosts or /etc/hosts.equiv files to authorize remote access.
|
|
|||||||||||||||||||
Although you can use netDrv at boot time to download a run-time image, netDrv is not limited to boot time or run-time images. It is a generic I/O device that you can use to access files on a remote networks system. To include netDrv in VxWorks, use the configuration component:
INCLUDE_NET_DRV -- netDrv I/O library for accessing files on a remote host
To use netDrv, you must create a netDrv device for each system on which you want to access files. You can then use this device in standard VxWorks I/O device calls such as open( ), read( ), write( ), and close( ). To create a netDrv device, call netDevCreate( ):
netDevCreate ("devName", "host", protocol)
For example, the following call creates a new I/O device on VxWorks called mars:, which accesses files on the host system mars using RSH:
-> netDevCreate "mars:", "mars", 0
After a network device is created, files on that host are accessible by appending the host pathname to the device name. For example, the filename mars:/usr/darger/myfile refers to the file /usr/darger/myfile on the mars system. You can read or write to this file as if it were a local file. For example, the following Tornado shell command opens that file for I/O access:
-> fd = open ("mars:/usr/darger/myfile", 2)
The usrNetInit( ) call in a VxWorks boot program can automatically create a netDrv instance for the host name specified in the VxWorks boot parameters. The boot program then uses this device to download an image from the host specified in the boot parameters. Whether the netDrv instance uses FTP or RSH to download the image depends on whether the boot parameters include an FTP password. When the FTP password is present, netDrv uses FTP. Otherwise, netDrv uses RSH.2
For most single-processor stand-alone VxWorks targets, using FTP or RSH to download an image is useful while developing an application but rare in the deployed system. However, for devices that consist of multiple VxWorks targets linked together by a shared memory backplane, using FTP to download run-time images from a central server CPU to its client CPUs is convenient and common. As the clients on the backplane boot, they create instances of netDrv that they then use to download their run-time images from the server.
Consider the system shown in Figure 8-1. Using the shared memory backplane, CPU 1 can use FTP to download its run-time image from the storage device (in this case, a SCSI disk) accessible through CPU 0. Note that the client must include a non-empty ftp password field in its boot parameter:
boot device : sm=0x800000
processor number : 1
host name : vxServer
file name : /sd0/vx2
inet on backplane (b) : 161.27.0.2
host inet (h) : 161.27.0.1
user (u) : caraboo
ftp password (pw) (blank=use rsh) : ignored
Including an FTP password tells netDrv to use FTP. Whether the FTP server on CPU 0 checks the validity of the password depends on whether the FTP server on CPU 0 has been configured with security turned off (the default) or on. The relevant configuration parameter is INCLUDE_FTPD_SECURITY.
The FTP server daemon is initialized on the VxWorks server based on the configuration. The relevant configuration parameter is INCLUDE_FTP_SERVER. See also the reference entry for ftpdLib.
The VxWorks NFS implementation supports both the client and server side of the protocol. The relevant configuration components are:
To mount a remote file system on a VxWorks host, you must make sure that the remote system runs an NFS server and that the remote directory has been made available for export to your client. Then, on the target running a VxWorks NFS client, you must set your NFS client name, user ID, and group ID. Finally, you can call nfsMount( ), which creates an nfsDrv instance that mounts and manages the mounted remote file system.
For a UNIX NFS server, the /etc/exports file specifies which of the server's file systems are exported for mounting by remote NFS clients. For example, if /etc/exports contains the line:
/usr
The server exports /usr without restriction. If you want to limit access to this directory, you can include additional parameters on the line. For more information on these parameters, consult your UNIX system documentation. If a file system on a UNIX NFS server is not listed in /etc/exports, the file system is not exported, which means other machines cannot use NFS to mount it.
Windows systems also support NFS. Thus, it is possible to configure a directory on a Windows system so that it is exported over NFS. However, the exact procedures for doing so depend upon the particular network package you purchased. For more information, consult the documentation included with your Windows networking package.
Internally, NFS depends upon RPC to handle the remote execution of the commands (open, read, write, and others) that access the data in the remote file system. Associated with the RPC protocol is an authentication system known as AUTH_UNIX. This authentication system requires RPC peers to provide a user name, a user ID, and a group name. The recipient of an RPC message uses this information to decide whether to honor or ignore the RPC request.
On a VxWorks host, you can set the NFS user name, user ID, and group name using the NFS_CLIENT_NAME, NFS_GROUP_ID, and NFS_USER_ID parameters included in the INCLUDE_NFS configuration component. You can also set these values by calling nfsAuthUnixSet( ) or nfsAuthUnixPrompt( ). For example, to use nfsAuthUnixSet( ) to set the NFS user ID to 1000 and the NFS group ID to 200 for the machine mars, you would call nfsAuthUnixSet( ) as follows:
-> nfsAuthUnixSet "mars", 1000, 200, 0
The nfsAuthUnixPrompt( ) routine provides a more interactive way of setting the NFS authentication parameters from the Tornado shell.
On UNIX systems, a user ID is specified in the file /etc/passwd. A list of groups that a user belongs to is specified in the file /etc/group. To configure a default user ID and group ID, set NFS_USER_ID and NFS_GROUP_ID. The NFS authentication parameters will take on these values at system startup. If NFS file access is unsuccessful, make sure that the configuration is correct.
After setting your NFS client name, user ID, and group ID, you are ready to call nfsMount( ) to mount any file system exported by a known host. To add a system to the list of hosts known to a VxWorks system, call hostAdd( ):
hostAdd ("host", "IPaddress" )
This function associates a host name with an IP address. Thus, if you wanted to mount a file system exported by a system called "mars," you would need to have already called hostAdd( ) for "mars." For, example, if "mars" were at 150.12.0.1, you would need to call hostAdd( ) as follows:
hostAdd ("mars", "150.12.0.1" )
If "mars" exports a file system called /usr, you can now use a call to nfsMount( ) to create a local mount of that remotely exported file system. The syntax of an nfsMount( ) call is as follows:
nfsMount ("hostName", "hostFileSys", "localName")
-> nfsMount "mars", "/usr", "/vwusr"
If the call above completes successfully, it creates a local I/O device called /vwusr. This device refers to the mounted file system. You can open, read, write, and close /vwusr just like any other VxWorks I/O device. Further, a reference on the VxWorks target to a file with the name /vwusr/darger/myfile refers to the file /usr/darger/myfile on the host mars as if it were local to the VxWorks system.
If you do not need to mount the remote file system under a new name, you should consider using nfsMountAll( ) instead of nfsMount( ). A call to nfsMountAll( ) mounts all file systems that are exported from the remote system and that are accessible to the specified client. The syntax of nfsMountAll( ) is as follows:
nfsMountAll( "hostName", "clientName", quietFlag )
To include the VxWorks NFS server in an image, use the configuration component INCLUDE_NFS_SERVER. Using the VxWorks NFS server, it is possible for a VxWorks target to act as a file server for any system that runs an NFS client. Consistent with the NFS protocol, the VxWorks NFS server exports only those file systems explicitly marked for NFS export. Under VxWorks, preparing a file system for export is a two step procedure. First, when you initialize the file system, you must initialize it to allow NFS export. Then you must register the file system with the NFS server by calling nfsExport( ).
On a VxWorks target, you can export a file system over NFS only if you have initialized that file system. The following steps initialize a DOS file system called /goodstuff on a SCSI drive. You can use any block device instead of SCSI. Your BSP can also support other suitable device drivers; see your BSP's documentation.
For example, you can use a SCSI drive as follows:
scsiAutoConfig (NULL);
pPhysDev = scsiPhysDevIdGet (NULL, 1, 0);
pBlkDev = scsiBlkDevCreate (pPhysDev, 0, 0);
Calling scsiAutoConfig( ) configures all SCSI devices connected to the default system controller. (Real applications often use scsiPhysDevCreate( ) instead, to specify an explicit configuration for particular devices.) The scsiPhysDevIdGet( ) call identifies the SCSI drive by specifying the SCSI controller (NULL specifies the default controller), the bus ID (1), and the Logical Unit Number (0). The call to scsiBlkDevCreate( ) initializes the data structures to manage that particular drive.
dosFsDevInit ("/goodstuff", pBlkDev, NULL);
|
|||||||||||||||||||
After you have an exportable file system, call nfsExport( ) to make it available to NFS clients on your network. Then mount the file system from the remote NFS client, using the facilities of that system. The following example shows how to export the new file system from a VxWorks platform called vxTarget, and how to mount it from a typical UNIX system.
nfsExport ("/goodstuff", 0, FALSE, 0);
The first three arguments specify the name of the file system to export; the VxWorks NFS export ID (0 means to assign one automatically); and whether to export the file system as read-only. The last argument is a placeholder for future extensions.
|
|
|||||||||||||||||||
When exporting dosFs file systems that do not provide file permissions, the VxWorks NFS Server does not normally provide authentication services for NFS requests. To authenticate incoming requests, write your own authentication functions and arrange to call them when needed. See the reference entries for nfsdInit( ) and mountdInit( ) for information on authorization hooks.
The Trivial File Transfer Protocol (TFTP) is implemented on top of the Internet User Datagram Protocol (UDP) and conforms to the RFC 1350 recommendations for packet format. VxWorks provides both a TFTP client and a TFTP server. The TFTP client is useful at boot time, when you can use it to download a VxWorks image from the boot host. The TFTP server is useful if you want to boot an X-Terminal from VxWorks. It is also useful if you want to boot another VxWorks system from a local disk.
To include the VxWorks TFTP client or server, use the following configuration components:
Typically, the host-resident Internet daemon starts the TFTP server. For added security, some hosts (for example, Sun hosts) default to starting the TFTP server with the secure (-s) option enabled. If -s is specified, the server restricts host access by limiting all TFTP requests to the specified directory (for example, /tftpboot).
For example, if the secure option was set with -s /tftpboot, a TFTP request for the file /vxBoot/vxWorks is satisfied by the file /tftpboot/vxBoot/vxWorks rather than the expected file /vxBoot/vxWorks.
To disable the secure option on the TFTP server, edit /etc/inetd.conf and remove the -s option from the tftpd entry.
Include the VxWorks TFTP client side by reconfiguring VxWorks. The relevant configuration parameter is INCLUDE_TFTP_CLIENT. To boot using TFTP, specify 0x80 in the boot flags parameters. To transfer files from the TFTP host and the VxWorks client, two high-level interfaces are provided, tftpXfer( ) and tftpCopy( ). See the reference entry for tftpLib.
The Remote Procedure Call (RPC) protocol implements a client-server model of task interaction. In this model, client tasks request services of server tasks and then wait for replies. RPC formalizes this model and provides a standard protocol for passing requests and returning replies.
Internally, RPC uses sockets as the underlying communication mechanism. RPC, in turn, is used in the implementation of several higher-level facilities, including the Network File System (NFS) and remote source-level debugging. In addition, RPC includes utilities to help generate the client interface routines and the server skeleton.
The VxWorks implementation of RPC is task-specific. Each task must call rpcTaskInit( ) before making any RPC-related calls.
The VxWorks RPC implementation is based on a public domain implementation that originated at Sun Microsystems. RPC is equivalent to the Open Networking Computing (ONC) RPC standard. For more information, see the public domain RPC documentation and the reference entry for rpcLib.
To include VxWorks RPC, use the INCLUDE_RPC configuration component.
You can log in to a host system from a VxWorks terminal using rlogin( ). For more information on the VxWorks implementation of rlogin( ), see the reference entry for rlogLib. To include VxWorks rlogin( ) in an image, use the INCLUDE_RLOGIN configuration component.
When connecting with a Windows host system, VxWorks's ability to remotely login depends on your version of Windows and the networking software you are using. See that documentation for details.
When connecting with a UNIX host system, access permission must be granted to the VxWorks system by entering its system name either in the .rhosts file (in your home directory) or in the /etc/hosts.equiv file. For more information, see Configuring the Remote Host to Allow Access to an RSH User, p.162.
Like rlogin, telnet is another remote login utility. However, telnet does not require any previous setup of a .rhosts file or its equivalent under non-UNIX systems, but it does require that the remote system is configured to grant login privileges to the user specified for a telnet session.
For more information on how to use the telnet server with a VxWorks target, see the reference entry for telnetdLib.
|
|
|||||||||||||||||||
STATUS shellParserControl
(
int remoteEvent, /* Starting or stopping a connection? */
UINT32 sessionId, /* Unique identifier for each session */
int * pInFd, /* Input to command interpreter (written by socket) */
int * pOutFd /* Output from command interpreter (read by socket) */
)
The internal (not printed) reference entry for shellParserControl( ) is as follows:
shellParserControl - handle connecting and disconnecting remote users
This routine configures the shell to connect new telnet or rlogin sessions to the command interpreter by redirecting standard input and standard output and restores the original settings when those sessions exit. This routine is the default parser control installed as part of the INCLUDE_SHELL_REMOTE component. The default TELNETD_PARSER_HOOK setting for the INCLUDE_TELNET component accesses this routine. It only supports a single remote session at a time, which determines the default value of the TELNETD_MAX_CLIENTS parameter.
1: If you are developing on a Windows host, check your Windows and networking software documentation for information on which of these protocols are supported under Windows and how to use them.
2: When creating a boot program that must download an image using an RSH or and FTP client, you must make sure that you include those components in the program.