8    Troubleshooting the ASU Software

This chapter describes how to troubleshoot some common ASU problems, describes tools that you can use to learn about problems, and offers possible solutions.

8.1    Preventing Problems

You can use ASU commands to track and monitor the status of the ASU server. By doing so, you can understand how the ASU server works under normal conditions and watch for indications that the ASU server might need adjustments before a problem arises.

8.1.1    Reviewing Statistics

You can use the net statistics command to display detailed statistics about the current usage and cumulative usage of ASU over a period of time. If you review ASU statistics on a regular basis, you will find it easier to recognize and address ASU changes. Table 8-1 describes the statistics that the ASU server maintains.

Table 8-1:  ASU Statistics

Statistic Shows
Statistics since The start date for reading this set of statistics (either at the last ASU startup or the last time the statistics were cleared).
Sessions accepted The number of times users connected to the ASU server.
Sessions timed-out The number of user sessions that were closed because of inactivity.
Sessions errored-out The number of user sessions that ended because of error.
Kilobytes sent The number of kilobytes of data the ASU server transmitted.
Kilobytes received The number of kilobytes of data the ASU server received.
Mean response time (msec) The average response time for processing remote server requests. This always will be zero (0) for Tru64 UNIX system servers.
System errors This statistic does not apply to Tru64 UNIX system servers.
Permission violations The number of times that a user attempted to access resources without the required permissions.
Password violations The number of incorrect passwords that were tried.
Files accessed The number of files that were used.
Communication devices accessed This statistic is not supported on the ASU server.
Print jobs spooled The number of print jobs that were spooled to printer queues.
Times buffers exhausted The number of shortages of big request buffers. Always set to zero (0) for Tru64 UNIX system servers.

8.1.2    Gathering Transaction Statistics

By default, transaction statistics are gathered by the countbeans parameter in the lanman.ini file.

To disable the countbeans parameter, edit the lanman.ini file and change the countbeans value to no. Add the countbeans parameter to the lanman.ini file under the lmxserver section if it does not already exist. For example, to disable the countbeans parameter, enter:

[ lmxserver ]
countbeans=no

To enable the countbeans parameter, set the value to yes.

Use the asustat -n command to view transaction statistics. The following message is displayed if the countbeans parameter is disabled:

The gathering of transaction statistics has been disabled.

8.1.3    Using Scripts

You can use the scripting features provided by the Tru64 UNIX operating system in combination with ASU data-gathering tools to create a powerful tool that can assess the condition of the ASU server at any time.

For example, using the Tru64 UNIX system job scheduling feature (cron), ASU data gathering tools, and standard Tru64 UNIX commands for checking file system integrity and free space, you can write scripts that perform various checks and mail the results to Tru64 UNIX system administrators at regular intervals.

8.1.4    Generating Alert Messages

The ASU server sends a message to a specified list of users when an administrative alert occurs. The system generates administrative alerts that relate to the ASU server and resource use. They warn about security and access problems, user session problems, problems with services, shutdown because of power loss, printer problems, and registry parameters being exceeded.

For example, the following situations will generate an alert message:

For an alert message to be sent, the Alerter and Messenger services, which are usually enabled by default when the system starts, must be running on the computer originating the alert. For an alert message to be received, the Messenger service must be running on the destination computer.

You can use the Server Manager GUI to view and manage the list of users and computers that are notified when administrative alerts occur.

8.1.5    System, Security, and Application Log Files

Events generated by the ASU server are automatically recorded in three event log files: system, security, and application.

An ASU event is any significant occurrence in the system (or in an application) that requires user notification. Critical events are noted in on-screen messages. An event that does not require immediate attention is recorded in one of the following event log files located in the /usr/net/server/lanman/logs directory:

You can view system, security, and application log files by using either the Windows based Event Viewer or the elfread command.

8.1.5.1    Windows Event Viewer

The Event Viewer (eventvwr.exe) is installed on Windows NT systems. You can install the Event Viewer on a Windows 95 or Windows 98 system by installing the Windows based administrative interfaces. See Section 1.8.2 for more information on installing the Windows based administrative interfaces.

The Event Viewer lists events. Double click on any event to learn more about it.

See the Event Viewer online help for more information on viewing events.

8.1.5.2    The elfread Command

Use the elfread command to display log files and clear events. You can copy, move, or rename the default log file to a file that you specify.

