..... REMOTE ANSWERS modified at 18:13:55 on 93/09/14 GMT (by RAGAN at AUSVM1) :ndx. :abs. ----- REMOTE ANSWERS appended at 00:29:15 on 93/06/15 GMT (by RAGAN at AUSVM1) ..... REMOTE ANSWERS modified at 17:26:29 on 93/06/16 GMT (by RAGAN at AUSVM1) :ndx.MODEM001 :abs.COMMON PROBLEM #1: "Modem failed to initilize" error :key.RLA TBIRD modem :QUESTION. What do I do if I get the error message: "Modem failed to Initilize."? :ANSWER. **************************************************************** Common problem #1: *************************************************************** SYMPTOM: Error message upon starting RLA: -------------------------------------------- INFORMATION Modem could not be initialized. Port Manager: xxxxxx Port: COM1 Local Number: xxx-xxxx -------------------------------------------- When you try to dial from the phonebook you get the message: ----------------------------------------------- No ports are available for the call to... ----------------------------------------------- SOLUTIONS: 1) A common problem occurs when an unsupported modem is used. Step #6 details how to configure for an unsupported modem. This is a technically difficulty step, so you may want to confirm Steps #2 through #5 are completed correctly before attempting Step #6. 2) You may have a bad modem cable, switch it out with another modem cable, or test your COMport/cable/modem connection with an async emulation package to confirm this connection is working. 3) You may have failed to configure a modem and a COM port correctly. To re-configure the COM port and Modem correctly, please follow these steps: Start RLA (double click on the RLA icon). Wait 45 seconds for RLA to start. Open the workstation icon as Settings. Wait 60 seconds for the Settings notebook to open. Select on the Ports tab. Delete any ports you may have put in. Select the Modems tab. Delete any modems you may have put in. Select the Ports tab. Select the Add pushbutton. Select OK, accepting the Async Comm Adapters Select the COM port you need, e.g., COM1 Double click on the System Menu in the upper left-hand corner to close the - notebook. Select the Modems tab. Select the Add pushbutton. Select your modem from the list box entitled: Available modem types. If your modem is not listed, see STEP #6 below. Select OK Select Add from the - Settings notebook. Type in a telephone number in the "Phone number" entry field Select OK Select from the ports configured, e.g., COM1 Select OK Double click in the upper left-hand corner to close the - notebook with only the Ports chapter. Double click in the upper left-hand corner to close the main Settings notebook. Stop all applications that are running, Shutdown your workstation, press Ctrl+Alt+Del to re-start your workstation. 4) You may have a workstation that is non-FIFO, supporting only COM port speeds under 9.6Kbps. To see if your workstation is non-FIFO, type at the OS/2 command line: MODE COM1 4a) If the system response is: BUFFER = AUTO (or anything other than N/A) then you have a FIFO machine. You have a FIFO workstation supporting faster speeds, move to step #5. 4b) If the system response is: BUFFER = N/A then you have a non-FIFO machine (that will only support modem speeds of 9.6 or lower). Complete the following steps for your non-FIFO machines. WARNING: Complete the sequence below, ONLY if you have a good understanding of editing System configuration files. Stop RLA, close all RLA windows. Using your favorite ASCII editor, edit the WCLNET.INI file in the \WAL subdirectory. For the parameter labeled: SerialPortSpeed = change the number to 9600 so the entire line will now read SerialPortSpeed = 9600 Save the file, then re-start RLA. 5) You may have a modem that is configured (via the modem switches) to run at a lower speed. Edit the WCLNET.INI file as described in STEP #4b. 6) Configuration of non-supported modems. If you have a modem that is not contained in the RLA Settings, Modem, "Available modem types", then you will need to either: > locate a modem that is supported <<< an easy solution > proceed with the following hand editing of RLA configuration files based upon information you research in the modem's user manuals <<<< not an easy solution. *** WARNING: do not attempt to carry out the following steps unless you have advanced knowledge of communications, OS/2 configuration files, and modems. Here are the steps to add a non-supported modem: 6.1) Close all RLA windows. At an OS/2 command prompt, type C: CD WAL COPY ASYNCSW.PIF MYMODEM.PIF EPM MYMODEM.PIF Locate and modify the following parameters in this file: the very first line: MYMODEMŁ PIF = MYMODEM.PIF Title = "My newly configured modem" scroll down the file until you find: AutoBaudDetectŁ Default = SerialPortSpeedŁ Default = Initialization1Ł Default = Initialization2Ł Default = These parameters vary from modem to modem with a specific brand of modem, and vary considerably between brands of modems. Only the modem manual can give you the values that fit each of these parameters. You can contact the modem company for further information on these values. Once the new file has been created and edited, you will now need to enter the RLA user interface Settings to use this file to configure your RLA workstation correctly. 6.2) Save the MYMODEM.PIF file Shutdown and re-start your workstation. Start RLA (double click on the RLA icon). Wait 45 seconds for RLA to start. Open the workstation icon as Settings. Wait 60 seconds for the Settings notebook to open. Select the Ports tab. Delete any ports you may have put in. Select the Modems tab. Delete any modems you may have put in. Select the Ports tab. Select the Add pushbutton. Select OK, accepting the Async Comm Adapters Select the COM port you need, e.g., COM1 Double click on the System Menu in the upper left-hand corner to close the - notebook. Select the Modems tab. Select the Add pushbutton. Select your new modem from the list box entitled: Available modem types, you new modem should be entitled: MYMODEM. If your modem is not listed you have not done STEP 6.1 correctly, repeat STEP 6.1. Select OK Select Add from the - Settings notebook. Type in a telephone number in the "Phone number" entry field (don't forget to add numbers such a 9 to dial out, etc.) Select OK Select a port from the ports configured list, e.g., COM1 Select OK Double click in the upper left-hand corner to close the - notebook, with the single Ports chapter. Double click in the upper left-hand corner to close the main Settings notebook. Stop all applications that are running, Shutdown your workstation, press Ctrl+Alt+Del to re-start your workstation. If you continue to have the same symptom as stated at the top of this note, please respond back to us with a further request for assistance. :from.Rick Ragan, IBM Austin, TX ----- REMOTE ANSWERS appended at 16:56:53 on 93/06/15 GMT (by RAGAN at AUSVM1) ..... REMOTE ANSWERS modified at 21:18:10 on 93/06/15 GMT (by RAGAN at AUSVM1) :ndx.INFO_001 :abs.COMMON PROBLEM #2: Domain Controller not Available, part 1/2 :key.RLA TBIRD Doamin Controller Bridge LAPS :QUESTION. What do I do if I get the error messages: Domain Controller not Available, or The Server is not responding? :ANSWER. Part 1 of 2 for Common Problem #2. **************************************************************** Common problem #2: Cannot logon to the Server *************************************************************** SYMPTOMS: RLA starts correctly, without error messages. RLA dials correctly, establishing a connection: > No dial error messages. > Modem lights flash at both workstations. However, you cannot get IBM LAN Requester at the RLA remote workstation to logon to the IBM LAN Server at the RLA Server workstation. You may often get the messages: ------------------------------------- Domain Controller not Available. ------------------------------------- or ------------------------------------- The Server is not responding. ------------------------------------- SOLUTIONS A--Bridge is not configured at the server. B--Timeout value is too small C--Pre-existing bug in BRIDGFH.OS2 device driver. D--IBM LAN Server/Requester 2.0 incompatibility Below are two step-by-step solutions for RLA configuration from Binh Tran - "Mr. Configuration." SOLUTION A -- BRIDGE IS NOT CONFIGURED AT THE SERVER. This problem may indicate the RLA Server has not been configured correctly. Philosophy: Sometimes users will assume that since the RLA Remote Workstation installation process installs code AND configures the communications parameters, that the RLA Server Workstation installation process also configures the RLA Server. RLA Server configuration is not automatic and must be accomplished via the RLA Settings notebook as explained below. CONFIGURATION FOR A RLA SERVER 1) Install the RLA Server code. 2) Stop all programs, shutdown your workstation, and reboot your workstation (Ctrl+Alt+Del). 3) At an OS/2 command prompt, change to the \IBMCOM subdirectory and run LAPS, type: LAPS The LAN Adapter and Protocol Support configuration window will appear. Select the "Configure" pushbutton on the IBM LAPS Logo window. Select the "Configure LAN Transports" item, then select the "Continue..." pushbutton on the Configuration message window. 4) You should now be at the main LAPS configuration window entitled: "Configure Workstation" Configure LAN Transports as follows: In the List box entitled "Current Configuration" select the "IBM OS/2 NETBIOS" entry for the "IBM Token-Ring Network Adapter", then select the "Change Number" pushbutton and select 0 on the "Change Logical Adapter Number" window. Select the "Change" pushbutton. Repeat this process for the "IBM OS/2 NETBIOS" entry for the "remote LAN access Logical Adapter", making this adapter number 1. You should now have a "Current Configuration" list box with the following information in it: +--------------------------------------------+ | IBM Token-Ring Network Adapter....... | | 0 - IBM OS/2 NETBIOS | | remote LAN access Logical Adapter....... | | 1 - IBM OS/2 NETBIOS | +--------------------------------------------+ 5) Placement of Protocols. Philosophy: The remote workstation's application protocols should be located at the RLA remote workstation, not at the RLA Server. Only applications that will be run from the RLA Server should have protocols configured to exist at the Server. For example, if you plan to run 3270 emulation via Communications Manager, you do not place the 802.2 protocol at the RLA Server. Only the RLA remote workstation needs this protocol. If you place an unnecessary protocol at the RLA Server, there is a bug in the RLA first beta code that may cause a Trap D at component PDFH$. This bug will be fixed in the second beta. 5.1) Delete all unnecessary protocols from the RLA Server. Do not place any protocols here in an effort "to match" the RLA remote workstation with this RLA Server. 6) After you have changed the Adapter Numbers and deleted any unnecessary protocols, select the OK pushbutton located in the lower right-hand corner of the "Configure Workstation" window. Select the Exit pushbutton on the IBM LAPS Logo window. Select the Continue... pushbutton on the CONFIG.SYS Update message window. Select OK to CONFIG.SYS Updated message window. Select the Exit pushbutton at the Exiting LAPS message. This configuration will allow you to bridge from the RLA Wide Area LAN to the Token-Ring LAN. In other words, once RLA makes a connection between the RLA Remote and the RLA Server, the RLA Server then must bridge the Remote's frames onto the physical LAN via the TR adapter. By making the TR adapter 0 and the RLA adapter 1, you instruct the RLA Server to bridge from the WAN to the LAN. 7) Double click on the RLA icon to start RLA Server. 8) Open as > Settings 9) Click on the Answer Chapter 10) Select PSTN_ALL_CALLS in the List Box. (PSTN is async and sync. ISDN is digital telephone lines). 11) Select the Change pushbutton. 12) If you want to have the RLA Server put itself into Answer Mode when RLA starts up, check the "Enable answer mode on startup" checkbox. If you choose not to enable answer mode on startup, then you will need to select the Start Mode pushbutton within the Answer chapter in order to place the RLA Server in Answer mode. This pushbutton's effect lasts until you select the Stop Mode pushbutton, or until you stop RLA. 13) Double click on the System Menu in the upper left-hand corner of the Answer Criteria notebook to close and save these changes. 14) Configure the Ports and modems via the following steps: Select on the Ports tab. Delete any ports you may have put in. Select the Modems tab. Delete any modems you may have put in. Select the Ports tab. Select the Add pushbutton. Select OK, accepting the Async Comm Adapters Select the COM port you need, e.g., COM1 Double click on the System Menu in the upper left-hand corner to close the - notebook. Select the Modems tab. Select the Add pushbutton. Select your modem from the list box entitled: Available modem types. If your modem is not listed, see Common Problems #1, Step #6. Select OK Select Add from the - Settings notebook. Type in a telephone number in the "Phone number" entry field Select OK Select from the ports configured, e.g., COM1 Select OK Double click in the upper left-hand corner to close the - notebook with only the Ports chapter. 15) Click on the Bridge chapter. 16) Click once on the right-hand pointing arrow at the bottom right-hand corner of the notebook to move to Page 2. 17) Type the LAN segment ring number. While the default is 1, if you plan to run 3270 terminal emulation, this number must represent the LAN segment ring number to which the RLA Server is attached. 18) Click on the Workstation chapter. 19) You can type any name for the RLA Server (optional), type the desired name in the "Local RLA workstation name" entry field. 20) Double click on the System Menu in the upper left-hand corner of the main RLA Settings notebook to close and save these changes. 21) Double click on the System Menu in the upper left-hand corner of the RLA Workstations window to stop RLA. 22) Stop all applications, shutdown your workstation, Ctrl+Alt+Del your workstation. continued on Part 2 of 2... :from.Rick Ragan, IBM Austin, TX. ----- REMOTE ANSWERS appended at 16:59:13 on 93/06/15 GMT (by RAGAN at AUSVM1) ..... REMOTE ANSWERS modified at 21:18:48 on 93/06/15 GMT (by RAGAN at AUSVM1) :ndx.INFO_002 :abs.COMMON PROBLEM #2: Domain Controller not Available, part 2/2 :key.RLA TBIRD Doamin Controller Bridge LAPS :QUESTION. What do I do if I get the error messages: Domain Controller not Available, or The Server is not responding? :ANSWER. Part 2 of 2 for Common Problem #2. SOLUTION B) -- TIMEOUT VALUE IS TOO SMALL Philosophy: A 4Mbps LAN send LAN frames around the LAN wire at very fast speeds. Once you introduce IBM RLA into the LAN as a virtual TR node, the LAN must slow down to accommodate this remote client operating at 14.4Kbps speeds (this slow WAN speed is 0.00036% of the faster LAN speed) IBM LAN Requester/Server assumes the LAN applications will run at 4Mbps speeds. The Netbios timers (TI, T1, and T2) of the LAN workstations are defaulted for the 4Mbps LAN speed. IBM remote LAN access modifies these values for 19.2Kbps in order to introduce the slower remote client. You may have to further modify these values for even slower telephone line speeds. 1) Increase the T timers in the PROTOCOL.INI file, see below. 2) Make sure the 15 bit in the SRVHEURISTICS parameter in the IBMLAN.INI file is a 1, it should not be a 0. The first bit for this Netbios timeout value is 0, so you count from 0th bit to 15th bit. These values should be adjusted on the IBM RLA remote workstation and RLA server, and also ALL the LAN Workstations or Servers (LAN Server, LOTUS Notes server, etc) that will communicate with the RLA remote workstation. Here are the suggested settings for the PROTOCOL.INI file for modems extending as low as 9600Kbps: DEFAULT IBM RLA TI = 30,000 60,000 Inactivity timer T1 = 500 10,000 Response timer T2 = 200 2,000 Acknowledgement timer PLEASE NOTE: Low speed modems are supported primarily for remote workstation to remote workstation, not for remote workstation to LAN. 9.6 Kbps modems or higher are recommended for the Remote to LAN environment due the inherent nature of LAN Timers. The lower the line speed, the higher the LAN Timer value needs to be set, which may lead to LAN performance problems. Some modems will start at a high line speed and negotiate down to lower line speeds until the line errors are corrected. You could have a 14.4Kbps modem that has an effective line speed well below 9600Kbps. SOLUTION C) -- PRE-EXISTING BUG IN BRIDGFH.OS2 DEVICE DRIVER. If you have configured the RLA server correctly and modified your timer values to match the speed of your modems, you may be experiencing a bug in the IBM RLA code. The bug manifests itself with LANs having even number of hops. You will receive the errors listed at the beginning of this note if your LAN destination workstation is an even number of hops (bridges) from your RLA Server. For instance, if there are two bridges between your RLA Server and your Communications Manager SNA gateway, then the hop count is 2 and your will not access the SNA gateway, but will receive one of the error messages listed above. Please request the fix module BRIDGFH.OS2 on this forum with the following VM command: REQUEST BRIDGE FROM BETASRUS AT AUSVM1 SOLUTION D) -- IBM LAN SERVER/REQUESTER 2.0 There is a further bug in the RLA 1st Beta that prevents RLA from working with LAN Server/Requester 2.0. If you use this application, you will receive the messages at the beginning of this note. Please install IBM LAN Server/Requester 3.0 or higher. You are now ready to start the RLA Server and receive calls from the RLA Remote Workstation. Please remember this first Beta for RLA does not contain security, so your RLA Server may be vulnerable to others dialing into your server. :from.Rick Ragan, IBM Austin, TX. ----- REMOTE ANSWERS appended at 17:06:01 on 93/06/15 GMT (by RAGAN at AUSVM1) ..... REMOTE ANSWERS modified at 13:58:43 on 93/07/13 GMT (by RAGAN at AUSVM1) :ndx.INFO_003 :abs.COMMON PROBLEM #3: LAPS on the Remote Workstation. :key.TBIRD RLA LAPS remote workstation :QUESTION. What do I do if I get the following error messages: " An error occurred while opening network device driver NET1=NETBEUI$" or "The REQUESTER service could not be started"? :ANSWER. *************************************************************** Common problem #3: LAPS configuration *************************************************************** SYMPTOMS: RLA starts correctly, without error messages. RLA dials correctly, establishing a connection: > No dial error messages. > Modem lights flash at both workstations. However, you cannot get > IBM LAN Requester or > 3270 Communications Manager to work. Error messages: IBM LAN Requester places info into CONFIG.SYS that will fail at boot time with the following words: ---------------------------------------------------------------- Net3406 :An error occurred while opening network device driver NET1 = NETBEUI$ SYS1719: The file "C:\IBMLAN\NETWKSTA.200" specified in the IFS command on line (94) of the CONFIG.SYS file does not contain a valid device driver or file system driver. ---------------------------------------------------------------- or When the IBM LAN Requester starts up: --------------------------------------------------------------- The REQUESTER service could not be started. NET3060: The service did not respond to a control signal and was stopped with the DosKillProc function. --------------------------------------------------------------- or If you are trying to run 3270 emulation (Communication Mgr): --------------------------------------------------------------- ACS 2390 ALERT: An unexpected OS/2 function call or 802.2 LAN Transport error has closed the logical LAN adapter. (This is a full screen message, white letters, black background) ---------------------------------------------------------------- Below are two step-by-step solutions for RLA configuration from Binh Tran - "Mr. Trouble Shooter." PROBLEM -- LAPS is not configured correctly. The problem is that when you configured for LAPS, you deleted the Token Ring adapters at 0 (zero) and added protocols to the RLA logical adapter as 1 (one). Philosophy: The applications should be configured to run on the remote machine just as if they were running at any LAN workstation. Thus, the protocols (NETBIOS, 802.2, etc) must be located at the RLA remote workstation, not at the RLA Server. Secondly the RLA remote workstation expects to use the RLA logical adapter 0. SOLUTION: LAPS CONFIGURATION FOR A RLA REMOTE WORKSTATION 1) At an OS/2 command prompt, change to the \IBMCOM subdirectory and run LAPS, type: LAPS The LAN Adapter and Protocol Support configuration window will appear. Select the "Configure" pushbutton on the IBM LAPS Logo window. Select the "Configure LAN Transports" item, then select the "Continue..." pushbutton on the Configuration message window. 2) You should now be at the main LAPS configuration window entitled: "Configure Workstation" Configure LAN Transports as follows: In the List box entitled "Current Configuration" select the 1 - IBM OS/2 NETBIOS protocol and select the Remove pushbutton, select the Yes pushbutton to remove this protocol. Repeat the same steps for the remote lan access Logical Adapter... In the List box entitled "Current Configuration" select the IBM Token-Ring Network adapters In the list box entitled "Network Adapters" select the remote lan access Logical Adapter... Select the Change pushbutton under the list box entitled "Network Adapters" in order to make the "IBM Token-Ring Network adapters" switch to "remote lan access Logical adapter." You should now have a "Current Configuration" list box with the following information in it: +--------------------------------------------+ | remote LAN access Logical Adapter....... | | 0 - IBM OS/2 NETBIOS | | 0 - etc | | 0 - etc | +--------------------------------------------+ The applications that will run on your remote workstation will now run on adapter 0 instead of adapter 1. 3) Let's make sure that your protocols under the RLA logical adapter are clean. In the list box entitled "Current Configuration" select the 0 - IBM OS/2 NETBIOS protocol. Select the Edit pushbutton. You now see the "Parameters for IBM OS/2 NETBIOS" dialog box. Delete all information from the "Network adapter address" entry field. Repeat Step #3 for each of the protocols under the remote LAN access Logical Adapter. Do not delete the critical network adapter address for the remote lan access Logical Adapter. This adapter must have a destination address. 4) OK pushbutton located in the lower right-hand corner of the "Configure Workstation" window. Select the Exit pushbutton on the IBM LAPS Logo window. Select the Continue... pushbutton on the CONFIG.SYS Update message window. Select OK to CONFIG.SYS Updated message window. Select the Exit pushbutton at the Exiting LAPS message. :from.Rick Ragan, IBM Austin, TX ----- REMOTE ANSWERS appended at 17:08:28 on 93/06/15 GMT (by RAGAN at AUSVM1) ..... REMOTE ANSWERS modified at 16:37:02 on 93/11/30 GMT (by RAGAN at AUSVM1) :ndx.INFO_004 :abs.COMMON PROBLEM #4: Leased Line or Null Modem problems :key.RLA TBIRD Null Modem, Leased line :QUESTION. What do I do if I have problems with Leased line or null modem configuration? :ANSWER. *************************************************************** Common problem #4: Null modem (cable) configuration *************************************************************** | 11/30/93 - All of the configuration information below has been revised. PROBLEM: Cannot get Null modem configured. PHILOSOPHY: A null modem is a type of cable connecting two workstations in close proximity without using modems. The LAN Distance product allows for a null modem connection. This solution can be used to test your LAN Distance installation and configuration. If you are trying to use modems not listed in the Available modem types list box, you can confirm, by using a Null modem connection, that the problems you may be experiencing are do to the mis-match between your modem hardware and the Modem type you have selected. There are steps in the LAN Distance documentation to use modems not listed with the LAN Distance product. For null modem configurations you must set the values: Ports ---------------- Switched Modems ----------- Non-switched Phonebook -------- Non-switched Answer criteria -- Non-switched SOLUTION: Null modems steps and wiring: For the LAN Distance Connection Server: Open as Settings Select the Ports tab, a Ports - Settings notebook will appear. Delete all ports. Select the Add Pushbutton and select a port with a "switched" (this is not a typo) Line Type. Close this notebook. Select Modems tab Delete all modem types Select the Assign push button Select "Null Modem" in Available modem types list box. On the Notebook that appears (xxxxx modem ---Settings). Select Add... to add a Port, the dialog box Null Modem - Settings will appear. Non-switched is selected, for "Permanent connection name" type a name that matches on both the Connection Server *and* the Remote workstation. Select OK. For the next Notebook that appears assign the COM port (if there are multiple COM ports make sure you choose the switched COM port). Select OK, close the Null Modem - Settings notebook. Select the Answer tab Select the Add push button. On the next dialog box select Network Type of "PSTN" and Line Type of "Non-switched." Select OK. On the Notebook that appears (Answer mode criteria -- Settings) for "Answer mode name" type in any unique descriptive name and select "Enable answer mode on startup", close this notebook. Close Settings Shut down and re-start your workstation. For the LAN Distance Remote workstation: Open as Settings Select the Ports tab, a Ports - Settings notebook will appear. Delete all ports Select the Add Pushbutton and select a port with a "switched" (this is not a typo) Line Type. Close this notebook. Select Modems tab Delete all modem types Select the Assign push button Select "Null Modem" in Available modem types list box. On the Notebook that appears (xxxxx modem ---Settings). Select Add... to add a Port, the dialog box Null Modem - Settings will appear. Non-switched is selected, for "Permanent connection name" type a name that matches on both the Connection Server *and* the Remote workstation. Select OK. For the next Notebook that appears assign the COM port (if there are multiple COM ports make sure you choose the switched COM port). Select OK, close the Null Modem - Settings notebook. Select the Phonebook tab Select the Add pushbutton Select PSTN for "Network type" and Non-Switched for "Line type". On the Notebook that appears (Phonebook -- Settings) type a unique and descriptive "Entry Name". On the Phonebook - Settings notebook, select the Connect tab. The "Modem" entry field has Null Modem pre-filled, and the "Leased Line" entry field name is pre-filled. Close this notebook. Close Settings Shut down and re-start your workstation. Start both Remote and Connection Server workstations Start LAN Distance on both Remote and Connection Server workstations. Dial from the LAN Distance Remote workstation to the LAN Distance Connection Server workstation. THE NULL MODEM CABLE WIRING NOTE: You can obtain this modem cable from Radio Shack stores. There are over four types of Null modem cables. Make sure your null modem cable has the following wiring when you are using a null modem for the LAN Distance product. (FG) 1----------------------1 (FG) Pin 1 straight through (TD) 2----------------------3 (RD) Pin 2 and 3 are crossed (RD) 3----------------------2 (TD) (RTS) 4----------------------5 (CTS) Pin 4 & 5 are crossed (CTS) 5----------------------4 (RTS) (SG) 7----------------------7 (SG) Pin 7 straight through (DSR) +--6 6---+ (DSR) Pin 6 & 8 together to | | Pin 20 of the other side (CD) +--8----------------------20 | (DTR) | (DTR) 20-----------------------8---+ (CD) :from.Rick Ragan, IBM Austin, TX ----- REMOTE ANSWERS appended at 17:11:01 on 93/06/15 GMT (by RAGAN at AUSVM1) :ndx.INFO_005 :abs.COMMON PROBLEM #5: IBM LAN Server/Requester copy large files :key.RLA TBIRD LAN Server, large files copy :QUESTION. What do I do if I have problems with my IBM LAN Server/Requester system when I try to copy large files? :ANSWER. *************************************************************** Common problem #5: Large File copy with IBM LAN Server *************************************************************** SYMPTOMS: RLA starts correctly, without error messages. RLA dials correctly, establishing a connection: IBM LAN Requester works correctly. When you try to copy files larger than 2 Kbytes, or XCOPY a lot of files, you may have one of the following problems. Error messages: ---------------------------------------------------------------- REQUESTER NET3193: A virtual circuit error occurred on the session to STLCORE. The NCB command and return code are the data. 96 18 ---------------------------------------------------------------- or ---------------------------------------------------------------- REQUESTER NET3190: Netwksta Internal Error. NCB Done msg incomplete in redir NCB! 06 00 A virtual circuit error on the session to ***. The NCB command and return code are the data. ---------------------------------------------------------------- or ---------------------------------------------------------------- The results of a large file copy simply does not complete, leaving the file partially copied, or XCOPY does not copy all files. ---------------------------------------------------------------- or ---------------------------------------------------------------- Failed logon attempts. Domain not available. ---------------------------------------------------------------- These solutions are from the technical minds of Steve Tipton and Binh Tran. PROBLEM The problem is that the blocks of data that the IBM LAN Server sends to the IBM LAN Requester over the WAN link are too large for the slow WAN link to handle. The IBM LAN Timers and Block sizes must be modified. Philosophy: A 4Mbps LAN send LAN frames around the LAN wire at very fast speeds. Once you introduce IBM RLA into the LAN as a virtual TR node, the LAN must slow down to accommodate this remote client operating at 14.4Kbps speeds (this slow WAN speed is 0.36% of the faster LAN speed) SOLUTION #A: -- TIMEOUT VALUE IS TOO SMALL FOR THE LAN WARNING: Please back up any file that you plan to modify. If you make the changes to your files as described below, you will be modifying the performance of your LAN. Do not attempt these procedures unless you have a good understanding of LANs, control files, and data communications. IBM LAN Requester/Server assumes the LAN applications will run at 4Mbps speeds. The Netbios timers (TI, T1, and T2) of the LAN workstations are defaulted for the 4Mbps LAN speed. IBM remote LAN access modifies these values for 19.2Kbps in order to introduce the slower remote client. You may have to further modify these values for even slower telephone line speeds. Back up any files BEFORE you start to modifying them. 1) THE IBM LAN SERVER'S IBMLAN.INI FILE: Make sure the 15 bit in the SRVHEURISTICS parameter in the IBM LAN Server's IBMLAN.INI file is a value from 1 to 9, it should not be a 0. The first bit for this Netbios timeout value is 0, so you count from 0th bit to 15th bit. A useful way to adjust this bit is to first set the bit to 9. This sets the Netbios timer to infinite. Once you have done this, retry the COPY or the XCOPY command. If the LAN Server was timing out, the problem should disappear. If you still cannot copy, remove the SMB RAW bits for the workstation (See SOLUTION B below). After removing these values, you can decrease the timer value (the 15th bit) until you reach a timer value that maximizes the IBM LAN Server's performance while still allowing large files to be copied over the LAN. (NOTE: The Timeout is the same for values 2 to 8.) 2) THE IBM LAN SERVER'S IBMLAN.INI FILE: If you are receiving the message regarding failed Logon attempts, you may also wish to change SRVHEURISTICS bit 15 to a 9. 3) THE IBM LAN REQUESTER'S IBMLAN.INI FILE: In the IBM LAN Requester's IBMLAN.INI file, increase the SESSTIMEOUT = value to a range of 45 to 200. Increasing this value will help keep the transmits and receives from timing out due to slow WAN speeds. 4) THE IBM LAN SERVER AND REQUESTER'S PROTOCOL.INI FILE: The values listed below may be increased above the IBM RLA values. Here are the suggested settings for the PROTOCOL.INI file for modems extending as low as 9600Kbps: DEFAULT IBM RLA TI = 30,000 60,000 Inactivity timer T1 = 500 10,000 Response timer T2 = 200 2,000 Acknowledgement timer These values should be adjusted on the IBM RLA remote workstation and RLA server, and also ALL the LAN Workstations or Servers (LAN Server, LOTUS Notes server, etc) that will communicate with the RLA remote workstation. SOLUTION B) -- KNOWN BUG WITH IBM LAN REQUESTER: APAR IC04667 exists. This is a time out problem when copying large files from the IBM LAN Requester. NET3190 error typically occurs due to this error. A work-around is to adjust the IBM LAN Requester's SMB RAW WRKHEURISTICS values in the IBMLAN.INI file. Make sure the 11th, 12th, and 13th bits for the WRKHEURISTICS parameter in the IBM LAN Requester's IBMLAN.INI file are set to 0. The first bit for this Netbios timeout value is 0, so you count from 0th bit to 11th bit, etc. Make this change only for the IBM LAN Requester, so only the remote operations are affected. Locally LAN-attached workstations will have better performance if the IBM LAN Server's WRKHEURISTICS bits are left on. New NETWKSTA.200 and MFSD20.SYS files will soon be available for this APAR. Call 1-800-237-5511 to request this fix. :from.Rick Ragan, IBM Austin, TX ----- REMOTE ANSWERS appended at 15:57:51 on 93/06/16 GMT (by RAGAN at AUSVM1) :ndx.MODEM002 :abs.Constructing Modem Strings for unsupported RLA modems :key.RLA TBIRD Modem strings :QUESTION. If I have a modem that is not supported by RLA, how do I construct a modem string on my own? :ANSWER. Subject: Modem String Construction Rules for non-RLA modems Addition of steps 2-8 below, 6/1/93. This is a complete listing thanks to our RLA async team. Please refer to Common Problem #1, Step 6.1 to modify the modem string (in order to create a .PIF file for your modem that RLA does not support currently). The modem initialization string should contain commands so that the modem controls the RS-232 signals in the following way. RLA Modem String Construction rules: 1) Do not attempt to construct modem strings unless you have a good understanding of modems and configuring communications software. 2) DTR - When DTR drops, the modem hangs up and goes to the command state. The modem does NOT do a reset when DTR drops. The modem should not answer the phone when DTR is low. For almost all modems the correct command is &D2. 3) CD - CD tracks the carrier signal from the remote modem. For almost all modems the correct command is &C1. Note: Some modem manuals refer to CD as DCD or RLSD. 4) DSR - DSR follows standard RS-232 operation. DSR must drop when a connection terminates. For almost all modems the correct command is &S1. 5) RTS/CTS - Modem uses bidirectional hardware (RTS/CTS) flow control. For some modems the correct command is \Q3, however the correct command for this behavior varies widely from modem to modem. Note: Some modem manuals refer to CTS as RFS. 6) The speed between the modem and the computer is fixed. The connect speed over the phone line may change per connection, but the speed between the computer and the modem never changes. 7) The modem buffers data between the computer and the phone line. 8) The modem answers an incoming call on the second ring. The correct command for this is S0=2. 9) Never assume factory defaults are correct. 10) If Initialization 2 is too long move part of the sting to Initialization 1. 11) Character echo enable 12) Full duplex 13) Speaker on until carrier detected 14) Result codes displayed as words (verbal mode) 15) Modem negotiates highest possible link rates with remote mode. In the "You too can contribute to RLA" department, we would like for those of you out there who have successfully created .PIF files for your non-RLA supported modems to send these PIF files to me, we will make them available to the RLA Beta community, and if they are confirmed by others to work, then the modem string you construct will go into the RLA final product! :from.Rick Ragan, IBM Austin, TX ----- REMOTE ANSWERS appended at 20:30:48 on 93/06/18 GMT (by RAGAN at AUSVM1) ..... REMOTE ANSWERS modified at 16:45:39 on 93/07/13 GMT (by RAGAN at AUSVM1) :ndx.NETWR001 :abs.COMMON PROBLEM #6: Configuring IBM RLA for Netware :key.NETWARE Novell, TBird, configuration :QUESTION. How do I configure my Novell software to run with IBM RLA? :ANSWER. **************************************************************** COMMON PROBLEM #6: Novell NetWare Server/Requester configuration **************************************************************** I will detail the specific steps in the near future, but for now, here are the general details for configuring IBM remote LAN access for NetWare. This information is brought to you by Mike Gibson. Configuring Novell NetWare for IBM remote LAN access NOVELL SERVER: To configure the Novell Server for connecting with the OS/2 RLA Server: 1) Have a Novell LAN with Token Ring adapters 2) At the Novell Server type: LOAD ROUTE BOARD=x (Where x is the LAN adapter number the Novell Server will use to communicate with the OS/2 RLA Server.) This command adds the source routing bridge information to the LAN frames (ROUTE.NLM). NOVELL REQUESTER: To configure the Novell Requester to run over the OS/2 RLA Remote workstation: 1) Have OS/2 2.x installed 2) Have Novell NetWare Requester installed. Choose the Network Interface Card Driver: TOKEN.SYS This action places the ROUTE.SYS device driver into CONFIG.SYS so that the LAN frames will have the source routing information in it that IBM RLA requires to run. 3) Have IBM RLA installed (always install RLA last) Make sure before doing the following steps you have installed the Novell NetWare Requester. 4) Using LAPS, configure the remote LAN access logical adapter to have the following protocol: 0 - NetWare Requester Support 5) Using LAPS, configure the NetWare Requester Support protocol to match the network address of the RLA logical adapter. 6) Using LAPS, configure the NetWare Frametype so that the frame type of the NetWare Requester is the same as the frame type of the NetWare Server that will be accessed. If you have a Token-Ring network, the TOKEN-RING frame type is the most common, to choose this frame type set this entry field to "yes". If you have an Ethernet network, the ETHERNET_802.3 frame type is most common, to choose this frame type set this entry field to "yes". ERROR: Once you have configured and re-booted your IBM RLA workstation you may receive the NetWare message: NWD0115: Error getting connection ID (0X880F). REASON: The Novell Requester has been started through CONFIG.SYS and cannot find the Novell Server until after IBM RLA has dialed and connected. SOLUTION: With your favorite ASCII editor, comment out (place the letters REM and a space at the beginning of) the line in your remote workstation's CONFIG.SYS file: RUN C:\NETWARE\NWDAEMON.EXE Shutdown, and re-start your workstation. Dial RLA. As RLA connects, and before you attempt to logon to the server, type from the command line: START C:\NETWARE\NWDAEMON.EXE This will allow the Novell Requester to connect with the Novell Server without displaying the error message. :from.Rick Ragan, IBM Austin ----- REMOTE ANSWERS appended at 23:47:59 on 93/06/22 GMT (by RAGAN at AUSVM1) ..... REMOTE ANSWERS modified at 16:30:30 on 93/06/23 GMT (by RAGAN at AUSVM1) :ndx.LAPS_001 :abs.COMMON PROBLEM #7: LAPS for RLA Remote and Server, part 1/3 :key.RLA TBIRD LAPS :QUESTION. How do I configure LAPS for IBM remote LAN Access? :ANSWER. *************************************************************** Common problem #7: LAPS for RLA Remote and Server, part 1/1 *************************************************************** Common Problem #7, part 1 of 3... This information will assist you if you wish to run NetBIOS applications such as IBM LAN Requester, 802.2 applications such as Communications Manager, TCP/IP applications, or Novell NetWare Requester on IBM remote LAN access. The information below describes how to use LAPS and what should appear in both the RLA Remote and Server's PROTOCOL.INI files. For the sake of a starting point we will assume you have: > Set up a workstation currently located on the LAN, that will be converted to a "remote workstation." > Installed your applications > Installed IBM remote LAN access (always do RLA last) > The LAN applications are configured for LAN adapter 0 > Now are looking at LAPS or PROTOCOL.INI This information has been brought to you by Binh Tran and Rick Ragan. ---------------------------------------------------------------- LAPS CONFIGURATION FOR A RLA REMOTE WORKSTATION >> RLA Remote Workstation << ---------------------------------------------------------------- Philosophy for the RLA Requester: The applications should be configured to run on the RLA remote machine just as if they were running on any LAN workstation. Thus, the protocols (NETBIOS, 802.2, etc) must be configured at the RLA remote workstation, not at the RLA Server. STEPS FOR LAPS CONFIGURATION: (See assumptions for starting point above) 1) At an OS/2 command prompt, change to the \IBMCOM subdirectory and run LAPS, type: LAPS The LAN Adapter and Protocol Support configuration window will appear. Select the "Configure" pushbutton on the IBM LAPS Logo window. Select the "Configure LAN Transports" item, then select the "Continue..." pushbutton on the Configuration message window. 2) You should now be at the main LAPS configuration window entitled: "Configure Workstation" Configure LAN Transports as follows: In the List box entitled "Current Configuration" select the 1 - IBM OS/2 NETBIOS protocol and select the "Remove pushbutton," select the "Yes" pushbutton to remove this protocol. Repeat the same steps for the remote LAN access Logical Adapter... In the List box entitled "Current Configuration" select the IBM Token-Ring Network adapters In the list box entitled "Network Adapters" select the remote LAN access Logical Adapter... Select the "Change" pushbutton under the list box entitled "Network Adapters" in order to make the "IBM Token-Ring Network adapters" switch to "remote LAN access Logical adapter." You should now have a "Current Configuration" list box with the following information in it: +--------------------------------------+ | remote LAN access Logical Adapter...| | 0 - IBM OS/2 NETBIOS | <--- Required by RLA | 0 - IBM IEEE 802.2 | <--- Optional NOTE #1 | 0 - IBM NetWare Requester | <--- Optional NOTE #2 | 0 - IBM TCP/IP | <--- Optional NOTE #3 +--------------------------------------+ NOTE #1: 802.2 protocol is optional and is needed only if you are going to run an 802.2 application such as Communications Manager on the remote workstation. NOTE #2: NetWare Requester is optional and is needed only if you are going to run the Novell Requester over IBM RLA to a Novell Server. NOTE #3: TCP/IP is optional and needed only if you are going to run applications that require TCP/IP. 3) In the List box entitled "Currently Configuration" select "rla Logical Adapter" 4) Select the "Edit" pushbutton. 5) Enter the Network adapter address for the rla logical adapter. This is the virtual LAN Network address by which your RLA remote workstation will be identified to the LAN. This address must be unique for the logical LAN RLA creates. 6) Let's make sure that your protocols under the RLA logical adapter are clean. In the list box entitled "Current Configuration" select the 0 - IBM OS/2 NETBIOS protocol. Select the Edit pushbutton. You now see the "Parameters for IBM OS/2 NETBIOS" dialog box. Delete all information from the "Network adapter address" entry field. Repeat Step #3 for 802.2 and NetWare Requester as needed. 7) OK pushbutton located in the lower right-hand corner of the "Configure Workstation" window. Select the Exit pushbutton on the IBM LAPS Logo window. Select the Continue... pushbutton on the CONFIG.SYS Update message window. Select OK to CONFIG.SYS Updated message window. Select the Exit pushbutton at the Exiting LAPS message. For technical people who want to know more about what the PROTOCOL.INI file looks like, we list an example below. WARNING: Please do not edit this file unless you have an excellent understanding of OS/2 control files, protocols, and adapters. NOTE: Due to translation problems, the normal square brackets you would see before and after each keyword will have the curly brackets instead, e.g., {PROT_MAN} Your file must have keywords surrounded by square brackets. ---------------------------------------------------------------- PROTOCOL.INI for RLA Remote ---------------------------------------------------------------- {PROT_MAN} DriverName = PROTMAN$ {IBMLXCFG} LANDD_nif = LANDD.NIF NETBEUI_nif = NETBEUI.NIF ODI2NDI_nif = ODI2NDI.nif TCPIP_nif = TCPIP.NIF PDFH_nif = PDFH.nif {LANDD_nif} <----- 802.2 protocol DriverName = LANDD$ Bindings = PDFH_nif <----- RLA as adapter 0 ETHERAND_TYPE = "I" SYSTEM_KEY = 0x0 OPEN_OPTIONS = 0x2000 TRACE = 0x0 LINKS = 8 MAX_SAPS = 3 MAX_G_SAPS = 0 USERS = 3 TI_TICK_G1 = 255 T1_TICK_G1 = 15 T2_TICK_G1 = 3 TI_TICK_G2 = 255 T1_TICK_G2 = 25 T2_TICK_G2 = 10 IPACKETS = 250 UIPACKETS = 100 MAXTRANSMITS = 6 MINTRANSMITS = 2 TCBS = 64 GDTS = 30 ELEMENTS = 800 end of part 1 of 3. :from.Rick Ragan, IBM Austin ----- REMOTE ANSWERS appended at 13:32:54 on 93/06/23 GMT (by RAGAN at AUSVM1) :ndx.LAPS_002 :abs.COMMON PROBLEM #7: LAPS for RLA Remote and Server, part 2/3 :key.RLA TBIRD LAPS :QUESTION. How do I configure LAPS for IBM remote LAN access? :ANSWER. Common Problem #7, part 2 of 3... {NETBEUI_nif} <----- NetBIOS protocol DriverName = netbeui$ Bindings = PDFH_nif <----- RLA as adapter 0 ETHERAND_TYPE = "I" USEADDRREV = "YES" OS2TRACEMASK = 0x0 SESSIONS = 40 NCBS = 95 NAMES = 21 SELECTORS = 5 USEMAXDATAGRAM = "NO" ADAPTRATE = 1000 WINDOWERRORS = 0 MAXDATARCV = 4168 TI = 60000 <----- LAN Timers adjusted T1 = 25000 <----- for IBM RLA T2 = 2000 <----- MAXIN = 1 MAXOUT = 1 NETBIOSTIMEOUT = 500 NETBIOSRETRIES = 8 NAMECACHE = 0 PIGGYBACKACKS = 1 DATAGRAMPACKETS = 2 PACKETS = 350 LOOPPACKETS = 1 PIPELINE = 5 MAXTRANSMITS = 6 MINTRANSMITS = 2 DLCRETRIES = 5 {ODI2NDI_nif} <----- NetWare ODI to NDIS DriverName = odi2ndi$ Bindings = PDFH_nif <----- RLA as adapter 0 TOKEN-RING = "yes" TOKEN-RING_SNAP = "no" ETHERNET_802.3 = "no" ETHERNET_802.2 = "no" ETHERNET_II = "no" ETHERNET_SNAP = "no" TRACE = 0x0 {TCPIP_nif} <----- TCP/IP DriverName = TCPIP$ Bindings = PDFH_nif <----- RLA as adapter 0 {PDFH_nif} DriverName = PDFH$ NETADDRESS = "t4000000000AA" <----- RLA LAN Network address, must be unique for the LAN. {VLAN_KERNEL} <----- RLA Virtual LAN DRIVERNAME = VLANKNL$ device driver CFGTYPE = "Locked" MODE = "POINT_TO_POINT" LANTYPE = "802.5" MAXADDRESSES = 512 {COM1} DRIVERNAME = WCLCPMC$ CFGTYPE = "LOCKED" PCMSUPPORT = "YES" MACTYPE = "802.5" CONN_TYPE = "SWITCHED" ---------------------------------------------------------------- end of PROTOCOL.INI for RLA Remote workstation ---------------------------------------------------------------- ---------------------------------------------------------------- LAPS CONFIGURATION FOR A RLA SERVER >> RLA Server << ---------------------------------------------------------------- Philosophy for the RLA Server: The only protocol stack needed for the RLA Server is NetBIOS for both the Token Ring adapter and for the IBM RLA logical adapter. All application protocols are configured at the RLA Remote workstation. 1) Configure the RLA Server to include the following adapters and protocols. See the above steps (1-7) if you are unsure about how to work with LAPS to achieve the results listed below. Once completed, your LAPS "Current Configuration" list box should have the following information in it: +---------------------------------------+ | IBM Token Ring Network Adapters | | 0 - IBM NetBIOS | <--- Required by TR | 0 - xxxxxxxxxxxxxx | <--- NOTE #1 | remote LAN access Logical Adapter... | | 1 - IBM OS/2 NETBIOS | <--- Required by RLA +---------------------------------------+ NOTE #1: If the server is strictly a workstation dedicated to IBM RLA, then no other protocols will be under the TR adapter. Only if this Server has the dual purpose of running IBM RLA and also running applications as a LAN-attached workstation for a user sitting at this Server would there ever be a need to include other protocols under the TR adapter. For technical people who want to know more about what the PROTOCOL.INI file looks like, we list an example below. NETBIOS is configured for IBM Token-Ring as adapter 0 and for remote LAN access Logical Adapter as adapter 1. RLA Setting configuration: RLA bridge, COM1, and COM3 for async switched connection to the receive calls. WARNING: Please do not edit this file directly unless you have an excellent understanding of OS/2 control files, protocols, and adapters. NOTE: Due to translation problems, the normal square brackets you would see before and after each keyword will have the curly brackets instead, e.g., {PROT_MAN} Your file must have keywords surrounded by square brackets. ---------------------------------------------------------------- PROTOCOL.INI for the RLA Server ---------------------------------------------------------------- {PROT_MAN} DRIVERNAME = PROTMAN$ {IBMLXCFG} NETBEUI_nif = NETBEUI.NIF IBMTOK_nif = IBMTOK.nif {NETBEUI_nif} <----- NetBIOS protocol DriverName = netbeui$ Bindings = IBMTOK_nif,PDFH_nif <----- Token-Ring as ETHERAND_TYPE = "I" adapter 0 and USEADDRREV = "YES" RLA as adapter 1 OS2TRACEMASK = 0x0 SESSIONS = 40 NCBS = 95 NAMES = 21 SELECTORS = 5 USEMAXDATAGRAM = "NO" ADAPTRATE = 1000 WINDOWERRORS = 0 MAXDATARCV = 4168 TI = 60000 <----------- LAN timers adjusted T1 = 25000 for WAN speeds T2 = 2000 MAXIN = 1 MAXOUT = 1 NETBIOSTIMEOUT = 500 NETBIOSRETRIES = 8 NAMECACHE = 0 PIGGYBACKACKS = 1 DATAGRAMPACKETS = 2 PACKETS = 350 LOOPPACKETS = 1 PIPELINE = 5 MAXTRANSMITS = 6 MINTRANSMITS = 2 DLCRETRIES = 5 {IBMTOK_nif} DriverName = IBMTOK$ ADAPTER = "PRIMARY" MAXTRANSMITS = 6 RECVBUFS = 2 RECVBUFSIZE = 256 XMITBUFS = 1 ENABLEBRIDGE end of part 2 of 3. :from.Rick Ragan, IBM Austin ----- REMOTE ANSWERS appended at 13:35:06 on 93/06/23 GMT (by RAGAN at AUSVM1) :ndx.LAPS_003 :abs.COMMON PROBLEM #7: LAPS for RLA Remote and Server, part 3/3 :key.RLA TBIRD LAPS :QUESTION. How do I configure LAPS for IBM remote LAN access? :ANSWER. Common Problem #7, part 3 of 3... {VLAN_KERNEL} <----- RLA's Virtual LAN DRIVERNAME = VLANKNL$ device driver CFGTYPE = "Locked" MODE = "POINT_TO_POINT" LANTYPE = "802.5" MAXADDRESSES = 3500 {PDFH_nif} <----- RLA logical adapter DRIVERNAME = PDFH$ NETADDRESS = "t4000000000FF" <----- Logical LAN Network Address, must be unique {sr_bridge} DriverName = BRIDGE$ Bridgenum = 15 <----- Make sure there are no Maxframe = 516 duplications within the Spanningtree = NO same LAN segment. CfgType = "Locked" Bindings = IBMTOK_nifB,BRIDGEFH Ringnum = 0xA54,0x222 <----- Your LAN Segment in Hex Maxhopcount = 3,3 and WAN Segment in Hex {BRIDGEFH} DriverName = LANFH$01 CfgType = "Locked" {COM1} DriverName = WCLCPMC$ CFGTYPE = "LOCKED" PCMSUPPORT = "yes" MACTYPE = "802.5" CONN_TYPE = Switched {COM3} DriverName = WCLCPMC$ CFGTYPE = "LOCKED" PCMSUPPORT = "yes" MACTYPE = "802.5" CONN_TYPE = Switched ---------------------------------------------------------------- end of PROTOCOL.INI file for the RLA Server ---------------------------------------------------------------- end of Common Problem #7 :from.Rick Ragan, IBM Austin ----- REMOTE ANSWERS appended at 19:38:45 on 93/07/12 GMT (by RAGAN at AUSVM1) ..... REMOTE ANSWERS modified at 16:47:35 on 93/07/13 GMT (by RAGAN at AUSVM1) :ndx.SECUR001 :abs.COMMON PROBLEM #8: What security does RLA contain? Part 1/2 :key.security RLA TBIRD :QUESTION. What security features does the IBM remote LAN access product contain? :ANSWER. *************************************************************** Common problem #8: What security does RLA contain, Part 1/2 *************************************************************** Common Problem #8, part 1 of 2... Part 1 of 2 Page 1 of 7 05/27/93 IBM remote LAN access for Token Ring IBM Wide Area LAN/2 for Token Ring Wide Area LAN/2 (WAL/2) Server - Security Runtime Services The primary goal of WAL runtime security is to protect the LAN wire from casual, unauthorized external access. When a external WAN circuit is established at a WAL Server using a Public Switched Network, WAL runtime security services will ensure that no LAN frames will be transfered onto the WAN circuit and no WAN frames will be transfered onto the LAN wire UNTIL the caller is authenticated. In addition, if there are already several external users that have been authenticated and are currently accessing application servers on the LAN, WAL runtime security will ensure that a NEW caller will not see any of the traffic between the LAN and any of these prior users until the new caller has been authenticated. A new caller can learn nothing about the names being used on the LAN until the caller is authenticated and a new caller will not be able to introduce any data (e.g. inject error frames) onto the LAN until the caller is authenticated at the WAL Server. A secondary goal of the WAL/2 server runtime security is to ensure that when a WAL/2 server receives a request for service, the server can determine that the request was sent by an authorized user, the request received has not been modified in transit, and the current message is not a copy of a prior message. Before a WAL/2 workstation sends requests to a secured WAL/2 server, the WAL/2 workstation must first ensure that the user at the WAL/2 workstation is authenticated by the WAL/2 server. If the workstation user is authenticated successfully (i.e. the user provides the correct password), the workstation will be able to generate server CERTIFICATES that can be added to requests sent to the server. When a secure WAL/2 server receives a request containing a certificate, the server (i.e. its runtime security component) can validate the certificate and verify that the user sending the request is authentic and is authorized by the WAL/2 server to request the service. Moreover, a valid certificate will contain proof that the request itself has not been modified since being sent and is not a copy of a certified request (sent earlier by a "good" user) that was introduced by a "hacker" masquerading as the "good" user. RLA/2 Server Security Features * User Permission Types A separate data base of user accounts is maintained at each RLA/2 server. - USER This is the lowest security classification. A user of this type has permission to access the dial services of a RLA/2 server in order to dial off LAN and can be granted permission to remotely attach to the LAN wire by calling a RLA/2 server. A user of this type can also view and change selected information (e.g. user description and user password) within the user's own account at a RLA/2 server. - ADMINISTRATOR This user type has the same privileges as a USER type and, in Page 2 of 7 - SECURITY ADMINISTRATOR This user type has the same privileges as an ADMINISTRATOR and, in addition, is authorized to maintain a RLA/2 Server's User Account Data Base. This user can change user account policy parameters (e.g. maximum number of logon attempts permitted during a single call), and can view, add, and delete user accounts within the User Account Data Base. This user can also change any of the account information contained in other user's accounts. * Optional Security The security feature of a RLA/2 Server is a configuration option. If security is disabled, any person can access the configuration interface at the RLA/2 Server and enable its security option. However, once security is enabled, only a user designated as a RLA/2 security administrator can logon to the RLA/2 server and disable the security sub-system. Enabling or disabling security at a RLA/2 Server is a LOCAL operation only and can not be performed remotely. That is, a RLA/2 security administrator must be physically located at the RLA/2 server machine when operating the RLA/2 configuration user interface that toggles the state of the security sub-system. * User Authentication Protocol The RLA/2 security sub-system implements a two party, two way entity authentication protocol based upon the IBM patented protocol "2PP". Like 2PP the RLA/2 security protocol uses Message Authentication as the primitive on top of which it solves the entity authentication problem. The message authentication scheme uses DES to generate the required cryptographic checksum and adheres to the X9.9 standard. After a successful mutual authentication - client to server and server to client - the client and server both share a common secret SESSION KEY that is used to build the certificates that authenticate all subsequent workstation service requests sent to the server. A different session key is used during each separate logon session. * Password Phrases To minimize the possibility of off-line "dictionary attacks" to discover user passwords, RLA/2 security supports "pass phrases". Up to 32 case sensitive characters can be used to build individual tokens that comprise a password phrase. The password phrase is one-way encrypted using the xxxxx algorithm into an eight byte Page 3 of 7 is the initial shared secret that is the basis for the message authentication scheme used in the RLA/2 user authentication logon protocol. * Single Logon A user is required to logon and be authenticated by each secured RLA/2 Server before accessing the server's services (e.g. Dialer services, Management services, or access to the target LAN wire). However, a user need only be involved in a single logon task (i.e. supplying his/her User Id and password) provided the user has the same User Id and password at each of the RLA/2 servers that the user subsequently attempts to access. The user id and password used during the first logon are saved (in memory only) by the RLA/2 workstation security component and used first for each of the following logon attempts at the other servers. The user will be required to participate in a second logon only if the user's User Id or password is different at the next RLA/2 server accessed. * Policy Options Several user authentication policy options can be configured by a RLA/2 Security Administrator when setting up a RLA/2 Server: - Maximum Password Age User's with passwords will be required to change their passwords when the age of their current password exceeds this time period. The user will not be permitted to logon until a valid new password has been submitted. The new password will not take effect until the next logon (i.e. the current password will be used for the password change session). The user will be permitted to change his/her own password prior to the password's expiration time using a separate User Account Management interface. The default is 30 days and a "no maximum" selection is supported. - Minimum Password Age A RLA/2 Security Administrator will be able to specify a time period during which a user will not be able to change a recently established password. The default time period is 0 days which means that there is no restriction on when a user can change a newly assigned password. - Minimum Password length A RLA/2 Security Administrator can establish the minimum password length that is required for each user account. The minimum password length can be from 4 to 32 characters. password length is 32 characters. The default is 8 characters. - Password History A RLA/2 Security Administrator can specify that a history of from 0 to 8 prior passwords be saved in the users account. Whenever the user changes his/her password, the new password is checked against these password history values to ensure the new password is not a duplicate of a recent password. If a duplicate is found, the new password submitted is reported to be invalid and the user will be asked to submit another new password. The default is 8 prior passwords. end of part 1 of 2, continued. :from.Rick Ragan, IBM Austin ----- REMOTE ANSWERS appended at 13:21:37 on 93/07/13 GMT (by RAGAN at AUSVM1) ..... REMOTE ANSWERS modified at 16:47:43 on 93/07/13 GMT (by RAGAN at AUSVM1) :ndx.SECUR002 :abs.COMMON PROBLEM #8: What security does RLA contain? Part 2/2 :key.security RLA TBIRD :QUESTION. What security features does the IBM remote LAN access product contain? :ANSWER. Common Problem #8, part 2 of 2... - Maximum Unsuccessful Logon Attempts A RLA/2 Security Administrator will be able to specify the number of unsuccessful logon attempts that will be permitted for each call. A logon attempt can fail because an unknown User Id is submitted, an inactive account is being accessed, the password is incorrect, the user is calling from a workstation with a LAN adapter address that is invalid for the account, or the user is calling during a day of the week or a time of day that is invalid for the account. The default is four attempts. If the maximum number of logon attempts is exceeded, the user's account will automatically be marked as inactive. In this situation, in order to logon in the future, a user will be required to contact the RLA/2 Security Administrator in order to have the account re-activated. Dialback and Additional Security Options * DialBack RLA/2 security supports an optional dialback feature for remote RLA/2 (standalone) workstations only; dialback to RLA/2 LAN workstations (workstations physically attached to the LAN) and RLA/2 Servers is not supported. The dialback option configured within the caller's account will not be checked unless the call is placed from a remote RLA/2 (standalone) workstation. The dialback option within a user account can be configured as follows: - Dialback not required These user's will never be called back by the called server. - Fixed Dialback These user's will be called back at a fixed configured telephone number. - Mobil Dialback Page 5 of 7 part of the logon protocol. The server will then use the telephone number submitted to it for the Dialback. The caller will be authenticated both prior to the dialback call (this will prevent harassment calls) and also after the dialback is is complete (this will guard against known hacker techniques that can normally only be avoided using special telephone equipment or service options). Dialback can be useful if reversal of telephone charges is needed (e.g. the majority of the charges for a call from a hotel room can be be charged to the central site instead of the traveler at the hotel). * Workstation Address Identification A RLA/2 Security Administrator can configure 0 to 8 workstation LAN MAC addresses within a user account. The caller must call from a workstation that has been configured with a LAN adapter MAC address that matches one of the MAC addresses stored in the caller's account, otherwise the logon attempt will fail. * Valid Logon Time Intervals A RLA/2 Security Administrator can configure the days of the week and the time of day during these weekdays that a user is allowed to logon to his account at the RLA/2 server. logon at a time that is not within one of the specified time intervals within the user's account, the logon attempt will fail. Summary of IBM RLA/2 Server Logon protocol The RLA/2 server implements a protocol for MUTUAL AUTHENTICATION in the shared key model. Two parties who share a secret password-derived KEY want to interact with one another and to be able to mutually identify one another. After the mutual authentication is complete, both parties should simultaneously share a random and secret SESSION KEY. The protocol satisfies the following requirements: * The protocol provides mutual authentication between a client and a server. In the process of authenticating one another, the client and server come to share a random session key. * The client initiates the protocol. The client has no information about the server except the server's address. The client has a user id and user-supplied password for authentication. * The server has no information about the client besides the client's id and password-derived KEY. The server is physically secure (and may store secrets). Page 6 of 7 * The client's computational resources may be quite limited (a low-end PC, say). The server's computational resources are moderate to high (a mid-range PC, say). The adversary's computational resources may be considerable. * An adversary can watch all communication and can interact with the client and server to try to subvert authentication. The number of such interactions possible in a day is not too large. * Compromise of session keys should have no ill-effects outside the current session. Description of RLA/2 logon protocol A, RA from a user password phrase using a one-way cryptographic hash algorithm. The password phrase can consist of 4 - 32 case B The resulting key is 8 bytes in length. The protocol requires three rounds and resembles the patented IBM protocol 2PP. The protocol is shown in the following Figure: Flow 1 ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ> RB, Fa Flow 2 <ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ Fa Flow 3 ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ> Figure 1. A variant of the protocol 2PP. In this protocol, A sends B a random value RA together with the name A (the name A should be unique among the entities who share the secret key 'a' - for example User Id). B responds by choosing its own random value RB and returns both RB and Fa, a message authentication code of the contents of the A's message, the random value RB, and its own name. The message authentication code is derived using the X9.9 standard (i.e. applying DES CBC to the input string using key 'a' and a null initialization vector). The message authentication code is the last CBC block in the chain. Page 7 of 7 A compares the message authentication code received from B with the message authentication code A has generated locally and if they match, A accepts B as authentic. A then returns a new message authentication code Fa back to B (flow3). When B gets this message, he computes his own message authentication and compares his code with the one received from A. If the two codes match, B accepts A as authentic. As a result of the exchange, each party that accepts can regard himself as being in possession of a random, shared, secret SESSION KEY. This session key is a message authentication code which both sides can compute. The protocol of Figure 1 is, of course, susceptible to dictionary attacks if the user fails to take advantage of the capability of a full password phrase (e.g. a single word is used for the password instead of a case sensitive phrase such as "My lily are ASTRO turf"). In future releases of RLA/2, the protocol above may be enhanced by adding information in the scope of the message authentication codes of flows 2 and 3 - information that is not known to an adversary and that results from a secret key exchange that occurs concomitantly with the authentication. By adding this new information within the the flows, the protocol will be made resistant to off-line dictionary attacks even if "dictionary words" are used as passwords. If an adversary collects proper authentication transcripts and correctly guesses the shared key, there will be no way for the adversary to verify the guess by studying the transcripts themselves; instead, the adversary will be forced to interact with one of the real parties to see if a candidate password works and thus expose his activities to auditors. In addition, learning a clients password at some point in time will not compromise session keys used at EARLIER points in time. Unfortunately, the proposed protocol enhancement can not be described here - it is currently proprietary and has been submitted as a candidate for an IBM patent. :from.Rick Ragan, IBM Austin ----- REMOTE ANSWERS appended at 20:49:28 on 93/07/27 GMT (by RAGAN at AUSVM1) ..... REMOTE ANSWERS modified at 14:14:51 on 93/07/28 GMT (by RAGAN at AUSVM1) :ndx.LAN_0001 :abs.COMMON PROBLEM #9: LAN Server 2.0 fails to work :key.RLA TBIRD LAN DISTANCE LAN Server 2.0 :QUESTION. Why does my LAN Server 2.0 and LAN Requester 2.0 fail to work with IBM remote LAN access (LAN Distance)? :ANSWER. **************************************************************** COMMON PROBLEM #9: IBM LAN Server / Requester 2.0 **************************************************************** If you are using IBM LAN Server 2.0 or IBM LAN Requester 2.0, you may have problems logging on to the Domain Controller with LAN Distance. LS 2.0 SYMPTOMS: RLA starts correctly, without error messages. A wide variety of error messages could occur including LAN Requester failing to start, failed logon attempts, etc. If you type the following command at the OS/2 command prompt: NET ERROR You will see a log containing one or both of the following errors: ---------------------------------------------------------------- NET 3106: An unexpected NCB was received. ---------------------------------------------------------------- NET 3140: The service has stopped due to repeated consecutive occurrence of an NCB error. ---------------------------------------------------------------- LS 2.0 PROBLEM ONLY: Due to an incompatibility problem between the latest NETBIOS driver that is shipped with IBM LAN Distance and the NETBIOS driver provided with LAN Server 2.0, IBM LAN Server 2.0 will eventually fail to run over LAN Distance. LS 2.0 SOLUTION ONLY: ******************************************************************* >> FOR IBM LAN SERVER 2.0 & IBM LAN REQUESTER 2.0 USERS ONLY << ******************************************************************* * * * An APAR exists for this bug, APAR JR07340. You may either call * * IBM at 1-800-237-5511 to request this fix, or you can carry out * * the following steps: * * * * Do not apply this fix to your workstations unless they are * * either LAN Server 2.0 or LAN Requester 2.0. * * * * 1) Place LAN Distance Diskette #3 into the diskette drive * * >>> for the 2nd beta diskettes only <<< * * 2) At an OS/2 command prompt, enter the \IBMCOM\PROTOCOL * * subdirectory * * 2) Backup your old file with the command: * * COPY NETBIOS.OLD * * 3) Type the command: * * COPY A:\NETBIOS.LS2 NETBIOS.OS2 * * 4) Remove the diskette * * 5) Shutdown and re-start your workstation. * ******************************************************************* Rick Ragan, Austin, TX :from.Rick Ragan, IBM Austin ----- REMOTE ANSWERS appended at 18:37:13 on 93/07/28 GMT (by RAGAN at AUSVM1) :ndx.BETA_001 :abs.COMMON PROBLEM #10: Beta code of LAN Distance has expired. :key.BETA TBIRD expired LAN DISTANCE :QUESTION. What do I do if I get the error message that my Beta code has expired? :ANSWER. **************************************************************** COMMON PROBLEM #10: "Beta Code of LAN Distance has expired." **************************************************************** SYMPTOMS: You successfully install the 1st or the 2nd beta code on a workstation. > The current date on your workstation is before: 11/01/93. > When you double click on the LAN Distance icon, you receive the following error message. WCL0590I: This beta code of IBM's LAN Distance has expired. Please see you IBM representative for information on obtaining the official Licensed version of this product. PROBLEM #1: If you have not run this beta before (and the date on your workstation is before 11/01/93), then you have a workstation that does not have a valid and formatted C: drive. SOLUTION #1: Either prepare your workstation to have a usable, formatted C: drive, or install LAN Distance's beta on a workstation that has a valid C: drive. PROBLEM #2: If the date of your workstation is after 11/03/93, your beta code has expired. SOLUTION #2: Please discard the LAN Distance beta code and purchase a copy of LAN Distance from your local IBM representative. :from.Rick Ragan, IBM Austin ----- REMOTE ANSWERS appended at 14:08:30 on 93/08/09 GMT (by RAGAN at AUSVM1) ..... REMOTE ANSWERS modified at 23:54:00 on 93/11/12 GMT (by RAGAN at AUSVM1) :ndx.BRIDGE01 :abs.COMMON PROBLEM #11: Setting up the LAN Distance Bridge :key.Bridge BETA LAN DISTANCE TBIRD hop count :QUESTION. How do I set up my bridge to get the values such as hop count, LAN Segment number, etc? :ANSWER. **************************************************************** COMMON PROBLEM #11: Setting up the LAN Distance Bridge **************************************************************** | highlighted change in OS2PING command (dropped -sr) PROBLEM: When setting up the LAN Distance Connection Server, there are five major issues to get the bridge part of LAN Distance working correctly. The "Controller" mentioned below could be an IBM LAN Server's Domain Controller, or the 3270 Controller to get to the host, etc. 1) LAN Adapter address to tell the LAN Distance Remote workstation the location of the Controller (configured on the LAN Distance Remote machine. 2) Unique bridge number (0-15) for LAN Distance's bridge (configure on LAN Distance's Connection Server). 3) LAN Segment Ring number (3 digit hexadecimal) the LAN Distance Connection Server is located (configure on LAN Distance's Connection Server). 4) Network Bridge Hop count from the LAN Distance Remote workstation to the Controller (configure on LAN Distance's Connection Server). 5) Possible need to increase the Hop count for all bridges between the LAN Distance Remote workstation and the Controller (configure at each bridge). SOLUTION: On OS2TOOLS, there is a very valuable tool called OS2PING. This applet is highly recommended for anyone who is having problems with the items 1-5 above, or anyone who wants to discover more about their LANs. The 802.2 protocol is required to run OS2PING. This protocol is shipped with the LAN Distance product. OS2PING COMMAND FOR LAN DISTANCE: | OS2PING -a=xxxxxxxxxxxx -r | WHERE: | xxxxxxxxxxxx is the destination address of the Controller. | r is the command to display formatted routing information. THIS EXAMPLE WILL PING: from LAN Distance Remote workstation to the Controller. THE RESULTING ROUTING INFORMATION FROM OS2PING IS: (002) 1 --> (cea) 7 --> (b22) 5 --> (c3a) WHAT DOES THIS RETURNED INFORMATION MEAN? Each number in parenthesis (cea) is a LAN Segment number for a specific LAN. Each number after the LAN Segment is the bridge's unique number. In this example, the Ping traveled from WAN1 across three bridges to LAN4: (002) --- 1 ----> (cea) --- 7 --> (b22) --- 5 --> (c3a) (WAN1) LD/Bridge (LAN2) Bridge (LAN3) Bridge (LAN4) The LAN Distance connection is WAN1 (the default WAN Segment for the LAN Distance product is 002). The LAN Distance Connection Server is the first bridge with a default number "1". The Controller is on LAN4 (this is always the last LAN Segment in the returned information). LAN DISTANCE BRIDGE SOLUTIONS: 1) The LAN Adapter address for the Controller is xxxxxxxxxxxx (this is the known value you obtained from your LAN Administrator). 2) A unique Bridge number (0-15) for the LAN Distance Connection Server worked with the default number 1. 3) The LAN Distance Connection Server is located on LAN Segment Ring number: cea. 4) The Network Bridge Hop count from the LAN Distance Remote workstation to the Controller is 3 (count the bridges = one LAN Distance bridge and 2 LAN bridges). 5) The ping from the LAN Distance Remote workstation to the Controller returned from the Controller. There is no need to adjust the bridges to add an extra hop count. Additionally, to trouble shoot bridging problems, you can follow this sequence: a) Ping from Connection Server to any LAN workstation located on that LAN segment the Connection Server is located. b) Ping from the Connection Server to the Controller. c) Ping from the LAN Distance Remote workstation to the Connection Server. d) Ping from the LAN Distance Remote workstation to the Controller. If the ping from the LAN Distance Remote workstation to the Controller fails, and OS2PING returns the message: OS2PING: No responses received during 10 second wait. Then you may either have an incorrect destination address for the Controller, or you bridges may be tuned so tightly that a response cannot return. One way to test this is to systematically ping from the LAN Distance Remote Workstation to a LAN-attached workstation on each intervening LAN. For example from the LAN Distance Remote workstation (WAN1), ping a known address on LAN2, ping a known address on LAN3, and ping a known address on LAN4. If all pings return except on LAN4, then the bridge between LAN3 and LAN4 may need its hop count increased. NOTE: If your OS2PING produces multiple lines: OS2PING: First response received OS2PING: ADDR=xxxxxxxxxxxx Route was: (002) 1 --> (cea) 7 --> (b22) 5 --> (c3a) OS2PING: Later response(s) : OS2PING: ADDR=xxxxxxxxxxxx Route was: (002) 1 --> (cea) 7 --> (b22) 5 --> (c3a) OS2PING: ADDR=xxxxxxxxxxxx Route was: (002) 1 --> (cea) 7 --> (4ab) 2 --> (c21) 3 --> (b31) 5-->(c3a) These additional LANs represent various paths your ping can take from your LAN Distance Remote Workstation to the Controller. Just as you can drive to work using several different roads, OS2PING will show you the various paths back to the Connection Server from the Controller. You can use any path that is stable; however, you may wish to use the path with the fewest hop counts in order to minimize the number of bridges and LANs. The LAN Segment Ring number will always be the same (last) number for your Controller, no matter which path it takes to get to the controller. (You always make it to work, no matter which road you take to get there.) :from.Rick Ragan, IBM Austin ----- REMOTE ANSWERS appended at 15:19:32 on 93/08/12 GMT (by RAGAN at AUSVM1) ..... REMOTE ANSWERS modified at 15:34:44 on 93/08/12 GMT (by RAGAN at AUSVM1) :ndx. :abs. ----- REMOTE ANSWERS appended at 15:26:28 on 93/08/12 GMT (by RAGAN at AUSVM1) ..... REMOTE ANSWERS modified at 18:45:39 on 93/09/03 GMT (by RAGAN at AUSVM1) :ndx.ERROR001 :abs.COMMON PROBLEM #12: WCL0336 Error Message :key.WCL0336 autoanswer modem string :QUESTION. How do I recover from a WCL0336 error message? :ANSWER. **************************************************************** COMMON PROBLEM #12: WCL0336 Error message **************************************************************** ERROR MESSAGE: WCL0336: The connection was made, but the LAN Distance frame handler could not be attached to the connection. The connection was dropped. PHILOSOPHY: This error message occurs due to multiple reasons. There are at least six possible problems that could lead to the WCL0336 error message: #1 - No Autoanswer for the Connection Server #2 - Incorrect Modem String #3 - Defective Modem Cable #4 - Token Ring / Ethernet mis-match #5 - LAN Segment / WAN Segment mis-match #6 - non LAN Distance Destination mis-match #7 - bug in Practical Peripherial modem string PROBLEM #1: No Autoanswer for the Connection Server If you have a LAN Distance Remote workstation dialing into a LAN Distance Connection Server, the Connection Server may not be in Autoanswer mode. The Remote workstation will establish a partial link with the Connection Server then the connection will be quickly dropped. SOLUTION #1: No Autoanswer for the Connection Server For the LAN Distance Connection Server (or Remote that may be trying to receive a call) Open as Settings, Answer tab, select PSTN_ALL_CALLS, for temporary configuration select the "Start mode" pushbutton, for permanent configuration select the Change pushbutton and check "Enable answer mode on startup". PROBLEM #2: Incorrect modem string The Error message WCL0221: "LAN Distance could not initialize the modem" is a precursor to the WCL0336 message if you have an unsupported modem, or a damaged cable. A poorly designed modem string or a very badly damaged modem cable may be unable to form even a partial LAN Distance connection thus producing the WCL0221 error message. With a better modem string or a "not as damaged" modem cable the LAN Distance connection would be temporarily established, however the LAN Distance session will fail and produce the WCL0336 error message. If you are attempting to use an unsupported modem and you have created a modem string that leads to a temporary LAN Distance connection, but fails to establish a fully functional LAN Distance session, the WCL0336 error message may result. Below are some of the possible errors in modem string constructions: DTE rate is not set to fixed in the initialization string of WCLNET.INI or PIF file. Incorrectly, the AutoBaudDetect keyword Default = "On" may have been set in the WCLNET.INI and the PIF file. DSR is incorrectly set to always be low in the modem string of the WCLNET.INI or PIF file. CR is incorrectly set to always be low in the modem string of WCLNET.INI or PIF file. SOLUTION #2: Incorrect modem String Set DTE rate to fixed in the Initialization string of the WCLNET.INI and/or PIF file Confirm the AutoBaudDetect keyword Default = "Off" is indeed set to "Off" in the WCLNET.INI and the PIF file. DSR (Data Set Ready) The DSR is a signal the modem sends to the computer to indicate that the modem is ready have a dialog. Configure the DSR for your modem to go from on to off when a connection terminates. (For most modems, the correct command is &S1). Set DSR properly in the Initialization string of the WCLNET.INI and/or PIF file CD (Carrier Detect) The CD signal tracks the presence or absence of the carrier signal from the modem on the other end of the line. Some modem manuals refer to the CD as the DCD or RLSD. Modems can be configured to interpret the CD in several ways. Select the CD modem command that causes the modem to track the status of the carrier detect signal. (For most modems, this command is C1). Set CD properly in the Initialization string of the WCLNET.INI and/or PIF file PROBLEM #3: Defective modem cable The LAN Distance workstation connecting with your workstation may have a defective cable. The modem cable may be wired improperly. Some modems are more sensitive to improper modem cables than others. SOLUTION #3: Defective modem cable Test the modem cable with another asynchronous software package (such as OS/2 2.1's PM Terminal in the Productivity folder) to insure it is working correctly. Or switch out the suspected modem cable with a cable that is known to work correctly. PROBLEM #4: Token Ring / Ethernet mis-match If you have configured your LAN Distance workstation to work on one type of LAN and you have actually dialed into another type of LAN, you will get the WCL0336 error message. For instance, if you have configured LAN Distance to work on a Token Ring LAN, but dial into a Connection Server located on an ethernet LAN, then LAN Distance will fail with this message. SOLUTION #4: Token Ring / Ethernet mis-match Insure that you LAN Distance workstation is configured for the same type of LAN hardware that you are actually dialing into. PROBLEM #5: LAN Segment / WAN Segment mis-match If you have a LAN Distance Connection Server dialing into another LAN Distance Connection Server, the LAN Segment Ring Number and the WAN Segment Ring Numbers must be set correctly. Dialing from one Connection Server to another Connection Server is an unsupported feature in the LAN Distance product, version 1.0. SOLUTION #5: LAN Segment / WAN Segment mis-match LAN Distance Connection Servers connecting with each other is an unsupported function for the 1st release of LAN Distance 1.0, however you may try the following configuration: > LAN Segment Ring Numbers must be different from each other > WAN Segment Ring Numbers must be identical PROBLEM #6: non LAN Distance Destination mis-match If you have selected "Connect to a non LAN Distance destination" and dialed into another LAN Distance workstation that has "Connect to a non LAN Distance destination" de-select (this is the default LAN Distance ships with), LAN Distance will fail with the WCL0336 error. SOLUTION #6: non LAN Distance Destination mis-match The "Connect to a non LAN Distance workstation" parameter must be the same on either side of the LAN Distance connection. Set both workstations to "Connection to a non LAN Distance workstation," or set both so that both are not set to "Connect to a non LAN Distance workstation." (Set this to not "Connect to a non LAN Distance workstation" if you do not plan to have Security enabled and you also desire faster performance.) PROBLEM #7: bug in Practical Peripherals modem string There is a bug in the Practical Peripherals modem strings shipped in the LAN Distance second beta. SOLUTION #7: bug in Practical Peripherals modem string The Practical Peripherals modem strings have an error. The PIF file and the WCLNET.INI will read: Default = "ATE1L0M1N1Q0V1X4Y1&C1&D2&K3&Q5&R0&S0S0=2S7=60\CR" ||| Edit both files (WCLNET.INI to say: &S1 rather than &S0. Default = "ATE1L0M1N1Q0V1X4Y1&C1&D2&K3&Q5&R0&S1S0=2S7=60\CR" ||| :from.Rick Ragan, IBM Austin ----- REMOTE ANSWERS appended at 18:18:24 on 93/09/03 GMT (by RAGAN at AUSVM1) ..... REMOTE ANSWERS modified at 14:27:10 on 93/09/30 GMT (by RAGAN at AUSVM1) :ndx. :abs. ----- REMOTE ANSWERS appended at 19:53:16 on 93/09/14 GMT (by RAGAN at AUSVM1) ..... REMOTE ANSWERS modified at 23:55:47 on 93/11/12 GMT (by RAGAN at AUSVM1) :ndx. :abs. ----- REMOTE ANSWERS appended at 19:56:08 on 93/09/14 GMT (by RAGAN at AUSVM1) ..... REMOTE ANSWERS modified at 14:27:40 on 94/01/04 GMT (by RAGAN at AUSVM1) :ndx. :abs. ----- REMOTE ANSWERS appended at 14:45:11 on 93/09/27 GMT (by RAGAN at AUSVM1) ..... REMOTE ANSWERS modified at 15:18:24 on 93/09/30 GMT (by RAGAN at AUSVM1) :ndx.FILTER01 :abs.COMMON PROBLEM #13: Filtering, part 1 of 2 :key.filtering bridge :QUESTION. How do I adjust filtering on the Connection Server so that the LAN traffic does not flood the slow async wire? :ANSWER. **************************************************************** COMMON PROBLEM #13: Bridge Filtering, part 1 of 2 **************************************************************** (Updated 1st usability concern, 9/30/93) ERROR MESSAGES: The RECEIVE modem light for the LAN Distance Connection Server workstation is ON most or all of the time. You cannot connect to your destination. You may get a "Domain not available." message. PROBLEM: If the LAN Distance Connection Server is located on a busy LAN with large volumes of LAN traffic, the LAN adapter will pass all LAN frames into the LAN Distance bridge. The unfiltered bridge will attempt to pass this high volume traffic onto the (slower) WAN wire, flooding the LAN Distance connection. PHILOSOPHY: 9600 bps WAN wires cannot handle heavy (8Mb) LAN traffic. Filtering is required if the LAN has many LAN-attached workstation with a lot of activity. SOLUTIONS: SOLUTION #1: Place the LAN Distance Connection Server workstation on a LAN segment with minimal LAN activity, i.e., fewer than four LAN-attached workstations. SOLUTION #2: If you place the LAN Distance Connection Server workstation in a production environment (i.e., large number of workstations and servers) you will need to filter the LAN traffic reaching the LAN Distance Connection Server workstation. 1) Address filtering -- accepts or rejects LAN traffic from workstations based on their Network address. 2) SAP filtering -- allows applications written to specified protocols to be filtered. 3) NetBIOS Names -- filtering reduces broadcast storms from NetBIOS applications on your LAN. 4) Bit mask -- advanced filtering to reduce specific Functional Destination Addresses. The most popular type of filtering is LAN source address filtering, which filters the network address for specific LAN workstations. For example, you could allow LAN frames from only the IBM Domain Controller (Server) to cross the bridge to LAN Distance Remote workstations. WAN source address filtering accepts or discards specific network addresses from remote workstations. For example, you could allow WAN frames from only specific LAN Distance Remote workstations to pass over the LAN Distance bridge to the LAN. All other workstations, even if they logon successfully to the LAN Distance Connection Server workstation, could not cross the LAN Distance bridge. You could further reduce LAN traffic over the LAN Distance bridge by filtering SAP information so that only the NetBIOS protocol could cross the LAN Distance bridge. For example, if the IBM Domain Controller workstation also functioned as the TCP/IP and SNA controller you could set up filtering to accept only the NetBIOS SAP. The other protocols could not pass over the LAN Distance bridge. This is a partial list of SAP values for protocols&colon. NetBIOS --- F0 TCP/IP ---- AA SNA ------- 04 (and multiples of 4) Netware --- E0 You could set up a NetBIOS names filter for the IBM Domain Controller. Since the IBM Domain Controller is a NetBIOS application, filtering on specific NetBIOS Names from the IBM Domain Controller would further decrease the LAN frames crossing the LAN Distance bridge. Most LAN Distance Connection Servers will require LAN Filtering. While WAN Filtering is not required, it can be used to prevent specific remote workstations from accessing LAN resources. BETA #2 -- DETAILS: Configure your LAN Distance Connection Server workstation bridge filters in the Settings notebook, the Bridge tab. USER INTERFACE PROBLEM #1: | There is a USABILITY CONCERN in the 2nd beta (was not | fixed in the final design). Add filtering criteria to the list box. After you have added the filter criteria, YOU MUST SELECT ALL CRITERIA IN THE LIST BOX THAT YOU HAVE ADDED. This means that each filter criteria must have the black "selection" bar, any filter criterion without the selection bar will not be used to filter LAN traffic. Before closing the window, ensure the filter criteria are selected. USER INTERFACE PROBLEM #2: Another usability conern with the LAN Distance product (not completely fixed in the final design) is that if you configure filter criteria and even select it in the above problem, the LOAD BRIDGE SUPPORT check box at the top of the first page must be checked for the filter criteria to be active. FUNCTIONAL PROBLEM: There is a problem that currently only 10 filter criteria can be entered in the Bridge tab. This problem is fixed in the final product. For the second beta, the work around is to edit \IBMCOM\PROTOCOL.INI. Copy the 10 entries that you have already configured (completed earlier in Settings, Bridge tab) and place the copied lines directly below the existing entries and modify these new entries manually. FUNCTIONAL PROBLEM: NetBIOS names filtering is not working in the 2nd beta. This problem is being fixed in the final product. ETHERNET FILTERING: Ethernet filtering is working in the final design, however, the 2nd beta will support Ethernet filtering only through following the steps detailed in Common Problem #14. RECOMMENDATIONS: Minimize as much as possible the amount of LAN traffic crossing the LAN Distance bridge by placing the Connection Server on a LAN segment with minimal LAN activity. Install the fix modules below for 2nd beta to resolve a number of filtering bugs. continue for fix modules... part 2 of 2 :from.Rick Ragan, IBM Austin ----- REMOTE ANSWERS appended at 14:46:55 on 93/09/27 GMT (by RAGAN at AUSVM1) ..... REMOTE ANSWERS modified at 23:57:54 on 93/11/12 GMT (by RAGAN at AUSVM1) :ndx.FILTER02 :abs.COMMON PROBLEM #13: Filtering, part 2 of 2 :key.filtering bridge :QUESTION. How do I adjust filtering on the Connection Server so that the LAN traffic does not flood the slow async wire? :ANSWER. **************************************************************** COMMON PROBLEM #13: Bridge Filtering, part 2 of 2 **************************************************************** (Updated 2nd usability concern, 9/27/93) continued from part 1 of 2... FIX MODULES: (not needed for the 3rd beta or GA code) NETBIOS NAMES FILTERING Once you download the BRIDGE modules and place them in their respective subdirectories, you can use the wildcard feature for NetBIOS Names filtering. Follow the steps and examples below: Open as Settings Select Bridge tab Address page Insure the LOAD BRIDGE SUPPORT check box is checked Page forward to "LAN Segment Filter Criteria" Select Add Select the NetBIOS tab Select Add Enter a NetBIOS name into the NetBIOS entry field: EXAMPLES: Place the fully NetBIOS name in the NetBIOS entry field: AUSN001100000000 In this example, only the NetBIOS name AUSN001100000000 will be used as filter criteria. With wild card filtering, place the first characters of the NetBIOS Name in the entry field. All trailing characters are omitted: AUS In this example, all addresses starting with the value AUS will be used as filter criteria. Rick Ragan, IBM Austin, TX :from.Rick Ragan, IBM Austin ----- REMOTE ANSWERS appended at 00:12:50 on 93/11/03 GMT (by RAGAN at AUSVM1) :ndx.CONN0001 :abs.Common Problem #15: Network Address for other Connection Ser :key.Connection Servers :QUESTION. How can I get more information about the extraneous Connection Servers that appear in my Workstations window? :ANSWER. **************************************************************** COMMON PROBLEM #15: Network Address for other Connection Servers **************************************************************** PROBLEM: Other LAN Distance Connection Server workstations may appear in your Workstations window. If security is enabled on these Connection Servers and you cannot perform an Open as Settings on them, how do you find more information about them? BACKGROUND: The LAN Distance development team is considering the function for a future release to allow you to keep unwanted LAN Distance Connection Servers from displaying in your Workstations window. Until that function is available, these steps can show you the Network Address of other Connection Servers. You can consult your LAN Administration for the physical location of each Network Address. However, placing these Network Address into your LAN Distance's Bridge's Filter Criteria will not prevent these Connection Servers from displaying in the Workstation's window. There is no current technique available to keep unwanted Connection Servers from appearing in the Workstation's window. PARTIAL SOLUTION: Follow these steps to discover the Network adapter address of the other Connection Servers appearing in your LAN Distance Connection Server Workstations window. Once you have the Network Adapter address, you can use the filter criteria to filter any LAN frames to your workstation from these unidentified Connection Servers. However, the Connection Server icons will still appear in your Workstations window. If you have a tool that can send messages to a specific Network Adapter address, then you may be able to discover where the Connection Server is located (i.e., once you have the Network Adapter address, you are not guaranteed the location of the Connection Server). 1) Stop LAN Distance 2) From an OS/2 command prompt, type WCLRSNTB to start up the LAN Distance Tracing Notebook (without starting LAN Distance). 3) Ignore the WCL0146 error message 4) Select the Trace tab 5) Select the following three items (use the Ctrl key plus mouse button #1 to select the second and the third items): WCL Data Received WCL Data Sent WCL Startup UI 6) Select the "Start" pushbutton to start the trace, don't close the Tracking notebook. 7) Start LAN Distance (wait for all the other Connection Servers to appear in the Workstations window). 8) In the Tracking notebook, select the "Stop" pushbutton. 9) Enter a file name to copy the contents of the Trace into, e.g., C:\WHERE.ASC 10) Select the "Copy" pushbutton, Select OK to the message about copying the trace into the file. 11) Close the Tracking Notebook. 12) Use an editor like EPM to view and search the file: EPM C:\WHERE.ASC 13) Search for the string: OBJ STRUC 14) There may be multiple instances of this string. Each instance is another Connection Server in your Workstations window. Each instance will look like this: Event--->Startup UI 11020313P/T=0029/0001 17:28:40.50 sumainuf: obj struc 00000000 00000000 00000000 00000000 <................> 00000000 01004D59 574F524B 53544154 <......MYWORKSTAT> 494F4E00 00000044 45534352 49505449 4F4E204F 46204D59 20574F52 4B535441 54494F4E 00000000 00000000 00000000 00000000 00313030 30354141 43333946 <.....10006BBC39F> 30000000 00000000 00000000 00414300 <0............AC.> D8018A16 02000000 15) Count six lines down on the right-hand side and starting on the sixth line (and one character on the seventh line) you will see the 12 digit number that is that Connection Server's Network Address. The network address for the example is: 10006BBC39F0 16) You can use OS2PING to identify on which LAN Segment that Connection Server is located. 17) As of this writing, I know of no way to send a message to that Network Address. If you require the location of that Connection Server, contact your company's LAN Administration to see if they have a list of the locations of each Network Address. :from.Rick Ragan, IBM Austin ----- REMOTE ANSWERS appended at 00:16:05 on 93/11/03 GMT (by RAGAN at AUSVM1) :ndx.ETHERNET :abs.Common Problem #16: Ethernet cannot be selected :key.Ethernet :QUESTION. I am at the Address tab, but only Token Ring is availabe on the LAN type entry field, what can I do to get Ethernet? :ANSWER. **************************************************************** COMMON PROBLEM #16: Ethernet cannot be selected **************************************************************** PROBLEM: You Open as Settings, select the Address tab, pull-down the "LAN Type" entry field, see only Token Ring adapter. You wonder how do you get Ethernet support? BACKGROUND: OS/2 Workplace Shell uses the concepts of pull-down entry fields. Often these fields can be scrolled once they are pulled-down. This entry field is not designed well, it should pull-down with at least two lines (Token Ring and Ethernet) showing. We plan to fix this in the next release. SOLUTION: 1) Open as Settings 2) Select the Address tab 3) Pull down the "LAN type" entry field Notice the Token Ring line below the entry field 4) Notice the up and down arrows to the extreme right of the now visible Token Ring pull-down. 5) Click once on the up arrow. 6) Select Ethernet (click once on Ethernet). 7) Select the Ethernet adapter from the "Ethernet card" entry field now available. :from.Rick Ragan, IBM Austin ----- REMOTE ANSWERS appended at 23:04:38 on 93/12/07 GMT (by RAGAN at AUSVM1) :ndx.MODEM000 :abs.SUPPORTED MODEMS: Updated listing of newly supported modems :key.Modems LAN Distance :QUESTION. The Advanced Guide for LAN Distance, Appendix A lists the modems that LAN Distance shipped with. What new modems does LAN Distance support? :ANSWER. SUBJECT: LAN Distance Modems DATE: December 2, 1993 The LAN Distance product development team is dedicated to supporting as many modems as possible. The following new modem types (PIF files) are available for use by LAN Distance customers. You can request these new modem types as a binary self-extracting EXE file (download in binary, place in \WAL subdirectory, type the command MODEMS at the OS/2 command prompt, and use Settings to Assign the new modem to a port): IBM: REMOTE FORUM VM REQUEST: REQUEST MODEMS FROM BETASRUS AT AUSVM1 Modem PIF File --------------------------- ------------ --older-- Zenith 2000 Series Modem ZEN2000.PIF Intel 14.4EX Modem INT144EX.PIF Intel SatisFAXtion Modem/400 INTFAX4.PIF Intel SatisFAXtion Modem/400e INTFAX4E.PIF USRobotics WorldPort 9600 Modem USRWPRT9.PIF Digicom Eagle Plus V.32 Modem EAGLEP.PIF (1) IBM Microelectronics 14.4/14.4 Data/Fax (PCMCIA) Modem IBMTORON.PIF (3) --New-- Complete PC 14400 TurboModem COMPLETE.PIF Megahertz XJ1144FM PCMCIA Data/Fax Modem MH144PCM.PIF (2) Megahertz XJ196FM PCMCIA Data/Fax Modem MH96PCM.PIF (2) Apex PCMCIA Fax/Modem IBP-1414 APEXPCM.PIF (1) (2) Intel PCFM7600 14.4/14.4 External Modem INPCFM76.PIF (1) ViVa 14.4/FAX Modem VIVA144.PIF (1) Apex Freedom 14/96 Data/Fax Laptop Modem APEX1496.PIF GVC FM-144V External Fax Modem GVCFM144.PIF GVC SM-96 External Modem GVCSM96.PIF (1) Customer generated (not generated in the LAN Distance Development lab). (2) PCMCIA Modem. Must have OS/2 Card and Socket Services (available from modem manufacturer) to run on OS/2 LAN Distance. (3) There is a bug in Device Driver of this modem. We are working with IBM Toronto to tell our customers how to get this fix and will append the solution (to get the fix in their code) to the LAN Distance forums. Please let us know through the forums which modems you would like for us to consider supporting for the LAN Distance products. Periodically, the IBM LAN Distance Development team will add modems types to this list, and place the corresponding PIF files on this forum. In an effort to distribute the widest variety of modem types, the LAN Distance Development team will also include new modem types developed and verified by our customers. These modem types will be labeled above. While we have confidence they will work with LAN Distance, these modem types have not been officially certified in the LAN Distance modem lab. Your feedback to our LAN Distance team is essential. Please report any modem problems you encounter through the Forums. Typical modem errors for LAN Distance include (WCL0221, WCL0336, and spontaneous disconnections). We are also interested in your modem successes. We encourage you to try any modem type with any modem, or develop a new modem type for your modem hardware. Let us know how your new modem type works, we would like to include them in the LAN Distance product! :from.Rick Ragan, IBM Austin ----- REMOTE ANSWERS appended at 16:15:38 on 94/01/10 GMT (by RAGAN at AUSVM1) :ndx.MS000001 :abs.COMMON PROBLEM #17: (MS Windows client only) Traps & WCL0321 :key.Traps MS Microsoft client :QUESTION. The MS Windows Beta for LAN Distance has a number of traps, how do I get fixes for these problems? :ANSWER. **************************************************************** COMMON PROBLEM #17: (MS Windows client only) Traps & WCL0321 **************************************************************** PROBLEMS: TRAPS: After starting the LAN Distance Windows BETA the next step usually is to bring up the settings notebook. On certain machines a trap would occur when the user selected the PHONE BOOK tab or attempted to enter modems or ports. This trap only occurred on certain machines but when it did occur it occurred regularly. These files also fix a number of other unspecified traps. WCL0321 - CANNOT DIAL FOR LEASED LINES: Can start LAN Distance, however, when you try to dial a leased line, you will get a WCL0321 error message. You would find multiple bearer capability lines in the WCLDIAL.CXD file. Add this fix, re-configure in Settings (or hand edit the file \WAL\WCLDIAL.CDX, locate the section for the permanent outgoing call directory entry, then remove the first Subfield Bearer Capability line), then dial. GRAPHICAL USER INTERFACE: These files modify the graphical user interface slightly to add some usability features. SOLUTION: From the VM Command prompt, type: REQUEST LDPR17 FROM BETASRUS AT AUSVM1 These are the steps to install the LDPR17 package when you receive if from your VM reader: 1) Stop IBM LAN Distance MS Windows client. 2) Back up these files, rename them to something like: CFMAIN.OLD WCLCFG.OLD 3) Download the LDPR17.EXE file file in binary 4) At the command prompt, unzip this self-extracting file using the command: LDPR17 5) You should now have three files: CFMAIN.EXE WCLCFG.MSG LDPR17.TXT -- this file you are now reading 4) Place the two files (CFMAIN & WCLCFG) into the \WAL subdirectory (for the MS Windows client only). 5) Start LAN Distance, MS Windows client. :from.Rick Ragan, IBM Austin. ----- REMOTE ANSWERS appended at 16:17:58 on 94/01/10 GMT (by RAGAN at AUSVM1) :ndx.PCMCIA01 :abs.COMMON PROBLEM #18: README changes for PCMCIA, section 2.6 :key.PCMCIA README :QUESTION. How do I get the PCMCIA modems to work with LAN Distance, the README file is not correct? :ANSWER. **************************************************************** COMMON PROBLEM #18: README changes for PCMCIA, section 2.6 **************************************************************** PROBLEMS: The README file shipped with IBM LAN Distance, version 1.0 has an error in Section 2.6 - Using the LAN Distance Remote product with IBM PCMCIA adapters. The file: ICPMU02.SYS should be ICRMU02.SYS. SOLUTION: The lines where this error occur are: INCORRECT: Name = $ICPMOS2.SYS IBMTOKCS.OS2 IBM2SS02.SYS ICPMU02.SYS CORRECT: Name = $ICPMOS2.SYS IBMTOKCS.OS2 IBM2SS02.SYS ICRMU02.SYS CHANGE is to one character> | ---------------------------------------------------------------------- Below is the corrected version of Section 2.6 with a clarified set of DEVICE= lines, corrections are marked with an "*". ---------------------------------------------------------------------- 2.6 - Using the LAN Distance Remote product with IBM PCMCIA adapters If you install the LAN Distance Remote product on a LAN-attached workstation, the Shuttle function automatically will enable you to switch from the LAN-attached environment to the standalone environment where the LAN Distance Remote product will function. If your LAN-attached workstation contains an IBM PCMCIA Token-Ring Adapter, you must complete Steps 1 & 3 after installing the LAN Distance product and before you shuttle to the standalone environment. 1. Edit the \IBMCOM\MACS\IBMTOKCS.NIF file. a) Find the FILEŁ section. b) On the "Name =" line, add all required device driver names in * order. For example, the IBM ThinkPad requires this order: * DEVICE=x:\XXX\$ICPMOS2.SYS * DEVICE=x:\IBMTOKCS.OS2 * DEVICE=x:\IBM2SS02.SYS * DEVICE=x:\ICRMU02.SYS If your LAN-attached workstation contains a PCMCIA asynchronous modem adapter, you must complete Steps 2 & 3 after installing the LAN Distance product and before you shuttle to the standalone environment. 2. Edit the \IBMCOM\MACS\PDFH.NIF file. a) Find the FILEŁ section. b) On the "Name =" line add all required device driver names in * order. For example, the IBM ThinkPad requires this order: * DEVICE=x:\$ICPMOS2.SYS * DEVICE=x:\PDFH.OS2 * DEVICE=x:\IBM2SS02.SYS * DEVICE=x:\ICRMU02.SYS 3. Copy all of the device drivers mentioned in the "Name =" line to the \IBMCOM\MACS subdirectory if they are not already there. The required device drivers are described in the PCMCIA Adapter documentation and included on the Adapter's accompanying diskette. The device driver names are specific to each brand of adapter. The \IBMCOM\MACS\PDFH.NIF file is shipped, installed, and required by the LAN Distance product. PDFH.OS2 is its associated device driver. NOTE: this editing technique can be used for any multiple device drivers adapter requiring a particular order in CONFIG.SYS. :from.Rick Ragan, IBM Austin. ----- REMOTE ANSWERS appended at 16:20:47 on 94/01/10 GMT (by RAGAN at AUSVM1) ..... REMOTE ANSWERS modified at 14:59:30 on 94/01/14 GMT (by RAGAN at AUSVM1) :ndx.FILTER01 :abs.COMMON PROBLEM #19: AUTOMATIC Filtering :key.Filtering Line-dropping :QUESTION. My LAN Distance connection drops from time to time, or I cannot access my domain, or I think filter criteria is difficult to set up, what can I do to make filtering easier? :ANSWER. **************************************************************** COMMON PROBLEM #19: AUTOMATIC Filtering **************************************************************** | improvements to Automatic Filtering, new IBMFLTR.OS2 file FILTER PROBLEMS: While Filtering works correctly in the Shipped version of IBM LAN Distance (and in the 3rd beta), the LAN Distance Development team has created a new type of filtering that can be used in place of (or along with) the earlier Filter Criteria. We call this new type of filtering: Automatic Filtering. It is a one-step solution to what was a demanding task of finding Address Filters, SAP filters, NetBIOS Names, or using the Bit mask. Automatic Filtering is designed to work with small LANs, with complex LANs, with Token-Ring LANs, and with Ethernet LANs. Why do you need filtering at all? Filtering keeps the high-volume LAN traffic from flooding the slower async WAN wire. Symptoms include the LAN Distance Connection Server's modem's TD (transmit or send) light is on most of the time, or your connection drops a different times (busy times) of the day. PHILOSOPHY: When the LAN Distance Remote workstation dials into the LAN Distance Connection Server, the application using the LAN Distance Remote product (for instance, the IBM LAN Requester) sends out LAN traffic containing a destination names to the IBM LAN Server. Similar techniques are automatically applied to applications using other protocols (e.g., TCP/IP). The new Automatic Filtering in LAN Distance will notice this address and automatically make a list of the destination names for each Remote workstation. Only the LAN traffic from those LAN workstations (IBM LAN Servers) responding to the LAN Distance Remote workstations will be transmitted back over the WAN wire to the Remote workstations. The other LAN activity is automatically filtered under the covers, without having to set any filter criteria. This filtering is now on a per-port basis, so the filtering is done for each Remote workstation, not (as LAN Distance 1.0 had in the past) for all Remote workstations dialing into a Connection Server. RESTRICTIONS: Automatic Filtering works well for most environments. If you follow this sequence, the restrictions below may not apply: Step 1) Start LAN Distance and connect Step 2) Start LAN client (e.g., IBM LAN Requester) Step 3) Logon onto the LAN. If the above steps are not followed in sequence, then the following exceptions may exist when using IBM LAN Server: 1) Currently, IBM LAN Server functions may not work when run on the LAN Distance Remote workstation (i.e., IBM LAN Server on LAN Distance Remote) when using Automatic Filtering. 2) Currently, Automatic Filtering will not allow the LAN Distance Connection Server to forward Netbios Broadcast Datagrams from the LAN to the Remote workstation. For example: If you use the NET SEND * command with IBM LAN Server or Requester (e.g., NET SEND * Hello World) from a LAN workstation, the LAN Distance Remote workstations may not receive this message if the LAN Distance Connection Server is using Automatic Filtering. 3) Currently, Automatic Filtering *may* prevent a LAN Distance Remote workstation using IBM LAN Server's Administrative functions in some LAN environments. For example, in the Statistics and Logs section you may not see all LAN Servers on the Domain (e.g., Action > Statistics & Logs > Statistics, NET function). SOLUTION: All of these changes are made strictly at the LAN Distance Connection Server, no changes are made to the Remote workstation. While the next release of LAN Distance may contain Automatic Filtering and the selection of Automatic Filtering would be a single step (select the check box that says: "Automatic Filtering"), the steps below are slightly involved due to the fact that we are placing this new function into a shipped product that was not originally designed for this function. WARNING: There is a chance that adding this new function into your IBM LAN Distance software may disrupt the function of LAN Distance. If this occurs, please report this problem via the forums and follow Steps 17-19 to remove Automatic Filters and to restore your Filter Criteria. If you have configured the LAN Distance bridge to have Filter Criteria (Bridge tab), you should turn these filters off so that you can test the power and ease at which the Automatic Filters work: To request the binary file over VM, please type at the VM command line: REQUEST LDPR19 FROM BETASRUS AT AUSVM1 Turn off existing Filter Criteria: If you have defined LAN Distance Bridge Filter Criteria, you can disable this type of filtering with the following steps (1-7): 1) Start LAN Distance 2) Open as Settings 3) Select the Bridge tab 4) De-select the Filter Criteria item in the "Select Filter Criteria" list box (on page 2 of 3). You do this by using the space bar on your keyboard. Once de-selected, the item will not have a black bar through it. 5) Close Settings 6) You will receive a Message: "You have defined Bridge Filter criteria..." This message is asking if you are aware that you have created Filter Criteria, but do not have the filtering criteria selected. You do not need Filter Criteria with Automatic Filtering (you can go back and select this if you wish after you have seen how well Automatic Filtering works. Automatic Filtering and Filter Criteria can work at the same time). Select the "Cancel" pushbutton so that you will *not* activate any filter criteria. You will get a message asking "Do you want to save the Settings notebook values?" select the "Yes" pushbutton. 7) Stop the LAN Distance Connection Server. Download the LDPR19.EXE file: 8) Download LDPR19.EXE in binary into a \TEMP subdirectory. 9) At the OS/2 command prompt, unzip this self-extracting file with the following command: LDPR19 10) You should now have three files: IBMFLTR.OS2 CRC value: X'A0CA' MACFH.OS2 CRC value: X'C932' LDPR19.TXT <--- This file you are now reading. Modifying the LAN Distance files: 11) Copy IBMFLTR.OS2 (provided above) to the x:\WAL directory. 12) Backup the shipped file named MACFH.OS2 in the x:\IBMCOM\MACS directory, with the command: COPY MACFH.OS2 MACFH.OLD 13) Copy MACFH.OS2 (provide above) to the x:\IBMCOM\MACS directory. 14) Using the System Editor, add the following DEVICE line to \CONFIG.SYS. The DEVICE line can be placed at the very end of CONFIG.SYS. The "x" is the drive where you have installed LAN Distance, replace this letter with the letter that applies to your workstation. WARNING: do not edit this file unless you are familiar with editing system files. DEVICE=x:\WAL\IBMFLTR.OS2 15) Shutdown all other applications and re-start your workstation. 16) When the LAN Distance Connection Server is started and a LAN Distance Remote workstation dials in, Automatic Filters will be working. How to stop Automatic Filtering and return to using only the Filter Criteria in LAN Distance, version 1.0: 17) Using the System Editor, remove the DEVICE line in \CONFIG.SYS. You can do this by either deleting the DEVICE line, or by placing the three letters REM in front of this line. WARNING: do not edit this file unless you are familiar with editing system files. Change: DEVICE=x:\WAL\IBMFLTR.OS2 To: REM DEVICE=x:\WAL\IBMFLTR.OS2 18) (Optional) Restore the shipped file named MACFH.OS2 to x:\IBMCOM\MACS directory, with the command: COPY MACFH.OLD MACFH.OS2 19) Shutdown and restart your workstation. :from.Rick Ragan, IBM Austin ----- REMOTE ANSWERS appended at 16:22:55 on 94/01/10 GMT (by RAGAN at AUSVM1) :ndx.CM200001 :abs.Common Problem #20: Communications Manager/2, versions 1.01 :key.Communications Manager /2 :QUESTION. What can I do to get Communications Manager /2 1.01 to work with LAN Distance? :ANSWER. ***************************************************************** Common Problem #20: Communications Manager/2, versions 1.01 ***************************************************************** | dropped the CM/2 2.0 version (does not exist yet) SYMPTOMS: 1) Communications Manager/2, version 1.01 may not work over LAN Distance even though Communications Manager/2 1.0 did. You may receive the COMM695 error. - AND - 2) OS2PING works for the -SR option, but not for the -R option. PHILOSOPHY: Communications Manager/2, version 1.01 has changed their LAN broadcast frames from Source Route to General Broadcast. The advantage is that any hardware bridges that use to reject all Source Routing frame will now pass CM/2 frames. The disadvantage is that bridges (both LAN Distance's software bridge and your LAN's hardware bridge) may reject General Broadcasts information if the hop count is too low. By moving from CM/2 1.0 to CM/2 1.01, your LAN Distance Connection Server's hop count may be too low or your hardware bridges hop counts may be too low to pass CM/2 1.01 General Broadcast frames. SOLUTION: If CM/2 1.01 does not work with LAN Distance, you will have to increase your LAN Distance hop count, or even increase the hop count for your hardware bridges. Here is what you should do... Use OS2PING to ping the 3270 Controller destination address. If the command: OS2PING /A=123456789ABC -SR -R returns, but the command OS2PING /A=123456789ABC -R does not return, then increase your LAN Distance Connection Server's (Bridge tab) hop count based upon the number of bridges displayed in your -SR information (count each ---> symbol as a bridge, which is one hop). (NOTE: -SR creates a Source Route frame, while the absence of -SR creates a General Broadcast frame. The -R value is to display the information.) If after increasing the LAN Distance hop count to the correct value (or higher), and the OS2PING command with the -R value still does not return (and CM/2 still does not work), either move the LAN Distance Connection Server closer to the 3270 Controller (on a closer LAN Segment) or contact your LAN Administrator to increase the hop count of your hardware bridges. --------------------------------------------------------------- Optional Notes: IF OS2PING DOES NOT RETURN AT ALL: If the command: OS2PING /A=123456789ABC -SR -R does not return, then check your 3270 Destination Address. With busy LANs, you can increase your wait time by adding the -w=60 to the end of the command (60 seconds can be changed to any value). OS2PING /A=123456789ABC -SR -R -W=60 USE ONLY -R TO GET CONN SERVER'S LAN SEGMENT RING NUMBER: The -SR option may invert your LAN information. If you are trying to determine the LAN Segment Ring Number for the LAN Segment on which your Connection Server is located (in order to configure your LAN Distance Connection Server, Bridge tab), then use only the -R option (see the LAN Distance Adv Guide, Appendix E on OS2PING for more information). The -SR option may reverse the order of the LAN Segments and bridges. The -SR option is useful (as stated above) to determine if your version of CM/2 is using Source Route or General Broadcast frames. :from.Rick Ragan, IBM Austin. ----- REMOTE ANSWERS appended at 14:35:38 on 94/01/28 GMT (by RAGAN at AUSVM1) :ndx.0WCL0349 :abs.Common Problem #21: Persistent WCL0349 Returned :key.NetBios Conversation has been lost :QUESTION. What do I do if I get the WCL0349 erro message: NetBios Conversation has been lost, and all calls drop? :ANSWER. ***************************************************************** Common Problem #21: Persistent WCL0349 Errors Returned ***************************************************************** SYMPTOMS: With a number of OS/2 LAN Distance Remote Workstations connected to a LAN Distance Connection Server, all calls may suddenly drop with the WCL0349 - "NETBIOS CONVERSATION HAS BEEN LOST" message displayed at the remote. Subsequent attempts to redial fail with the WCL0310 or WCL0349 messages. Only rebooting the server will fix the problem. BACKGROUND: LAN Distance uses Netbios during the call establishment and hangup phases. Under high usage conditions a memory leak can occur, depleting LAN Distance's internal buffers. Once depleted incorrect buffer lengths are reported to Netbios, resulting in the reported error. This memory leak occurs only when calls drop unexpectedly. The most likely environments for this to occur are when noisy lines are in use, or when shutting down the Remote Workstation with calls still connected. SOLUTION: Apply the fix module, WCLCPSRD.DLL to the OS/2 LAN Distance Server or Remote Workstation experiencing the problem. To receive a copy of the patches contact IBM Service at 1-800-992-4777 and reference APAR number IC06610. APAR: IC06610 :from.Rick Ragan, IBM Austin ----- REMOTE ANSWERS appended at 14:38:37 on 94/01/28 GMT (by RAGAN at AUSVM1) :ndx.TRAP0001 :abs.Common Problem #22: Conn Server traps during logon/off :key.Call established Trap :QUESTION. What do I do if when I logon to my LAN Distance Conn Server I get a trap error when the call is established or hung up? :ANSWER. ***************************************************************** Common Problem #22: Server Traps during Logon/Logoff ***************************************************************** SYMPTOMS: When logging on or off of a LAN Distance Server from an OS/2 LAN Distance Remote as part of call establishment or hangup, the server may trap. SOLUTION: Apply the fix module, WCBSEC.DLL to the LAN Distance Server or OS/2 Remote Workstation experiencing the problem. To receive a copy of the patches contact IBM Service at 1-800-992-4777 and reference APAR number IC06607. APAR: IC06607 :from.Rick Ragan, IBM Austin ----- REMOTE ANSWERS appended at 14:41:18 on 94/01/28 GMT (by RAGAN at AUSVM1) :ndx.0SYS3175 :abs.Common Problem #23: SYS3175 Message during shutdown :key.SYS3175 close main container :QUESTION. What do I do if I get a SYS3175 message when I try to close the main container, also I get the WCL0530 message? :ANSWER. ***************************************************************** Common Problem #23: SYS3175 Message during shutdown ***************************************************************** SYMPTOMS: When closing the main container of LAN Distance (OS/2 Remote or Connection Server), you may sometimes get a SYS3175 Message displayed. Subsequent attempts to restart LAN Distance fail with the message: WCL0530E: The LAN Distance product did not start in the time allowed. This problem can only be fixed by rebooting. SOLUTION: Apply the fix modules, WCLCPME.DLL and WCLCPMER.EXE to the LAN Distance Server or OS/2 Remote Workstation experiencing the problem. To receive a copy of the patches contact IBM Service at 1-800-992-4777 and reference APAR number IC06608. APAR: IC06608 :from.Rick Ragan, IBM Austin ----- REMOTE ANSWERS appended at 14:43:53 on 94/01/28 GMT (by RAGAN at AUSVM1) :ndx.DRIVE001 :abs.Common Problem #24: SYS3175 Message during startup from D: :key.SYS3175 Drive D: Startup :QUESTION. What do I do if I get a SYS3175 message from my OS/2 LAN Distance workstation when LAN Distance is installed on a drive other than C:? :ANSWER. ***************************************************************** Common Problem #24: SYS3175 Message during startup from D: drive ***************************************************************** SYMPTOMS: On an OS/2 workstation, if LAN Distance is installed and started from any drive other than C:, a SYS3175 message may be displayed when LAN Distance is started. SOLUTION: Apply the fix modules, WCLCPME.DLL and WCLCPMER.EXE to the OS/2 LAN Distance Server or OS/2 Remote workstation experiencing the problem. To receive a copy of the patches contact IBM Service at 1-800-992-4777 and reference APAR number IC06471. APAR: IC06471 Rick Ragan, Austin, TX :from.Rick Ragan, IBM Austin ----- REMOTE ANSWERS appended at 16:47:06 on 94/01/28 GMT (by RAGAN at AUSVM1) :ndx.DLR00001 :abs.Common Problem #25: (MS Windows only) DOS LAN Requester :key.DOS LAN Requester :QUESTION. For the MS Windows client, I cannot logon usign the DOS LAN Requester, what do I do? :ANSWER. ***************************************************************** Common Problem #25: (MS Windows) DOS LAN Requester ***************************************************************** SYMPTOMS: MS Windows client of LAN Distance only: DOS LAN Requester cannot logon to the Domain Controller using DOS LAN Requester 2.0 or 3.0. SOLUTION: The DOS LAN Requester code (LS 2.0 and LS 3.0) has a bug that (incorrectly) defaults the Mail Slot number to 0 (zero). Corrective Service Diskette (CSD) 7003 will fix this problem. If you cannot get CSD 7003 easily, you can add the following parameter to the x:\DOSLAN\DOSLAN.INI file: /NMS:3 This will specify 3 rather than the incorrect default of 0 as the correct Number for the Mail Slot. Rick Ragan, Austin, TX :from.Rick Ragan, IBM Austin ----- REMOTE ANSWERS appended at 16:51:19 on 94/01/28 GMT (by RAGAN at AUSVM1) :ndx.TCPIP001 :abs.Common Problem #26: (MS Windows only) TCP/IP fails :key.TCP/IP :QUESTION. For MS Windows client, I cannot get TPC/IP to work, what do I do? :ANSWER. ***************************************************************** Common Problem #26: (MS Windows) TCP/IP fails ***************************************************************** SYMPTOMS: For the MS Windows client of LAN Distance only: TCP/IP fails to work. SOLUTION: From the VM command line, type: REQUEST LDPR26 FROM BETASRUS AT AUSVM1 1) Download the file LDPR26 EXEBIN in binary. 2) Type at the DOS command prompt: LDPR26 this will produce: LDPR26 TXT -- what your are now reading PROTMAN.DOS - the binary file. CRC=X'5D02' 3) Back up the file x:\WAL\PROTMAN.DOS (COPY PROTMAN.DOS PROTMAN.OLD) 4) Copy the new file to x:\WAL\PROTMAN.DOS. 5) In the file CONFIG.SYS, move the statement DEVICE = x:\TCPIP\BIN\DOSTCP.SYS to the last line of this file after all other DEVICE and DEVICHIGH statements. 6) Make sure you have run TCPSTART.BAT before starting MS Windows, place this command in your AUTOEXEC.BAT 7) Re-start your workstation. Rick Ragan, Austin, TX :from.Rick Ragan, IBM Austin ----- REMOTE ANSWERS appended at 23:48:38 on 94/02/07 GMT (by RAGAN at AUSVM1) ..... REMOTE ANSWERS modified at 17:22:25 on 94/02/09 GMT (by RAGAN at AUSVM1) :ndx.SHUTTLE1 :abs.COMMON PROBLEM #25: Shuttle with PCMCIA adapters :key.PCMCIA Shuttle :QUESTION. What do I do if I cannot get my PCMCIA adapter to work with LAN Distance's shuttle function? :ANSWER. ***************************************************************** Common Problem #27: Shuttle produces incorrect config.sys with PCMCIA adapters ***************************************************************** SYMPTOMS: APAR: IC06532 (1) Shuttle may change the order of some of the PCMCIA DEVICE= statements in config.sys. (2) Second, shuttle may lose a parameter on the PCMCIA socket services device driver (IBM2SS01.SYS) or on a PCMCIA modem device driver (ESTDFM.OS2). SOLUTION: ORDERING PROBLEMS: To fix the first problem (device ordering) perform the following steps: If you have an IBM PCMCIA Token-Ring Adapter perform step (1). (1) Edit the \IBMCOM\MACS\IBMTOKCS.NIF file. a) Find the FILE section. b) On the "Name =" line, add device drivers that are order dependent in their correct order. This will differ from one machine model to another and it will differ depending on what version of Card and Socket Services you have. Here's an example for how to edit the file for an IBM ThinkPad 750C: Name = IBMTOKCS.OS2 IBM2SS01.SYS ICRMU02.SYS This will result in these device drivers being added to the end of CONFIG.SYS in this order. If you have a PCMCIA modem, perform step (2). (2) Edit the \IBMCOM\MACS\PDFH.NIF file. a) Find the FILE section. b) On the "Name =" line, add device drivers that are order dependent in their correct order. The following is an example for the IBM PCMCIA and Megahurtz PCMCIA modems: Name = ESTDFM.OS2 PDFH.OS2 IBM2SS01.SYS ICRMU02.SYS This will result in these device drivers being added to the end of CONFIG.SYS in this order. (3) Copy all device drivers that you placed on the Name = line the above .NIF files to the \IBMCOM\MACS subdirectory. The required device drivers are described in your PCMCIA Adapter documentation and included on your Adapter's installation diskette. The device driver names are specific to each brand of adapter. The \IBMCOM\MACS\PDFH.NIF file is shipped, installed, and required by the LAN Distance product. PDFH.OS2 is its associated device driver. NOTE: This editing technique can be used for any multiple device drivers adapter requiring a particular order in CONFIG.SYS. MISSING PARAMETER PROBLEMS: Fix module, WCLSHUTL.DLL, has been made available to correct the problem. This fix is to be applied to all Remote Workstations experiencing the problem. This fix module will fix parameters lost for the IBM2SS01.SYS and ESTDFM.OS2 device drivers. NOTE: It is possible that shuttle may lose parameters for other device drivers depending on how you edit your IBMTOKCS.NIF and PDFH.NIF files to correct the ordering problem described above. If you have edited one of these .NIF files and have had to place a different device driver requiring parameters on the NAME= line, you must perform the following so that the shuttle feature will maintain your parameters: (1) Edit the WCLLOCAL.INI file in your \WAL subdirectory. In the SHUTTLE section add two lines describing the name of your device driver and its parameter. For example, if your SHUTTLE section looks like: SHUTTLE D1 = IBM2SS01.SYS P1 = /S0=1 and you have a device driver named XYZ.OS2 that needs parameter /A, add the following lines so that your shuttle section looks like: SHUTTLE D1 = IBM2SS01.SYS P1 = /S0=1 D2 = XYZ.OS2 P2 = /A NOTE: If you use LAPS to change your LAN protocol configuration, your parameters may be deleted again. If so, simply use shuttle your LAN Distance remote workstation and the parameters will be restored. (Or edit your CONFIG.SYS.) A LAPS fix will be available in the near future. To receive a copy of the patches contact IBM Service at 1-800-992-4777 and reference APAR number IC06532.