From: CSBVAX::CSBVAX::MRGATE::"SMTP::CRVAX.SRI.COM::RELAY-INFO-VAX" 3-FEB-1989 04:04 To: MRGATE::"ARISIA::EVERHART" Subj: Re: Using FAL$LOG and FAL$OUTPUT Logicals Received: From KL.SRI.COM by CRVAX.SRI.COM with TCP; Thu, 26 JAN 89 14:08:27 PDT Received: from VLSI.JPL.NASA.GOV by KL.SRI.COM with TCP; Thu, 26 Jan 89 13:49:18 PST Received: from jplgp.span by VLSI.JPL.NASA.GOV with VMSmail ; Thu, 26 Jan 89 13:50:48 PST Date: Thu, 26 Jan 89 13:50:48 PST From: tencati%jplgp.span@VLSI.JPL.NASA.GOV Message-Id: <890126135048.316b@VLSI.JPL.NASA.GOV> Subject: Re: Using FAL$LOG and FAL$OUTPUT Logicals To: info-vax@kl.sri.com X-ST-Vmsmail-To: JPLLSI::"info-vax@kl.sri.com" In the DECUS pre-symposium seminar "Introduction to DECnet/VAX Security" that I teach, one of the topics that we cover is the use of logicals like FAL$LOG, FAL$OUTPUT and NETSERVER$TIMEOUT. The following rambling describes the use of these logicals. Under VMS 4.x, the FAL logicals were undocumented. As of V5.0 they have come out of the closet. I'll be glad to answer any additional questions you may have. ----------------------------------------------------------------------- Two logical names can be used for FAL logging. They are FAL$LOG and FAL$OUTPUT. The former is used to redirect the logging output in a file different from the normal remote session log file (in general NETSERVER.LOG in default DECNET account directory). The format and function of these logical names are not documented and may change at any revision. Their use may considerably the performances of the FAL processes, as well as it can improve them. The primary function of the logical name FAL$LOG is to request the logging of various types of information about the file operation performed by FAL. This includes identifying each accessed file, displaying the Data Access Protocol (DAP) message exchanged, computing data throughput statistics, and logging the logical link and mailbox QIO calls and the subsequent delivery of ASTs. Logging operations are requested via the parameter bitmask value. A secondary use of the logical name is to specify qualifiers that control various aspects of FAL's operation such as determining buffer sizes or disabling features. Currently the format of the FAL$LOG option string is : [parameter][/qualifier_1, ..., qualifier_n] where each qualifier is of the form keyword=value (e.g., /BPM=20). The parameter and qualifiers are optional. However, the parameter if present must precede any qualifiers. In addition, only the first three characters of a qualifier keyword are examined to determine a match. Thus, /DISABLE=xx can be abbreviated to /DIS=xx. Spaces and tabs are ignored and keywords can be entered using either uppercase or lowercase characters. PARAMETER VALUES The parameter is a hexadecimal bitmask used to specify FAL logging options. If this parameter is non-zero (indicating that FAL logging output will be generated), then an attempt is made to translate the logical name SYS$OUTPUT prior to opening the log file. If FAL$OUTPUT is defined, then its equivalence string is used as the file specification of the log file; otherwise logging output is directed to SYS$OUTPUT which normally points to the default network log file named SYS$LOGIN:NETSERVER.LOG. The bitmask definitions for the parameter are as follows : Bit0 -- enable logging of file name and type of file access requested. Bit1 -- enable logging of data throughput and other performance statistics. Bit2 -- enable logging of individual DAP messages as they are processed from the input buffer or assembled in the output buffer. Bit3 -- enable logging of DAP message packet and mailbox AST routine completions. Bit4 -- enable logging of DAP message packet and mailbox QIO requests. Bit5 -- enable logging of internal counters. QUALIFIER VALUES The following qualifiers are recognized where 'd' denotes a decimal digit and 'x' denotes a hexadecimal digit : /DISABLE=xx (Disable FAL Options) where the bitmask value denotes: Bit0 -- disable DAP level CRC checksum generation and comparison. (Note that CRC checking will be automatically disabled if the initiating mode does not support DAP level CRC computations). Bit1 -- disable DAP message blocking in both directions (i.e. transmit each DAP message in a separate QIO system service call). Bit2 -- disable RMS multi-block caching to/from disk when block I/O file transfer mode is in effect. This restores the pre-VMS 3.4 block I/O processing behaviour of FAL where each DAP data message resulted in one RMS $READ or $WRITE call to be executed. Note also that selection of this option eliminates one MOVC5 copy of data in memory at the expense of greatly increasing the number of RMS I/O operations performed during a file transfer. Bit3 -- disable poor-man's (or manual) routing (i.e., have FAL reject any file specification it receives that contains a node name). Bits4-7 are undefined. /ENABLE=xx (Enable FAL options) is currently not used. /BPM=ddddd (Bytes per messages) this is the maximum number of bytes per DAP message to display (used only if parameter bit2 is set). The default value is 20 bytes per message. /BPL=dd (Bytes per line) this is the maximum number of bytes per line to display when dumping a DAP message (used only if parameter bit2 is set). The default value is 20 bytes per line. /RBK_CACHE=ddd (RMS multi-block cache size) this controls the number of disk blocks per RMS $READ or $WRITE call to transfer when block I/O file transfer mode is selected (if bit2 of the /DISABLE option is set, this option is ignored). The number can vary from 1 to 127, the default is 64. /DBS=ddddd (DAP buffer size) request FAL to send this value in the DAP Configuration message for the field. /SYSTEM_ID=xxxx (System Identification) requests FAL to send this value in the DAP Configuration message for the fields (the OSTYPE file is the low order byte of the value). /VERSION=xxxxxxxx (DAP version number) requests FAL to send this value in the DAP Configuration message for the fields (the field is the low order byte of the value). /SC1=xxxxxxxx (System Capabilities Part 1) requests FAL to send this value in the DAP Configuration message for bits <31-00> of the field. /SC2=xxxxxxxx (System Capabilities Part 2) requests FAL to send this value in the DAP Configuration message for bits <63-32> of the field. Note that any qualifier that cannot be interpreted or that contains an invalid value is ignored and a parse error message is written in the log file. EXAMPLES The following DCL commands illustrate how FAL logging options may be setup in one's LOGIN.COM file. $ DEFINE FAL$LOG 1 The above command enables the logging of file name and type of access in the default network log file NETSERVER.LOG. $ DEFINE FAL$LOG 3 $ DEFINE FAL$OUTPUT FAL.LOG This requests the logging of file name, type of access, and data throughput statistics in SYS$LOGIN:FAL.LOG. $ DEFINE FAL$LOG "3/RBK_CACHE=16/DBS=1056" $ DEFINE FAL$OUTPUT disk:[dir]statistics_of_fal.lis The above definitions are used to gather data throughput statistics in the specified log file while altering buffer sizes. $ DEFINE FAL$LOG "7/BPM=80" This definition causes the first 80 bytes of each message to be dumped and file identification and statistics to be displayed in the log file. $ DEFINE FAL$LOG 7_50 Same as the previous example, except the VMS V3.n parameter format of xx_yyyy is used where yyyy is the number of bytes per DAP message to display expressed as a hexadecimal value. $ DEFINE FAL$LOG "/DISABLE=8" This disables poor-man's routing which prevents users from using FAL as a pass-through object on this node. $ DEFINE FAL$LOG 2F This enables all FAL logging options excluding qualifier control options. ----------------------------------------------------------------------- Additional Notes: o The symbol FAL$OUTPUT if used, should be a FILE spec, not just a directory spec. This defines where the additional FAL$LOG output goes only, the connection information still goes to the default NETSERVER.LOG file. o If you set FAL$LOG to any value other than numeric, it is manditory that you enclose the entry in double quotes (see above examples). o I personally recommend that you disable poor-man's routing unless you are required to support it. This will stop your node from being used as a "stepping stone" by hackers. Your negligence in this area could cause you legal problems in this age of viruses and worms. Besides - Force the hacker to connect directly to his targets. o DECnet starts up SERVER processes (e.g., SERVER_00DE) to handle network requests. In a default configuration, these servers do not die after the network process exits. I recommend that you define the system-wide logical symbol NETSERVER$TIMEOUT to a value of "0000 00:00:05". This will cause these servers to logoff at the conclusion of the process on whose behalf they were created. Separate NETSERVER.LOG files to be created for each inbound network request. This produces finer-detailed audit trails, and your accounting records (if accounting is enabled) will reflect individual connections. o Use of FAL$LOG will not show VMS error messages, instead it generates DAP status codes. The following table shows some typical DAP codes and their corresponding VMS error messages: DAP CODE Meaning ------------ -------------------------------------------------------- Success: "File Access was Terminated with No Bits Set on Close" 4020: Directory Not Found 4030: File Locked by Another User 4032: File Not Found 4055: Insufficient Privilege or File Protection Violation 4086: Invalid Channel [Poor Man's Routing Disabled] 4097: Syntax Error in Filename 10D7: \ 10D9: > Related to Sending Mail Across Nodes 5D60: / -------------------------------------------------------------------------------- Ron Tencati ARPA: TENCATI%JPLGP.SPAN@VLSI.JPL.NASA.GOV Manager, Computer & Network Security Jet Propulsion Laboratory ARPA: TENCATI@GPVAX.JPL.NASA.GOV Pasadena, Ca. 91109 SPAN: JPLGP::TENCATI (818) 354-8359 BitNet: TENCATI%GPVAX.JPL.NASA.GOV@HAMLET --------------------------------------------------------------------------------