To display a summary of the system log, enter:

# elfread system

To display a file called Monday into which you copied the system log, enter:

# elfread -f Monday system

See elfread(8) for more information on the elfread command.

8.1.6    Printer Log Files

For each printer share and each Tru64 UNIX system printer, the ASU server maintains a print log that contains messages generated due to printer faults or print job errors. Printer log files are located in the /usr/net/servers/lanman/shares/printlog directory.

You use a text editor to periodically check these log files to determine whether such errors have occurred.

8.1.7    Logging ASU Network Errors

The following sections describe where ASU network related errors are logged.

8.1.7.1    Computer Name Conflicts

If the computer name you choose for the ASU server conflicts with an existing system, an error message containing the name and address of the system that declared the conflict is generated in the following files:

8.1.7.2    Connection Problems Between a WINS Server and an ASU Server

Messages are generated in the following log files when the ASU server, configured as a WINS client, loses and reestablishes contact with a WINS server:

8.1.7.3    NetBIOS over TCP/IP Runs Out of Names

If NetBIOS over TCP/IP runs out of names, the following message is written to the system log (/var/adm/messages):

knbtcp: Warning - NetBIOS name limit exceeded; current limit = 32     
Recommend increasing parameter "knbnames" for subsystem "knbtcp" 
using sysconfigdb

See Chapter 7 for more information on increasing the number of NetBIOS over TCP/IP (knbtcp) names.

8.1.7.4    NetBEUI Runs Out of Datalinks

If NetBEUI runs out of datalinks, the following message is written to the system log (/var/adm/messages):

netbeui: Warning - link limit exceeded; current limit = 8     
Recommend increasing parameter "nb_datalinks" for subsystem 
"netbeui" using sysconfigdb

This error occurs when there are insufficient datalinks for the number of controllers configured. You need to configure two datalinks in NetBEUI for each controller configured.

See Chapter 7 for more information on increasing the number of datalinks.

8.1.7.5    NetBEUI Runs Out of Names

If NetBEUI runs out of NetBIOS names, the following message is written to the system log (/var/adm/messages):

netbeui: Warning - NetBIOS name limit exceeded; current limit = 32     
Recommend increasing parameter "nb_names" for subsystem "netbeui" 
using sysconfigdb

See Chapter 7 for more information on increasing the number of NetBIOS names.

8.1.8    Capturing All Network Packets

You can configure the ASU server to log information about all the network packets that are generated or received by the ASU server to a text file located in the /usr/net/server/lanman/debug directory. The file is called Debug-process-pid, where process is the name of the process and pid is the process identifier.

You can use a text editor to view the Debug-process-pid file to learn about the contents of the network packets.

When the logging of network packets is enabled, the ASU server responds slowly since all network activity is being recorded. You should enable logging only for the purpose of duplicating a problem. Stop the logging of network packets after the problem is duplicated and a Debug-process-pid file is generated.

To enable the ASU server to log network packets you can:

You can add the debugumask parameter in the [ lmxserver ] section of the lanman.ini file to control user access to the debug log and crash files. The permissions you set are similar to the octal settings used by the umask command. The default value for the debugumask parameter is 0600 (Read and Write for the owner).

If the problem is caused by a process that terminated abnormally, then a subdirectory specific to that process is created in the /usr/net/server/lanman/debug directory. The subdirectory is called Crash-process-pid-node, where process is the name of the process, pid is the process identifier for the process that terminated abnormally, and node is the name of the node on which the process was running. A core, StackTrace, and a ShmemTrace file are placed in the directory.

For example, if a server process (lmx.srv) with a PID of 512 on a node called red crashes, core, StackTrace, and a ShmemTrace files are created in the following directory:

/usr/net/servers/lanman/debug/Crash-LMX.SRV-512-RED

You can use a text editor to view the StackTrace file to learn about the process termination.

You can use the asustat -i command to view the ShmemTrace file to learn about the state of the ASU server when the process terminated. For example, to view a ShmemTrace file for a server process with a PID of 512 that crashed on a node called red, enter the following commands:

# cd /usr/net/servers/lanman/debug/Crash-LMX.SRV-512-RED

# asustat -a -i ShmemTrace

8.1.9    Generating StackTrace and Core Files for ASU Processes

