Applies To:

Show Versions Show Versions

Manual Chapter: Troubleshooting Tools
Manual Chapter
Table of Contents   |   << Previous Chapter   |   Next Chapter >>

The show health time-skew command shows the clocking skew between the ARX and its network peers.
Using SSH, you can run show commands from a remote host.
Refer to the ARX SNMP Reference for detailed information about any trap, including correction procedures.
bstnA(cfg)# show health
where trap is the trap or event name.
From any mode, you can use the show health time-skew command to see the time skew between the ARX, its DCs, and its back-end filers:
where timeout seconds (optional, 1-3600) specifies the maximum time to wait for responses from each server. The default is 3 seconds. The ARX often makes two or more connection attempts to each server, and this timeout applies to each attempt. Therefore, the command could take twice as long (or longer, in some cases) than the timeout you set here. Also, this timeout applies to each individual server, so the overall time for multiple servers may be longer. You can always use <Ctrl-C> to return to the CLI prompt before the command finishes.
bstnA(cfg)# show health time-skew
The syslog (short for System Log) contains all log messages from the systems internal software. Processes add informational messages to this log as they run, as well as error messages of varying severities. For an alphabetical list of syslog messages, see the ARX Log Catalog.
bstnA(cfg)# show logs
syslog Nov 21 03:59 13M
You can use the tail command from any mode to view syslog messages as they are added to the log:
tail logs file-name follow
logs is required to specify the logs directory,
file-name (1-255 characters) identifies the file to tail, and
follow is required to follow the syslog as it grows.
Use tail logs syslog follow to view the syslog file. Use <Ctrl-C> to stop the tail output and return to the CLI prompt.
prtlndA> tail logs syslog follow
tail logs file-name [number-lines]
file-name (1-255 characters) identifies the syslog file to tail, and
number-lines (optional, 1-4096) is the number of lines to show. By default, the command shows the last 24 lines in the file.
bstnA> tail logs syslog 5
Every log message originates from a log component (such as SCM_CLI in the sample above). A log component is a source of syslog messages, typically an internal process or group of processes. The table below is an alphabetical list of all log components, with a brief description and an indication of the board(s) where the software runs.
utc.uuu-tz:switch:slot-proc-board-pid:cmp-ins-sev-id:: msg
utc (2009-05-13T11:05:44 in the example) is the time in UTC.
uuu (202) is the millisecond time fraction.
-tz (+0000) is the hours off UTC (+nnnn or -nnnn).
switch (bstnA) is the switch name.
slot-proc-board (1-1-SCM) is the chassis slot, processor number, and board type (ACM, ASM, SCM, or NSM). Use the show processors command for a list of all processors and their associated modules.
pid (29776) is the Process ID (PID).
cmp (CLI) is the log-component name. Refer to Log Components, above.
ins (0) is the processs instance number.
sev (NOTE) indicates the message severity: DBG (debug) is the least severe, followed by INFO, NOTE, WARN, ERR, and CRIT (critical).
id (CLI_COMMAND) is the message-catalog ID, a unique ID for each log message. MSGn is an ID for an uncatologued message. The n is the severity of the message, from 7 (debug) down to 2 (critical). Refer to the ARX Log Catalog for an alphabetical list of log messages, sorted by their IDs. To view the documentation for a specific message, use the show documentation command (described later in the chapter).
msg (User admin: Command: bstnA# show nsck) is the message text itself.
bstnA(cfg)# show id-mappings
Use the show logs command to page through the active syslog or one of the syslog backups:
show logs file-name
where file-name (1-1024 characters) is the name of the desired syslog file.
bstnA(cfg)# show logs syslog
Use the grep command to apply a regular expression to the syslog as you page through it, viewing only the lines that contain a desired string:
grep pattern logs [file-name]
pattern (1-255 characters) is the regular-expression pattern to search for in the syslog. The grep displays all lines containing this pattern.
. matches any single character.
.* matches any string, including the null string.
[...] matches any one of the enclosed characters.
[a-z] matches any character in the sorted range, a through z.
\ matches the next character, even if it has special meaning (for example, \. matches a period instead of any character).
[^...] matches any character that is not enclosed. For example, [^0-9] matches any single character that is not a number from 0 to 9.
logs is a required keyword; this specifies the logs directory, where the syslogs are stored.
file-name (optional, 1-255 characters) identifies one file to search. If you omit the file name, the CLI searches through all files in the logs directory. Use the show logs command to see a list of accessible log files.
bstnA(cfg)# grep shareOnline logs syslog
You can use the ignore flag to filter out a second string from the grep output:
grep pattern logs [file-name] ignore ignore-pattern
pattern, logs, and file-name are described above,
ignore is required, and
ignore-pattern (1-1024 characters) is a pattern to ignore. Surround this with quotes () if it contains any spaces.
bstnA(gbl)# grep shareOnline logs syslog ignore acct
The show and grep commands search from the beginning of the syslog file, starting with the oldest messages and moving toward the most-recent logs. To skip ahead to the most-recent logs, use the tail option at the end of the grep command:
grep pattern logs [file-name] [ignore ignore-pattern] tail number-lines
pattern, logs, file-name, and ignore ignore-pattern are described above,
tail is required, and
number-lines (1-4096) is the number of lines to show.
For example, the following grep command shows only the 10 most-recent matching lines in the active syslog:
bstnA(gbl)# grep shareOnline logs syslog tail 10
show documentation msg-catalog-id
where msg-catalog-id (1-255 characters) identifies the message. This ID appears with the message in both the syslog (recall the id field in each syslog message; see Syslog Syntax) and in CLI output.
bstnA(gbl)# grep RON_SPFD logs syslog
bstnA(gbl)# show documentation RON_SYSTEM_CLOCK_CHANGED
copy logs syslog-file ftp://[username:password@]ftp-site/file
syslog-file identifies the syslog file to copy,
username:password@ (optional) is an FTP username and password (the default is set by the ip ftp-user command, as shown in Setting a Default FTP or SCP User),
ftp-site identifies the FTP server with an IP address or FQDN (for example, 172.16.88.3 or ftp.myftpsite.com), and
file is the chosen file name. Lead with an extra / if the path starts at the root of the server machine; for example, porthos//var/log/arx/syslog specifies /var/log/arx/syslog on server porthos. Omit the leading slash if the file is going to the home directory for username.
bstnA# copy logs syslog ftp://juser:jpasswd@ftp.wwmed.com/syslog_5-6
copy logs syslog-file scp://username@server:file [accept-host-key]
syslog-file identifies the syslog file to copy,
username@ is a valid username at the remote host,
server identifies the SCP server with an IP address or FQDN (for example, 172.16.100.18 or deb1.mynet.com), and
file is the chosen file name at the remote server. Lead with a slash (scp-server:/file) if the file path is absolute. Without the slash, the path is presumed to start in the home directory for username.
accept-host-key (optional) tells the CLI to accept an unknown host key if offered by the SCP server. The host key authenticates the server; if the key is unknown, it is possible that an attacker has taken the servers hostname and/or IP address. Note that any SCP server is unknown if the switch has not had an SCP exchange with it since the switchs last reboot.
The CLI prompts for the usernames password. Enter a password that is valid at the remote site.
bstnA# copy logs syslog scp://juser@rh1.wwmed.com:arx_syslog
Password: jpasswd
copy logs syslog-file {cifs|nfs} namespace volume file-path
syslog-file identifies the syslog file to copy,
cifs | nfs is a required choice. This is the network protocol used to copy the syslog file into the ARX volume.
namespace (1-30 characters) identifies the destination namespace.
volume (1-1024 characters) is the volume name.
file-path (1-1024 characters) is the path from the volume root (above) to the destination file.
bstnA# copy logs syslog cifs medarcv /rcrds admin
copy logs syslog-file smtp://[e-mail-address/]file
file is the chosen file name.
bstnA(cfg-smtp)# mail-server email1.wwmed.com
bstnA(cfg-smtp)# from admin@acopia.wwmed.com
bstnA# copy logs syslog smtp://juser@wwmed.com/arx_syslog
From cfg mode, use the logging level command to change the logging level for one (or all) log components:
logging level component {critical | error | warning | notice | info | debug}
component can be all or any log component (see Log Components), and
critical | error | warning | notice | info | debug chooses the logging level for the component. The critical level limits the component to critical log messages only, error allows both error and critical messages, and so on. Debug level is the most verbose; this causes the component(s) to issue every possible log message during their execution.
bstnA(cfg)# logging level TRANFS debug
logging level component disable
component can be all or any log component (see Log Components), and
disable stops all logging from the component.
bstnA(cfg)# logging level POLICY_PDP disable
Use the show logging levels command to see the logging levels for all log components:
bstnA(cfg)# show logging levels
where component can be all or any log component (see Log Components).
bstnA(cfg)# show logging levels POLICY
The default logging level for all components is info. Use no logging level to revert to the default logging level:
no logging level {component | all}
where you must choose either a single component or all components. Refer to Log Components for a complete list of components.
bstnA(cfg)# no logging level all
From cfg mode, use the logging destination command to add a server to the list of logging destinations:
logging destination target [udp | tcp] [port port]
target (1-80 characters) identifies an external server. This can be an IP address or, if you have a DNS lookups configured, a hostname. (To configure the switch for hostname lookups, see Configuring DNS Lookups, on page 4-31 of the ARX® CLI Network-Management Guide.)
udp | tcp (optional) chooses a transport protocol to reach the external server. This defaults to UDP if you omit it.
port port (optional, 1-65,535) selects a particular UDP or TCP port to receive the log messages. The default is port 514.
bstnA(cfg)# logging destination 172.16.202.8
bstnA(cfg)# logging destination 10.1.1.90 tcp port 9999
Use the no form of the logging destination command to remove one log server from the list:
where target (1-80 characters) identifies the server to remove. This can be an IP address or a hostname.
bstnA(cfg)# no logging destination 10.1.1.90
From cfg mode, use the management source command to change the source interface for outbound syslog messages:
where vlan-id (1-4096 characters) identifies the VLAN. Use show interface vlan to list all configured VLANs and their management interfaces (see Listing all VLAN Management Interfaces, on page 4-6 of the ARX® CLI Network-Management Guide).
bstnA(cfg)# management source vlan 25
prtlndA(cfg)# no management source
The management source mgmt command has the same effect:
bstnA(cfg)# management source mgmt
To show all configured logging destinations, use show logging destination from any mode:
bstnA(cfg)# show logging destination
The show system tasks command shows all running processes and the CPU and memory that each process is consuming. This is similar to the ps command on a Unix system, or the Task Manager on a Windows system. Invoke this command from any mode:
bstnA(cfg)# show system tasks
From priv-exec mode, use the collect diag-info ftp command to collect all diagnostic data (except reports, which can make the file excessively large) and send it to an FTP site:
collect diag-info ftp://[username[:password]@]ftp-site/file.tgz
username[:password]@ (optional) is an FTP username and optional password (the default is the username/password set by the ip ftp-user command),
ftp-site identifies the FTP server with an IP address or FQDN (for example, 172.16.88.3 or ftp.myftpsite.com), and
file.tgz is the chosen file name. Lead with an extra / if the path starts at the root of the server machine; for example, athos//usr/local/diag_files.tgz specifies /usr/local/diag_files.tgz on server athos. Omit the leading slash if the file is going to the home directory for username.
The CLI prompts for a password if you enter the username without one. The CLI then prompts for confirmation before collecting the diagnostics. Answer yes to continue. The collection process can be time-consuming; prompts appear to show the progress of the operation as it occurs.
bstnA# collect diag-info ftp://juser@arxftp.f5.com/acopia-diags.tgz
Password: jpasswd
collect diag-info scp://username@server:file.tgz [accept-host-key]
username@ is a valid username at the remote host,
server identifies the SCP server with an IP address or FQDN (for example, 172.16.100.18 or deb1.mynet.com), and
file.tgz is the file name for the diagnostics data. Lead with a slash (scp-server:/file) if the file path is absolute. Without the slash, the path is presumed to start in the home directory for username.
accept-host-key (optional) tells the CLI to accept an unknown host key if offered by the SCP server. The host key authenticates the server; if the key is unknown, it is possible that an attacker has taken the servers hostname and/or IP address. Note that any SCP server is unknown if the switch has not had an SCP exchange with it since the switchs last reboot.
The CLI prompts for the usernames password. Enter a password that is valid at the remote site. Then the CLI prompts for confirmation before collecting diagnostics; enter yes to continue. As mentioned above, you should allow at least one minute for the collection process to complete.
bstnA# collect diag-info scp://juser@rh1.wwmed.com:acopia-diags.tgz accept-host-key
Password: jpasswd
collect diag-info {cifs|nfs} namespace volume dest-path
cifs | nfs is a required choice. This is the network protocol used to transfer the diagnostics file to the ARX volume.
namespace (1-30 characters) identifies the destination namespace.
volume (1-1024 characters) is the destination-volume name.
dest-path (1-1024 characters) is the intended path from the volume root (above) to the diagnostics file. The directory you specify here must exist on the volume.
bstnA# collect diag-info cifs medarcv /rcrds admin/collect.tgz
In the same collect diag-info command, use the following syntax to send the diag-info as an E-mail attachment:
collect diag-info smtp://[e-mail-address/]file.tgz
file.tgz is the chosen file name. The .tgz extension is required.
As with the FTP and SCP uploads, the CLI prompts for confirmation before collecting the diagnostics. Answer yes to continue. The collection process can be time-consuming; prompts appear to show the progress of the operation as it occurs.
bstnA(cfg-smtp)# mail-server email1.wwmed.com
bstnA(cfg-smtp)# from admin@acopia.wwmed.com
bstnA# collect diag-info smtp://juser@wwmed.com/acopia-diags.tgz
where file is the chosen file name. You must use a .tgz extension on the end of the file name. The file is stored in the diag-info directory.
The CLI prompts for confirmation before overwriting any previously-collected diag-info files. Answer yes to continue. As stated above, the collection process can be time-consuming; allow at least one minute for the collection process to finish.
bstnA# collect diag-info juser-ns-wwmed.tgz
Use the show diag-info command to view the directory listing with the new diag-info file:
bstnA# show diag-info
collect diag-info destination async
destination can be any of the formats defined above for FTP, SCP, SMTP, an ARX volume, or a local file, and
async makes the collection process asynchronous.
The CLI prompts for confirmation; answer yes to continue. With the async option, the CLI displays a report name and then returns. You can use the tail reports report-name follow command to follow the collection process, or you can enter other CLI commands.
bstnA# collect diag-info ftp://juser:jpasswd@arxftp.f5.com/acopia-diags.tgz async
diag-info collects everything except reports, as described above.
config collects the configuration database, database logs, and the output from show running/global config.
cores gathers any core-dump files on the system, along with all shared-object libraries used by the system.
logs assembles the syslog, the procdat log (process data; a more-detailed log file for diagnosis by engineers), upgrade and installation logs, disk-usage logs, Kerberos state files, and logs from the systems service manager.
reports chooses all reports. (As mentioned above, these are omitted from the diag-info option because they can be excessively large at some installations.)
state collects individual log files from every processor in the switch, three system log files (syslog, procdat, and traplog), a chronological list of all CLI commands used since the switch booted, and the output from a series of useful show commands.
capture assembles all packet-capture files, which you can list with the show capture command. You can use a CLI command to capture IP traffic in a file for diagnostic purposes, as described in a later chapter. This command can send the capture file(s) to F5 for detailed examination.
all collects all information, including all reports. The diag-info option omits reports because they can be excessively large on some switches.
destination is either a local file name or any of the upload formats described above.
async (optional) makes the collection process asynchronous.
As shown earlier, the CLI prompts for confirmation before collecting the diagnostics. Answer yes to continue. The collection process can be time-consuming, depending on system state and the option that you have chosen; prompts appear to show the progress of the operation as it occurs.
bstnA# collect state ftp://arxftp.f5.com/sys-state.tgz
collect logs [start-time start [utc]] [end-time end [utc]] destination [async]
start-time start [utc] (optional) establishes a start time. If omitted, the command collects all of its logs up to the end-time.
start is a date and time. Enter this in one of two formats: mm/dd/yyyy:HH:MM:SS (designed for manual entry) or yyyy-mm-ddTHH:MM:SS (the time format found in the log files).
utc (optional) indicates that the start is UTC instead of local time. Without this, the start is assumed to be in local time, as established by the clock timezone command. This is intended for a copy-and-paste from a log file. (All time stamps in the log files are in UTC.)
end-time end [utc] (optional) establishes an end time for the collected logs. If omitted, the command collects all of its logs after the start-time. This has the same options as described above.
destination is either a local file name or any of the upload formats described above.
async (optional) makes the collection process asynchronous.
As with a full collection, the CLI prompts for confirmation before collecting the logs. Answer yes to continue. The collection process can be time-consuming, depending on system state and the options that you have chosen; allow at least one minute for the process to finish.
bstnA# collect logs start-time 05/06/2008:09:30:00 end-time 05/06/2008:12:30:00 smtp://juser@wwmed.com/mornLogs.tgz
Important: You must configure DNS and SMTP before you set up this data gathering mechanism. For instructions on setting up DNS, refer to the ip name-server command in the ARX® CLI Reference. For instructions on setting up SMTP, refer to the smtp command in the same manual.
From gbl mode, use the auto-diagnostics command to begin configuring the schedule for this regular data collection:
bstnA(gbl)# auto-diagnostics
The first step in setting up auto-diagnostic collection is assigning a schedule for it. To create a schedule, use the gbl schedule command (refer to Appendix 12, Creating a Policy Schedule of the ARX® CLI Storage-Management Guide for details). To apply a schedule to auto-diag collection, use the schedule command in gbl-auto-diag mode:
where name (1-64 characters) identifies the schedule. Use the show schedule command to list all schedules.
bstnA(gbl)# auto-diagnostics
bstnA(gbl-auto-diag)# schedule daily4am
show policy details
You can use the additional-command operation to add more show commands to this collection:
additional-command "show-command-string"
where show-command-string is the additional show command (128-byte limit) to add to the auto-diag collection. This command must start with the keyword, "show," and must be accessible from any CLI mode. Surround the string with quotation marks ("") if it contains any spaces.
bstnA(gbl)# auto-diagnostics
bstnA(gbl-auto-diag)# additional-command "show global service"
bstnA(gbl-auto-diag)# additional-command "show share status"
Use the command no additional-command to remove a user-added show command from future auto-diagnostic collections. This removes only the specified additional command, not any of the default commands listed in the previous section. The command syntax follows:
no additional-command "show-command-string"
For example, this command sequence removes the extra show command show share status from the auto-diagnostics collection at the "bstnA" switch:
bstnA(gbl)# auto-diagnostics
bstnA(gbl-auto-diag)# no additional-command "show share status"
You can use the mail-to command to add additional recipients for the collected E-mails. Unlike the collection for F5 Support, the E-mail attachment for these recipients is not encrypted. The ARX encrypts the collected information for F5 Support because it is likely to traverse the Internet:
mail-to recipient
where recipient is the E-mail address (128-byte limit) for someone to receive the collected diagnostics.
bstnA(gbl)# auto-diagnostics
bstnA(gbl-auto-diag)# mail-to juser@wwmed.com
bstnA(gbl-auto-diag)# mail-to jsmith@wwmed.com
Use no mail-to to remove one E-mail recipient from the auto-diagnostics list:
no mail-to recipient
where recipient (1-768 characters) is the E-mail address to remove.
bstnA(gbl)# auto-diagnostics
bstnA(gbl-auto-diag)# no mail-to jsmith@wwmed.com
You can display the current auto-diagnostics configuration by executing the show auto-diagnostics command. An example of the output from this command follows:
Type the privileged-exec mode CLI command auto-diagnostics test local to send an unencrypted auto-diagnostics mail test message to the Email addresses configured with the gbl-auto-diag mode mail-to command. No mail is sent to F5 Networks when this command is executed.
You can use SSH (the Secure SHell command) from a remote machine to run any show command at an ARX. Earlier chapter describe how to run various snapshot commands and/or a volume restore through SSH; recall Running Snapshot Operations from a Remote Host and Running the Restore from a Remote Host. You use the same ssh syntax to run show commands:
ssh admin-user@mip show-command
admin-user is the username for a valid administrative account at the ARX (use show users to list all of them, as shown in Listing All Administrative Users, on page 2-14 of the ARX® CLI Network-Management Guide),
mip is a management-IP address for the ARX (use show interface mgmt to show the out-of-band management interface, or show interface vlan to show all in-band management interfaces), and
show-command is a show command to run remotely. Surround this with quotation marks () if it contains any spaces.
The output of the show command appears in the local shell. For example, this command sequence runs from a Unix machine named mgmt17. The command runs show processors on bstnA, a remote ARX:
juser@mgmt17:~$ ssh admin@10.1.1.7 show processors
For example, the following command shows a namespace named test ns. The show namespace command requires quotes around test ns because it has a space in it.
juser@mgmt17:~$ ssh admin@10.1.1.7 show namespace %22test ns%22
Note: The snapshot remove command must remove the oldest snapshot before it removes any other snapshots. Without this restriction, file changes may be lost when a snapshot in the middle is removed. If a snapshot is removed while it is being used, the client will be notified, and it should rescan the files.
Executing the gbl-ns-vol mode CLI command notification rule creates a notification rule object and enters gbl-ns-vol-ntfy mode for defining the rule. This mode provides the following CLI commands:
enable, which activates the current snapshot rule.
report prefix, where prefix is the prefix to be prepended to each report name.
retain number, where number is the number of reports to be held, up to 1024.
schedule name, where name is the task schedule by which notification snapshots will be generated.
where name is the notification rule to be defined or edited.
Note: The various clear statistics CLI commands will reset these statistics and will be indicated by a reset marker in the log file. Clearing the global configuration will clear the statistics monitor data; if you wish to retain this data, make certain to copy it off the switch prior to clearing the global configuration.
Execute the show stats-monitor CLI command to display the current statistics monitor configuration:
After youve activated terminal beta mode, type stats-monitor in global configuration mode to enter gbl-stmon mode. Use this mode to access the statistics monitor log files, and to configure the statistics monitors sampling and notification behaviors.
To change the data sampling interval, use the sampling interval CLI command in gbl-stmon mode to specify the number of seconds between sampling intervals. This can range from a minimum of 30 to a maximum of 86,400 (one day).
Use the notify command in gbl-stmon mode to enter gbl-stmon-nfy mode for configuring event notification for a CIFS service, NFS service, or filer share. This controls when notification is sent because recent data is anomalous in the context of similar performance statistics used to calculate the moving average for the relevant parameter.
This causes you to enter a submode corresponding to the type of service that you specified, such as gbl-stmon-nfy[~cifs-service] if you executed notify cifs-service. If you specify filer-share, you must also specify cifs or nfs. Within each submode, you can use the commands metric, moving-average, and trap to configure the corresponding event notification parameters for that service type.
The Email group, stats-monitor, can be configured for trap notification for the following events:
filer-slow-clear: Filer share slowness is cleared.
filer-slow-raise: A filer share is slow.
service-slow-clear: Service slowness is cleared.
service-slow-raise: A service is slow.
filer-errors-clear: Filer errors are normal.
filer-errors-raise: Filer errors exceed the notificiation thresholds.
service-errors-clear: Service errors are normal.
service-errors-raise: Service errors exceed the notification thresholds.
cifs-service: This file type contains data plane CIFS service statistics, with services identified by their FQDN.
cifs-service-auth: This file type contains CIFS service authentication statistics. The services are identified by their FQDN.
cifs-share: This file type contains data plane and control plane CIFS filer share statistics, with shares identified by their namespace, volume, and share name in the ARX configuration.
cifs-work-queue: This file type contains CIFS work queue statistics. Work queues are identified by their volume group ID.
domain-controller: This file type contains domain controller statistics. Domain controllers are identified by their IP address.
metadata: This file type contains metadata statistics; objects in this file are identified by their namespace and volume.
metalog: This file type contains metalog statistics; objects in this file are identified by their volume group ID.
migration: This file type contains migration statistics. Objects in this file are identified by their namespace and volume.
nfs-service: This file type contains data plane NFS service statistics, with services identified by their FQDN.
nfs-share: This file type contains data plane and control plane NFS filer share statistics, with shares identified by their namespace, volume, and share name in ARX configuration.
You can view a particular log file by executing the show stats-logs filename command. For example:
Timestamp,fqdn,CheckDir-RTT,CheckDir-RTC,Close-RTT,Close-RTC,Create-RTT,Create-RTC,CreateDir-RTT,CreateDir-RTC,Delete-RTT,Delete-RTC,DeleteDir-RTT,DeleteDir-RTC,Echo-RTT,Echo-RTC,FindClose2-RTT,FindClose2-RTC,Flush-RTT,Flush-RTC,LockingAndX-RTT,LockingAndX-RTC,LogoffAndX-RTT,LogoffAndX-RTC,Negotiate-RTT,Negotiate-RTC,NTCancel-RTT,NTCancel-RTC,NTCreateAndX-RTT,NTCreateAndX-RTC,NTRename-RTT,NTRename-RTC,NTTransact/Create-RTT,NTTransact/Create-RTC,NTTransact/GetUserQuota-RTT,NTTransact/GetUserQuota-RTC,NTTransact/Ioctl-RTT,NTTransact/Ioctl-RTC,NTTransact/NotifyChange-RTT,NTTransact/NotifyChange-RTC,NTTransact/QuerySecurity-RTT,NTTransact/QuerySecurity-RTC,NTTransact/SetSecurity-RTT,NTTransact/SetSecurity-RTC,Open-RTT,Open-RTC,OpenAndX-RTT,OpenAndX-RTC,QueryInfo-RTT,QueryInfo-RTC,QueryInfoDisk-RTT,QueryInfoDisk-RTC,Read-RTT,Read-RTC,ReadAndX-RTT,ReadAndX-RTC,Rename-RTT,Rename-RTC,Seek-RTT,Seek-RTC,SessionSetupAndX-RTT,SessionSetupAndX-RTC,SetInfo-RTT,SetInfo-RTC,Transaction-RTT,Transaction-RTC,Transaction2/CreateDir-RTT,Transaction2/CreateDir-RTC,Transaction2/FindFirst2-RTT,Transaction2/FindFirst2-RTC,Transaction2/FindNext2-RTT,Transaction2/FindNext2-RTC,Transaction2/GetDFSReferral-RTT,Transaction2/GetDFSReferral-RTC,Transaction2/QueryFSInfo-RTT,Transaction2/QueryFSInfo-RTC,Transaction2/QueryFileInfo-RTT,Transaction2/QueryFileInfo-RTC,Transaction2/QueryPathInfo-RTT,Transaction2/QueryPathInfo-RTC,Transaction2/SetFileInfo-RTT,Transaction2/SetFileInfo-RTC,Transaction2/SetPathInfo-RTT,Transaction2/SetPathInfo-RTC,TreeConnectAndX-RTT,TreeConnectAndX-RTC,TreeDisconnect-RTT,TreeDisconnect-RTC,Write-RTT,Write-RTC,WriteAndX-RTT,WriteAndX-RTC,UnknownSMB-RTT,UnknownSMB-RTC,FormatError,NetworkError,ResourceError,SignatureError,SMBError,TimeoutError
Table of Contents   |   << Previous Chapter   |   Next Chapter >>

Was this resource helpful in solving your issue?




NOTE: Please do not provide personal information.



Incorrect answer. Please try again: Please enter the words to the right: Please enter the numbers you hear:

Additional Comments (optional)