If you are unable to determine the cause of an ASU problem, you can generate a StackTrace, ShmemTrace, and a core file for each ASU process. The StackTrace, ShmemTrace, and core files contain information that helps you to determine the state of each started ASU service.

Generating StackTrace, ShmemTrace, and core files causes the started ASU processes and services to stop, and creates a directory for each process in the /usr/net/servers/lanman/debug directory in which a StackTrace, ShmemTrace, and core file is generated. The directory created is called Crash-process-pid-node, where process is the process name, pid is the process identifier, and node is the name of the node on which the process was running.

To generate a StackTrace, ShmemTrace, and core file for each started ASU process you must send a SIGTRAP to the lmx.ctrl PID. For example, if the PID for the lmx.ctrl process is 26059, enter:

# kill -5 26059

8.1.10    Generating StackTrace and Core Files for ASU Transport Link Processes

If you are unable to determine the cause of an ASU transport problem, you can generate a StackTrace and core file for each link process. The StackTrace and core files contain information that helps you to determine the state of each started ASU link process.

Generating StackTrace and core files causes the started ASU transport link processes to stop, and creates a directory for each process in the /usr/net/servers/lanman/debug directory in which a StackTrace and core file is generated. The directory created is called Crash-process-pid, where process is the link process name and pid is the process identifier.

To generate StackTrace and core files for each started ASU transport link process, you must send a SIGTRAP to the link PID. For example, if the PID for the knblink process is 685, enter:

# kill -5 685

8.2    Solving Common ASU Server Problems

This section describes some common ASU server problems and recommends resolutions.

8.2.1    The ASU Software Might Be Corrupt

If you suspect that the ASU software is corrupt, use the fverify command to verify the attributes for installed files related to ASU.

During the ASU installation a special inventory file called SUBSET.inv.inst was created in the /usr/.smdb. directory. Use this special inventory file as the input for the fverify command. For example, to verify the files in the ASUBASEnnn subset, enter:

# /usr/lbin/fverify < /usr/.smdb./ASUBASEnnn.inv.inst

Where nnn is the version of ASU. See the ASU Release Notes for the current version number.

See fverify(8) for more information on the fverify command.

8.2.2    The ASU Server Will Not Start

If the ASU server will not start:

8.2.3    Difficulty Accessing the ASU Server

The following sections describe items to check if a large portion of the user community cannot access the ASU server.

8.2.3.1    Verify Network Links

Most networking hardware provides status indicators that you use to assess the state of the various network links (for example, 10-Base-T Hubs use LEDs). See your network hardware documentation for information on how to check these links for signs of problems.

If a client cannot connect to anything on a network that is otherwise functioning, then it is safe to assume that the problem is related to that client's network configuration. If, however, that client can connect to other systems on the network but not to the ASU server, then the network path to the ASU server or the account being used by that client is likely to be the source of the trouble.

Several third-party products are available that you can use to monitor the activity of the physical network. Check your network traffic periodically to determine whether or not problems are occurring with the physical network.

8.2.3.2    Verify that the Required ASU Processes Are Running

To verify that the ASU processes are running, enter:

# ps -ef | grep lmx

Information similar to the following is displayed:

root 17726   1     0  12:03:36   0:00    lmx.alerter
root 17713   17461 0  12:03:32   0:00    lmx.srv -s 1
root 17722   17874 0  12:03:35   0:00    lmx.srv -s 2
root 17726   1     0  12:03:36   0:01    lmx.dmn
root 17728   1     0  12:03:36   0:01    lmx.browser
root 17744   1     0  12:03:28   0:00    lmx.ctrl

This report indicates that the three required server processes are running: the netlogon daemon (lmx.dmn), the control process (lmx.ctrl), and the lmx.srv server processes. Additional lmx.srv processes, each with a unique number displayed at the end of the line, might be displayed as in the preceding example. The controller starts new lmx.srv processes based on the number of clients supported by the server. As more client sessions start, more lmx.srv processes may start, each with a unique process ID and number. Information about other processes, such as lmx.browser and lmx.alerter, might be displayed.

Use the asustat command to display current ASU data from the system's shared memory image. Executing the asustat -c command displays information similar to the following that shows clients connected to lmx.srv processes:

Clients:
 
[000] A.SERVE~X nwnum=0, vcnum=2 on 17713 LIC=00 (NONE)     link=[000]
[002] B         nwnum=0, vcnum=1 on 17713 LIC=02 (BUILT-IN) link=[002]
[003] C         nwnum=0, vcnum=1 on 17722 LIC=02 (BUILT-IN) link=[003]

Notice that each client name has an associated PID number (for example, A.SERVE~X has PID 17713). This is the PID of the lmx.srv process that currently is serving that client. The nwnum value specifies the transport that is being used for the session where 0 is NetBEUI and 1 is TCP/IP. The vcnum value specifies whether this is the client computer's first connection or an additional connection.

The ability to determine the PID of the lmx.srv process that is serving a client is particularly useful when using the asustat -w command. This command requires a PID.

If the ASU server is not running, enter the following command:

# net start server

8.2.3.3    Verify that the Required ASU Services Are Started

Determine if the ASU services started properly. A situation can occur when several ASU server processes are running, but the ASU server cannot be accessed because a particular service did not start. This is especially true for the NetLogon service. To display the started ASU services, enter:

# net start

A list of started ASU services is displayed.

If the NetLogon and Server services are not displayed, there is a problem with the ASU software. The NetLogon service sometimes will not start because of a problem with the ASU server name, domain name, or domain configuration.

Check the event logs for problems as described earlier in this chapter.

8.2.3.4    Verify that ASU Can Communicate Using TCP/IP

If the physical network appears to be functioning properly, then determine whether the various systems on the network can communicate with each other using the TCP/IP transport protocol.

You can use the Tru64 UNIX ping command to test whether or not the TCP/IP transport protocol is working properly on systems.

If the ping command is entered on a system on which the ASU server is running and cannot locate a client, then that client cannot connect to the ASU server using the TCP/IP transport protocol.

If the ping command is entered on several systems and cannot locate the system on which the ASU server is running, then one of the following conditions might exist:

If the ping command fails, run the /usr/sbin/asuivp utility to verify that the TCP/IP protocol is installed correctly.

Review the recommendations in your transport protocol software documentation.

See ping(8) for more information on the ping command.

8.2.3.5    Verify that ASU Can Communicate Using NetBIOS

ASU server communications are based on NetBIOS name sessions. Therefore, connectivity between nodes may be available but, if connectivity between NetBIOS names is not working, then the ASU server will not work.

To determine if the ASU server is communicating over the network using NetBIOS, enter:

# net view

If the ASU server name does not display, enter the asusetup command to reconfigure the ASU transports.

To determine if NetBEUI is posting NetBIOS names correctly, enter:

# nbemon -i1

To determine if TCP/IP is posting NetBIOS names correctly, enter:

# knbmon -i1

If names do not display, then either the transport type is not configured to run, or the ASU link process for the transport has stopped. To determine if the TCP/IP link process is running, enter:

# ps -e | grep knblink

To determine if the NetBEUI link process is running, enter:

# ps -e | grep dllink

# ps -e | grep nbelink

If the process is not running, execute asusetup to configure and restart the link process. If you get the error Cannot unload drive, you must reboot the system.

8.2.3.6    Verify Tru64 UNIX System Functionality

If network connections are working properly, verify the functionality of the Tru64 UNIX operating system on the system on which the ASU server is installed. The Tru64 UNIX operating system software provides a variety of log files and system checks that you can use to verify proper operation. See System Administration for information on these checks.

The ASU server is particularly sensitive to the following system problems:

8.2.3.7    Verify that ASU Special Disk Shares Are Shared

The following special ASU disk shares are automatically shared when you install the ASU software. Do not delete, modify, or reshare these special disk shares. Clients use these special disk shares in the background.

ADMIN$
C$
D$
DOSUTIL
IPC$
NETLOGON
OS2UTIL
PRINTLOG
PRINT$
USERS

If any of these special disk shares are missing, the ASU server will not function properly. Enter the following command to display disk shares:

# net view \\ASU_servername

Special disk shares ending with a dollar sign ($) are hidden and do not display when you browse the ASU server. However, you can connect to a hidden share if you specify the share name as follows:

\\servername\sharename$

If you detect a special disk share is missing, restart the ASU server by entering the following commands:

# net stop server

# net start server

Contact your services representative if a special disk shares is still missing after you restart the ASU server.

8.2.3.8    Determine If the ASU Registry Is Corrupt

To determine whether the internal format of the registry file is corrupt, enter:

# regcheck -C

A message is displayed that reports the condition of the registry.

If a message indicates that the registry is corrupt, enter the following command to repair the registry:

# regcheck -R

A message similar to one of the following is displayed that indicates the source of the corruption:

Keys had larger ID's than the next ID to allocate.

Keys did not have hash table entries.

Keys had duplicate ID's.

Keys listed nonexistent subkeys.

Keys were not listed as subkeys by their parents.

Keys had nonexistent parents.

Keys had wrong subkey names.

Keys listed subkeys that weren't really subkeys.

Keys had inconsistent representations.

Dead entries were found in the hash table.

If any corruption in the registry was repaired, enter the following command to reinitialize any missing registry values to their defaults:

# regload

Follow these steps if you are unable to repair the registry:

  1. Delete the registry by entering the following command:

    # rm /usr/net/servers/lanman/datafiles/registry*

  2. Reinitialize the registry to set all the registry values entries to their default values by entering the following command:

    # regload

See regcheck(8) and regload(8) for more information on these commands.

8.2.3.9    Verify the Parameters in the lanman.ini File

Default settings are used for the parameters in the lanman.ini file; however, you can change the default values.

To display a list of the parameters in the lanman.ini file and their settings, enter:

# srvconfig -p | more

See srvconfig(8) for more information on the srvconfig command and Appendix C for more information on the lanman.ini file.

8.2.3.10    Determine If the User Account Database is Corrupt

To determine whether the user account database is corrupt, enter:

# samcheck -s

A message is displayed that reports the condition of the user account database.

If a message indicates that the user account database is corrupt, enter the following command to repair the database:

# samcheck -r

See samcheck(8) for more information on the samcheck command.

8.2.3.11    Determine If the ACL Database Is Corrupt

Enter the following command to verify if the ACL database is corrupt:

# acladm -C

If the file is corrupt, then the command prompts you before repairing the file.

See acladm(8) for more information on the acladm command.

8.3    Solving Common Share Problems

This section describes some common problems with shared resources and recommends resolutions.

8.3.1    User Cannot Connect to a Share

If a user cannot connect to a share, ensure that:

8.3.1.1    Verify That the Share Exists

To display a list of disk share names, enter:

# net view \\ASU_servername

If the disk share name that the user is trying to connect to does not display, it does not exist. Use the net share command to create the share if necessary. See Chapter 4 for more information on creating disk shares.

8.3.1.2    Determine the Maximum Number of Clients

The ASU server will only service as many clients as there are ASU licenses. The maximum number of clients is defined by the maxclients parameter in the server lanman.ini file.

To display the value assigned to the maxclients parameter, enter:

# srvconfig -g 'server,maxclients'

Use the asustat -n command to view the number of clients connected. If there are fewer clients than the value of the maxclients parameter, but clients still cannot connect, use the asustat -L command to view the current number of available ASU licenses. If all the ASU licenses are in use, no other clients can connect to the ASU server.

8.3.2    User Cannot Access a File

If a user cannot access a file, check:

8.3.2.1    Viewing and Changing Windows NT Share Permissions

To view Windows NT share permissions you can use:

To use the net perms command to display the Windows NT share permissions for a disk share called project, enter:

# net perms \\project

To set the project Windows NT disk share permission to read for a user named peter, enter:

# net perms \\project /grant peter:read

Note

By default, all users have permission to connect to a share. Access to directories and files in the share is normally controlled through NTFS permissions. See Section 8.3.2.2 for more information

8.3.2.2    Viewing and Changing Windows NTFS Permissions

To set NTFS permission you can use:

To use the net perms command to view Windows NTFS permissions for the share called project, enter:

# net perms c:/usr/net/servers/lanman/shares/project

To use the net perms command to grant the team1 group the Windows NTFS write permission to the project disk share, enter the following command. Press Enter after you type the entire command.

# net perms c:/usr/net/servers/lanman/shares/project /grant team1:w

8.3.2.3    Checking Tru64 UNIX Permissions

You use standard Tru64 UNIX commands, such as chown, chgrp, and chmod to set ownership and permissions for directories and files that are associated with a disk share.

To set the permission for the world to read the project directory, enter:

# chmod 774 /usr/net/servers/lanman/shares/project

See chown(8), chgrp(8), and chmod(8) for more information on these commands.

8.3.2.4    Check for Open Locks

An application program error can sometimes leave a file open with a lock on it. A file in this state is unavailable to other users.

To correct the access problem, you can close these files by using:

8.3.2.5    Check for Insufficient UStructs

Follow these steps to check if there is an insufficient number of UStructs:

  1. Enter the following command to display the maximum number of UStructs. The backslash ( \ ) at the end of a line indicates continuation. Enter the entire command, then press the Enter key.

    # regconfig SYSTEM/CurrentControlSet/Services/\ 
    AdvancedServer/ProcessParameters NumUStructs
    

  2. Enter the following command to view the number of open files and file locks:

    # asustat -n

The total number of open files and file locks cannot exceed the number of UStructs. See Section 7.6 if you need to increase the number of UStructs.

8.4    Solving Common Browsing Problems

This section describes some of the common problems relating to the Computer Browser service and recommends resolutions.

8.4.1    Browser Does Not Display ASU Shares

If ASU shares do not display in browsers, restart the browser service by entering the following commands:

# net stop browser

# net start browser

8.4.2    LAN Manager Servers Do Not Show the ASU Server

If the output displayed by the net view command does not show the ASU server in the domain, edit the ASU registry and enable the LmAnnounce entry. Enabling this entry configures the ASU server to broadcast LAN Manager-style server announcements.

Follow these steps to use the regconfig registry editor to enable the ASU server to broadcast LAN Manager-style server announcements. The backslash ( \ ) at the end of a line indicates continuation. Enter the entire command, then press the Enter key.

  1. Enable the LmAnnounce entry by entering the following command:

    # regconfig SYSTEM/CurrentControlSet/Services/\ 
    LanmanServer/Parameters LmAnnounce REG_DWORD 1
    

  2. Restart the ASU server by entering the following commands:

    # net stop server

    # net start server

8.4.3    BDCs Browse Lists Do Not Show All Controllers

It can take as long as 12 minutes for the system to update the browse list. You can edit the ASU registry on the BDC to change the value of the BackupUpdate parameter to change the amount of time (in seconds) between updates. Note that increasing the browse update time generates increased network traffic.

Follow these steps to use the regconfig registry editor to decrease the time that it takes to update the browse list. The backslash ( \ ) at the end of a line indicates continuation. Enter the entire command, then press the Enter key.

  1. Decrease the time set in the BackupUpdate entry. To decrease the value of the BackupUpdate entry to 10 minutes (600 seconds), enter:

    # regconfig SYSTEM/CurrentControlSet/Services/\ 
    Browser/Parameters BackupUpdate REG_DWORD 600
    

  2. Restart the ASU server by entering the following commands:

    # net stop server

    # net start server

8.5    Solving Common Printing Problems

This section describes some of the common problems relating to shared printer queues and recommends resolutions.

8.5.1    Client Printers and Jobs Do Not Display

Manually refresh the screen by pressing the F5 key. You should do this to update the screen whenever you pause, resume, delete, or add printers.

8.5.2    Printer Name Is Invalid

Ensure that the printer name does not contain any spaces, and that the share name is the same as the printer name.

8.5.3    No Separator Page

The default separator page is the Tru64 UNIX LP subsystem banner page. You can configure the ASU server to use a custom separator page by entering the net print command with the separator:pathname option.

For more information on the net print command, enter:

# net help print /options | more

8.5.4    Print Jobs Do Not Print

Ensure that:

8.5.5    Characters Print Incorrectly

Refer to your printer manual to set the printer for no parity.

8.5.6    Trouble Printing to a Shared Client Printer

A shared client printer is connected to parallel port LPT1 or PRN on your client computer. Print jobs sent to that printer over the network (rather than locally) do not print, although print jobs sent from your owner client computer do print, indicating that the printer itself is operational.

Enter the net use command. If the display shows that the LPT1 or PRN port ID is linked to the printer, unlink that port ID; then link an unused port ID to the printer. The LPT1 or PRN port must be reserved for the physical connection to the printer.

8.5.7    Keyboard Locks When Printing

Your keyboard may lock for a few seconds if you are using an application on a client to which a shared client printer is connected and a print job is in progress. This hesitation at the keyboard is normal under these circumstances, especially when the printer is connected to a serial port.