Most of the Outpost problems fall into one of the following categories.  Additions to the different troubleshooting topics will be made as problems are identified and answers become available.

Installation, 1st time run problems [1000]

• Outpost fails with Error 339... dependency not properly registered [1010]

• Outpost fails to install...  "Could not open file named ..\SETUP.LST" [1012]

• Problems, errors, or  unexpected results running Outpost after installing on Vista, Windows 7 [2012]

• Runtime Error 6 Overflow when deleting a TNC, BBS config on Vista, Windows 7 [2012]

• Runtime Error 52 File not Found [2014]
• Runtime Error 75 Path or File Access error [2014]
  
• Runtime Error 380 Invalid property value [2014]
• Runtime Error 429 ActiveX Component can't create object [2014]

Setup problems [2000]

• Runtime Error 6 Overflow when saving a TNC, BBS config [2010]

No troubleshooting notes available

• <cntl-c> does not put the TNC back into command mode. [6110]
• Outpost fails to connect to a WL2K Node by Telnet [4260]

Don't see your problem listed?
If you don't see your problem listed here, please submit it either to the OutpostPacket Users Group or to KN6PE.

1010: Outpost fails with Error 339... dependency not properly registered [1140]

SYMPTOM: When running Outpost for the first time on Vista, a program error message is displayed.

DESCRIPTION:  The user reported installing Outpost v2.2 on a Vista Ultimate system.  On running Outpost for the first time, this error message was received.

CAUSE:  TABCTL32.OCX is a file delivered with the Outpost installation that supports the tabbed dialog box control that Outpost uses.  For some reason, this file did not get registered correctly when installed.  It has been reported (internet search of "Error 339 Vista Install TABCTL32.OCX") that when you install older control files on Vista, sometimes the controls (dll's or ocx's) do not register because the installer did not run the setup program with  administrator privileges.  Even though the reporting \user did have administrative privileges, this problem still occurred.

RESOLUTION:  This was resolved as follows (per the answers.yahoo link found during the above search):

"Create a shortcut to your regsrv32.exe put the shortcut  in the folder with your tabctl32.ocx (usually c:\WINDOWS\System32).  Right click on your shortcut for regsvr32.exe and find the checkbox to run as administrator.  Then drag and drop the ocx onto the shortcut."

The user reported this solved the problem and Outpost did open correctly.

Return to Top

1012: Outpost fails to install... "Could not open file named ..\SETUP.LST [ 1150]

SYMPTOM: After unzipping the Outpost install files and on running the setup.exe, an error occurred and the Outpost installation could not be completed.  The error message was:

CAUSE:  Note the length of this path to the installation files (~116 characters long).  While detailed analysis or research into this problem was not performed, it is believed that the pathname to the install files is too long.  

BACKGROUND:  The user reported that the Outpost op221c194.zip file contents was unzipped into a 'contents' folder, and then tried to run the setup program from there... that's when it failed. 

When the 'contents' folder was moved to the root of C:, the setup program completed and Outpost was successfully installed.

RESOLUTION:  The Outpost installation README.TXT suggests setting up a temp directory close to the root directory C:, such as "c:\optemp".  All users experiencing this problem are advised to follow this guidance.  Additionally, the installation README.TXT will be updated to reflect this situation.

Return to Top

2010: Runtime Error 6 Overflow when saving a TNC, BBS config

SYMPTOM: Outpost aborts after you attempt to save a TNC or BBS configuration.

CAUSE:  The TncInfo.dat and BbsInfo.dat files were copied off of the CD-ROM as read-only.  This seems to be a case for any files copied off of a CD-ROM.  Additionally, versions earlier than v2.2.1 did not check for this condition.

BACKGROUND:  The user reported copying, among other files, a TncInfo.dat and BbsInfo.dat file from a CD to their program directory.  After entering a new configuration and pressing Apply or OK, Outpost aborted with a "Runtime Error 6 Overflow" message.

RESOLUTION:  This exact problem was resolved with Outpost v2.2.1.  If you are on an earlier version, please download and apply the latest upgrade to resolve.  

If this is not immediately possible or this release does to resolve the problem, then notify KN6PE of the problem, and then do the following:
  1.  Right-click on each file that was copied off of the CD-ROM.
  2.  Select Properties
  3.  In the Attributes section, uncheck "Read-only".  Press OK.

Return to Top

2012: Problems, Errors, or unexpected results running Outpost after installing on Vista, Windows 7 [1284][1285]

Runtime Error 6 Overflow when deleting a TNC, BBS config running on Vista, Windows 7 [1265]

SYMPTOMS: 
1. After installing Outpost on a Vista O/S, the user got the error message: Runtime Error 75: Path/File access error.  The program would not continue.

2. When attempting to delete either a TNC or BBS, the user gets the error message "Run-time error '6';" and "Overflow".  On clicking OK in the message box, Outpost closes and the respective file (TncInfo.dat or BbsInfo.dat) is gone (as in deleted).  Additionally,

This problem was observed on these O/S versions:

• Vista 64 Ultimate (2 reports)

• Vista Home Premium with Service Pack 2 (2 reports)

• Two machines running Windows 7

CAUSE:  The problem seems to point to the Microsoft's VirtualStore implementation. 

For a more detailed explanation of UAC and Virtualization, see this TechNet Magazine article by Mark Russinovich titled "Security: Inside Windows Vista User Account Control".

RESOLUTION:  Two approaches were confirmed to have resolved the problem, both are described here.

Method 1 - Change the Installation Directory

One user determined that the problem could be mitigated by installing Outpost in a different directory other than the default Windows programs directory, thereby bypassing the Virtualization subsystem.

Vista 64: After removing the entire Outpost installation from his Vista 64 computer, the user installed Outpost in the directory "C:\Programs - Other" instead of the standard "C:\Program Files (x86)" directory.  To do that:

1. Run Outpost's opsetupXXX .exe install program.

2. At the "Select Destination Location" form, change the install directory to something else (I recommend it be something similar so it sorts with the other Program directories) like "C:\Programs - Other\Outpost".

3. Continue the rest of the installation process as usual.

On completion, he was then able to delete a BBS without the error message, and Outpost operated and terminated correctly.  The user ran Outpost with his standard user privileges.  

On  Vista 32, he similarly installed Outpost to a directory other than "C:\Program Files" that also eliminated the problem.  The user ran Outpost with his standard user privileges.

Method 2 - Change Program Administrator and Compatibility Settings

Another user determined that the Microsoft UAC was not working as expected.  Although you may be logged in with an administrator account, it may not really install with full system privileges.  To get around that: 

1. Before running Outpost's opsetupXXX.exe install program, right-click on this .exe and choose 'Run as administrator'.  Then, run the installation program as usual.

Return to Top

2014: Various Runtime Errors

4110: Problems with the TNC

SYMPTOM: The Session Manager hangs when interacting with the TNC.

DESCRIPTION:  A user reported: When I press Send/Receive, the Send/Receive window opens, the TNC sends a few lines of text, but Outpost does not respond.

CAUSE:  The user changed the default TNC Prompt, or entered an incorrect prompt, when setting up the TNC.

BACKGROUND:  Most TNCs have a command prompt of “cmd:”  This is the default TNC prompt set by Outpost.  If you must change the TNC prompt, it must match EXACTLY with what is displayed by the TNC.  This is case-sensitive.

RESOLUTION:  If you need to change the prompt, copy it exactly as it is shown from the TNC.  Use Outpost's Interactive Packet Window or another TNC Program to see what is returned by the TNC.  Refer to the TNC manual if uncertain or if you cannot find it.

Return to Top

4120: Problems with the TNC [1007, 1075]

SYMPTOM: The Packet Session Window displays control characters from a MFJ-1274, and no processing occurs.

CAUSE: The Serial Port is incorrectly setup.

BACKGROUND:  During TNC Session, the user was able to connect, but then only received garbage characters.  The cause of this was the Comm Port set to 4800-E-7-1.  

Outpost seems to have a problem with the E-7-1 configuration that has not yet been isolated.  All N-8-1 processing works fine.

RESOLUTION: Change the TNC and Outpost settings to N-8-1.  Use whatever baud rate you have set. 

Return to Top

4130: Run-time Error 8020: Error reading comm device [1207, 1259]

SYMPTOM: User was trying to connect to a KPC on COM4 [using a USB-to-Serial adaptor] with ipserial.exe, The O/S was Vista.

CAUSE: Problem was with the USB-to-Serial adaptor driver.

BACKGROUND:  The error 8020 has to do with a problem between a USB->serial device driver and the VBA comm software.  drivers written for Windows XP may not handle certain parameter-passing functions correctly when used in Vista or Windows 7.

RESOLUTION: It took awhile for the user to find an updated driver for his USB device. Whereas the vendors' website did not have a Vista driver available, the user eventually went to the website of the manufacturer of the chipset used in the adapter and found an updated driver.

To determine what type of device you have, with the adapter attached, look at the system hardware configuration under Control Panel>System>Hardware>Device Manager.  It will tell you the type of serial adapter.

If it is a Prolific chipset- based adapter (many inexpensive adapters are), then the driver can be downloaded from their website: http://www.prolific.com.tw/eng/downloads.asp?ID=31.  This solution worked under both Vista and Windows 7.

4210: Problems connecting to the BBS

SYMPTOM: The Session Manager connects to the BBS and then stops.

DESCRIPTION:  A user reported that when he pressed Send/Receive, the Packet Send/Receive Window showed that Outpost initialized the TNC, connected to the BBS, but then stopped.

CAUSE:  This problem has occurred in Outpost v2.1 and earlier.  The BBS Prompt is not set up correctly. 

BACKGROUND: Unlike the TNC, there is no default BBS prompt that is set up as a default prompt when creating a new BBS in Outpost.  When you enter the BBS prompt, it must match EXACTLY with what is displayed by the BBS.  This prompt is case- and space-sensitive.  For instance, the prompt "HELP>" is not the same as "HELP >" (the difference is the space).

For users of Outpost v2.1 and earlier, Outpost needs to know about the TNC and BBS Command Prompts as the way to detect when it should send the next TNC or BBS command. Outpost reads the text strings sent by the BBS, checks if the BBS Prompt is present, then acts on it.  If it does not find a BBS command prompt and one was obviously sent by the BBS, then it will wait forever or until the user Aborts the session.

All BBS Command Prompts end with a “>”.  It is recommended that you set the command prompt to ensure it is a reasonably unique string. Some examples of BBS Command Prompts are: 

RESOLUTION:  There are 2 ways to correct this problem:
1.  For users of v2.1 and earlier, use the Outpost Interactive Packet Window or another TNC Program to see what is returned by the BBS.  Manually connect to the BBS, and note the last string that looks like a prompt for a BBS command (ends in a ">").

Determine the correct BBS Command Prompt, then enter it in the BBS Setup menu:
       Setup >> BBS >> BBC Prompts Tab, 1^st field.  Press OK.

2.  Upgrade to Outpost v2.2.  This version automatically detects the prompts for most popular BBSs currently in use.

Return to Top

4230: Problems connecting to the BBS

SYMPTOM: Outpost connects to the AA4RE (W6XSC-1) then stops at the Tactical Call Prompt.

CAUSE:  The BBS Tactical Call Prompt is not set up correctly.

BACKGROUND: This problem should only be encountered with Outpost v2.1 or earlier, and by members of Santa Clara county (CA) RACES who use the AA4RE BBS with the Tactical Call customization (W6XSC-1 BBS).  See the the details about the AA4RE BBS.

RESOLUTION:   There are 2 ways to correct this problem:
1. For users of Outpost v 2.1 and earlier, verify the BBS is set up as follows:
     Setup >> BBS,  BBS Prompts Tab
        "Command:" = "Help>"  (no space in the prompt)
        "Tactical Call required" = box is checked
        "Tactical Call:" = "call sign" (these exact words... this is also case sensitive)
        Press OK

2.  Upgrade to Outpost v2.2.  This version simplifies the BBS setup for this customization as follows:
     Setup >> BBS,  first Tab
     Under "BBS Type:", check the box = "AA4RE BBS with Tactical Call Customization"

Return to Top

4240: Problems connecting to the BBS

SYMPTOM: Outpost reports that the BBS is not supported.

CAUSE:  The BBS type has not been defined and set up in Outpost.

BACKGROUND: Beginning with v2.2, Outpost now positively identifies the BBS by type to ensure the message list and messages are processed correctly.  See the list of BBSs that are currently supported.

RESOLUTION:   If you do not see your BBS on the list, follow the instructions to submit your BBS for support.

Return to Top

4250: Problems connecting to the BBS [1095]

SYMPTOM: Outpost does not connect to the next station in the node path.

CAUSE:  The node's port number to the next node/station is not correctly set up.

BACKGROUND: Outpost allows you to configure a list of KA-Nodes and/or Netrom nodes as a means for getting to a BBS that is out of range.  KA-Nodes are Kantronics nodes listen and respond to a single frequency.  Netrom nodes, such as the G8BPQ Packet Switch can be configured with multiple ports on different frequencies or bands.  Because of this flexibility, a user can connect to a BPQ Packet Switch on on frequency (example: 2 meters on Port 1) and then connect to the next station in the path on a different frequency (example: a 440 frequency on Port 3).

When defining a node in Outpost, you need to tell Outpost 4 things:

1. What is the connect name to this port?
2. What is the message this node will send back when the connect is successful?
3. What is the port number to take out of this node to get to the next station in the path?
4. What is the message this node will send back if the connect to the next node is unsuccessful?

RESOLUTION:   See the app note titled "Setting up KA-Node/Netrom network access" for a description of how to configure different kinds of nodes.

Return to Top

4260: Problems connecting to the BBS [1112]

SYMPTOM: Outpost fails to connect by Telnet to a W2LK node (Transparency Mode Error).

CAUSE:  The telnet protocol to a Winlink node requires Transparency Mode.

BACKGROUND: 30-May-07: The following are excerpts from John W5EJ on this problem: The difference between Winlink/Telpac and F6FBB is that the BBS's are interactive allowing users to manually login and issue commands.  In contrast, Winlink stations by telnet expect all sessions to be automated in nature hence the transparent mode where the session input is stream-based where all control characters are ignored versus normal interactive mode where backspace and other characters are recognized.  Telnet emulators usually have a command syntax that puts the emulator in this mode, and it is unclear how the Telpac or Paclink applications have implemented this.

RESOLUTION:   This issue has been resolved with Outpost v2.3.  Please download the latest version to resolve this issue.

Return to Top

4270: Problems connecting to the BBS [1105]

SYMPTOM: Can't connect to a PK-88/232 or MFJ-127X PBBS when it is directly connected to the PC.

CAUSE:  Local connect commands are different for PK-232/88 or MFJ-127X PBBS.

BACKGROUND: 3-June-07: For the sake of this hint, a "locally connected" PBBS is a TNC configured for PBBS access that is physically connected to your PC by a serial or USB-to-Serial cable.

Both the TimeWave (PK-xxx, DSP-xxx) and MFJ TNCs do not use the standard "connect" command when attempting to connect to a locally connected PBBS.  Additionally, the MFJ-127X PBBS do not use the standard  "bye" command for a local connect as well.

RESOLUTION:   There are a series of changes that you need to make to access a PBBS that is locally connected:

For PK-232/PK-88/DSP-232, do the following:

1.  From Outpost, Setup > TNC...  .  
2.  Create a new TNC called "PK232-DIRECT" or something like that.
3.  Select the 3rd Tab. change the 2nd command field value from "connect" to "mdc".
4.  Press OK.
5.  Run Outpost's send/receive session as usual.

For MFJ-127X, do the following:

1.  From Outpost, Setup > TNC...  .  
2.  Create a new TNC called "MFJ1270-DIRECT", or something like that.
3.  Select the 3rd Tab. Change the 2nd command field value from "connect" to "sysop".
4.  Press OK.
5.  From Outpost, Setup > BBS...  .  
6.  Select the 3rd Tab. Change the last command field (Bye/Log off) value from "B" to "cntl-c"
     (spell it out as shown here).
7.  Press OK.
8.  Run Outpost's send/receive session as usual.

Return to Top

4280: Strange characters are displayed when initially connecting by Telnet

SYMPTOM: When connecting to the the a BBS by telnet, I see the following character string:

BACKGROUND: Telnet supports a series of handshakes between 2 connecting stations. See the Telnet RFC for details on the protocol.  In this case...

** the "ÿ" means "Interrupt as Command", and is the first of a 2 byte sequence, followed by...
** the "û" says it WILL support function "", whatever "" decodes to be.

The above example was from a JNOS BBS.  However, other BBS-by-Telnet situations have shown similar behavior.  IN these examples the BBS was letting the connecting station know that it DOES (WILL) support 2 functions. This is not a problem, and Outpost essentially ignores these characters.

Return to Top

4290: Missing 1st characters in TNC Session Window

RESOLUTION: TNC Reset:  The user performed a hard reset on the TNC, and the problem was cleared up.

BACKGROUND: Outpost sends the TNC and BBS commands to the TNC, and it is the TNC that echo's back that Outpost displays.  In this case, the TNC was in some erroneous state and was truncating the 1st character.

Return to Top

4310: Problems sending a message to the BBS

SYMPTOM: After pressing Send/Receive, the message does not get sent. (1)

CAUSE: 1st situation: This message to be sent is not in the Out Tray.  Only messages in the Out Tray are sent.

RESOLUTION: If the message is not in the Out Tray, (i) Select the folder where the file exists, (ii) open the message, then (iii) press SEND.  If the message is valid, the message will be re-saved and stored in the Out Tray.

Return to Top

4320: Problems sending a message to the BBS

SYMPTOM: After pressing Send/Receive, the message does not get sent. (2)

CAUSE: 2nd situation: The message is in the Out Tray, but is not in a Valid state.  A valid message is when the BBS, FROM, TO, SUBJECT, and Message fields are all filled in.

RESOLUTION: Check for a valid message by pressing the Send Button on the message form.  If it is valid, the message form will close.  If it is not valid, the field that is missing will be highlighted and Outpost waits for the user to fill it in.  Or, press Cancel.

Return to Top

4330: Problems sending a message to the BBS

SYMPTOM: After pressing Send/Receive, the message does not get sent. (3)

CAUSE: 3rd situation: The message is opened for editing when the TNC Session Manager runs.

BACKGROUND: When a new or existing message is opened, it is LOCKED and unavailable for sending.  A message to be sent must not be opened for viewing or editing for it to be sent.

RESOLUTION: (i) Close the message, then either (ii) press Send/Receive from the Outpost main form, or (iii) wait for the next automatic Send/Receive cycle if it is set up.

Return to Top

4340: Problems sending a message to the BBS

SYMPTOM: After pressing Send/Receive, the message does not get sent. (4)

CAUSE: 4th situation: The message in the Out Tray is addressed to a different BBS than what is currently selected in Outpost.   

BACKGROUND: When Outpost starts a Send/Receive Session, it connects to the selected BBS (displayed on the Status bar), and then looks in the Out Tray for valid messages that are addressed to this BBS.  Messages addressed to other BBSs are not sent.

RESOLUTION: From the Out Tray, (i) Select the message to be sent, (ii) open the message, (iii) change the BBS to the current BBS, then (iv) press SEND.  Or, choose a different BBS from the Outpost Setup menu.  The message will be sent during the next session.

Return to Top

4350: Problems sending a message to the BBS [1015]

SYMPTOM: Outpost hangs when sending a large message.

CAUSE: Outpost has overflowed the TNC input buffer.

BACKGROUND: When Outpost sends a message the TNC, it normally sends the entire message package (SP command + Subject Line + Message) to the TNC in one burst.  However, for large files, this data transfer can overflow the TNC’s input buffer before the TNC has had time to send it out, thereby causing the TNC to hang.

RESOLUTION:  Outpost implements Hardware Flow Control (handshaking) with the TNC.  For this to work, you need to do 2 things:  
(i) Use a serial cable that includes the CTS line.  It is recommended that you use a full 9-wire shielded RS-232 serial cable between the PC and the TNC.
(ii) Accept the default Outpost TNC’s serial port setting as “RTS/CTS” (hardware) flow control turned on.

If this setting is on and you still experience hangs as described here, confirm that CTS is correctly wired in your interface cable.

For details on serial cables,  http://www.zytrax.com/tech/layer_1/cables/tech_rs232.htm

Return to Top

4360: Problems sending a message to the BBS [1025]

SYMPTOM: Outpost hangs after a few packets are sent using a custom cable.

CAUSE: Incorrectly wired Interface cable.

BACKGROUND: The messages are several hundred bytes or more but nowhere near 5000 bytes.  The user reported that the flow control was not working.  The configuration had a non-standard pin-out on it's DB-9 connector where it placed CTS on pin 5 which is normally SIGNAL GROUND !!!! 

RESOLUTION:  Use a commercial serial cable whenever possible.

Return to Top

4370: When sending a message to Telpac/RMS, user gets an address error

CAUSE: The internet email address does not have the SMTP: prefix.

BACKGROUND: Messages sent from Outpost to Telpac/RMS can have multiple destinations in the To: message address field.  The destinations can either be a standard call sign (KN6PE) or an internet email address (k6kp@addr.net).  To properly qualify an internet address, the "SMTP:" prefix is required as part of the address entry (example: SMTP:k6kp@addr.net). 

RESOLUTION:  Add the "SMTP:" prefix to the front of all internet addresses.

Return to Top

4372: Outpost hangs when sending a message, TNC resets to command mode [1149]

SYMPTOM: Outpost is connecting to a KPC3 PBBS with a KPC3 TNC.  After sending a message, the TNC unexpectedly shifts back into Command Mode, causing Outpost to hang.  The user has to press Abort Session to end the Send/Receive Session.

CAUSE: A TNC parameter was incorrectly set.

BACKGROUND: It is unknown which TNC parameter was incorrectly set.  The TNC was only one week old, and may have had an errant setting left in from the Factory.

RESOLUTION:  User had to perform a hard reset on the KPC3 by entering the "RESTORE Default" command.  Outpost worked after that point.  The conclusion here:  on receiving any new hardware, it may be wise to perform a hard reset to ensure you are starting with a good known state.

Return to Top

4380: When sending a message to Telpac/RMS with an KAM TNC [1130]

SYMPTOM: Outpost connects the Telpac/RMS node, but during the Send portion of the session, an Invalid Stream message appears.  

CAUSE: This appears to be caused by a KAM TNC with version v2.06.

BACKGROUND: The submitter of this problem troubleshot the problem to the KAM that he picked up at a local flea market.  He subsequently confirmed the problem was the KAM.  He had two systems running Winpack, one uses AGW and a sound card, the second is using the KAM.  Using the system running Winpack + AGW + soundcard, he was abll to send an email to the address successfully. Using Winpack + KAM system, he got the same error.

RESOLUTION:  KAM with Firmware versions earlier than v2.7 may be problematic and will not be supported by Outpost.  See the Kantronics website for their Firmware Versions.

Return to Top

4410: Problems retrieving the BBS message list

SYMPTOM:  Outpost hangs with Telpac after the message listing.

BACKGROUND:  Outpost’s auto-prompt detect feature assumes the first time it sees a line from the Telpac node (or any other BBS for that matter) ending with a ">", this string is a prompt and anything preceeding the ">" preceding it is part of the prompt. This is the case for several Telpac nodes in the SF Bay Area that return a complete prompt string like this...

However, for the 2 other Telpac nodes in the SF Bay Area, the first instance of this string is:

RESOLUTION: Spring 2008: This issue should have been resolved with the updated release of CMS and the RMS package.  IF you are still experiencing problems, please send your transactionyymmdd.log files to KN6PE for evaluation.

NOTE: Using only a ">" is not a strong prompt sequence.  This approach sets the command prompt to only ">" and could easily be matched to a portion of the message text string if someone forwards an internet mail message where there are a lot of the ">" in the 1st position of each row indicating a forwarded message.

Return to Top

4415: Problems retrieving the BBS message list

SYMPTOM:  Outpost hangs when connecting to a WL2K/CMS after the message listing.

CAUSE:  Outpost decoded the CMS  prompt incorrectly.

BACKGROUND:  This issue is almost identical to [4410] Outpost hangs with Telpac/RMS after the message listing except, in this case, Outpost connects directly to the CMS server instead of through a Telpac/RMS Node.

RESOLUTION: See the Resolution Section for issue [4410] for the workaround to this problem.

Return to Top

4420: Problems retrieving the BBS message list

SYMPTOM: Outpost hangs after retrieving the message listing.

CAUSE: For Outpost v2.1 and earlier, the BBS message listing is not interpreted correctly.

BACKGROUND: The first thing Outpost does in preparation for retrieving messages is to retrieve the list of messages addressed to you that exist on the BBS.  It sends a “LM” for list mine, or “LB” for list bulletins, or “LT” for list NTS traffic.  Outpost then parses the message list into its component parts: BBS message number, Status, Size, To, From, Date, Time, and Subject.  The order of these fields IS CRITICAL for Outpost to work.  Outpost recognizes the following Message List formats for these BBS applications and TNC-based PBBSs:

AA4RE  BBS
Msg# TR  Size   To         From   Date/Time Subj
 207 PY  1004 WA6ZTY       KN6PE  0712/0505 NTS Message
 205 PY   456 WA6ZTY       KN6PE  0703/1809 Field Day

MSYS  BBS
MSG # TR  SIZE TO     FROM    @BBS    DATE    TITLE
 1244 PN    85 N9AAA  KB9BBB   W9WK  040208  NTS Message
 1243 PN   190 N9AAA  KB9BBB   N6NKO 040208  EOC Status

KPC-x  PBBS
MSG#  ST SIZE  TO     FROM   DATE             SUBJECT
45    PN 148   K6TEN  KN6PE  02/26/04 23:36:23  Radio Test
44    PN 152   KR6CO  KN6PE  02/26/04 23:36:03  Creek Watch

AEA-, DSP-232  PBBS
Msg#    Size To     From  @ BBS  Date       Time   Title
  6 PY   222 KR6CO  KN6PE        12-Dec-04  10:38  New info

While the layout is generally the same between listings, the BIG difference has been the date/time format.  If your BBS message listing does not match one of the above, Outpost will hang. 

Outpost v2.2 now knows explicitly the layout of each BBS, thereby taking more of the uncertainty of message list processing out of the picture.  This problem should not occur with v2.2.

RESOLUTION: For users on Outpost v2.1 or earlier, upgrade to Outpost v2.2.  This new version is more robust with its BBS handling and supports an explicit list of BBSs.  If you do not see your BBS on the list, see the instructions on how to submit it for support.

Return to Top

4430: Problems retrieving the BBS message list

SYMPTOM: Outpost generates an Error 13 Type Mismatch with F6FBB

CAUSE: The date format was set up differently on the F6FBB BBS than what Outpost was expecting.

BACKGROUND: Outpost was connecting to a Linux version of the F6FBB BBS that was using the default date format.  There is an F6FBB file "english.txt" (in the /etc/ax25/fbb/lang directory) that contains the internationalization strings for English that are dynamically set at run-time.  In this case, the $i and $j parameters control the date format as follows:

$i : Date and time of the message header (Format MMDD/HHMM)
$j : Date of the message header (Format 29-Dec)

RESOLUTION: This is a simple change for the Linux F6FBB BBS Operator.  Set the date format parameter to "$i" .  The variables are documented here: http://www.f6fbb.org/fbbdoc/doc.htm, then click on Variables. 

Return to Top

4431: Problems retrieving the BBS message list

SYMPTOM: Outpost hangs with F6FBB after retrieving the message listing. (2)

CAUSE: The Message List field order was set up differently on the F6FBB BBS than what Outpost was expecting.

BACKGROUND: F6FBB provides a great deal of flexibility when setting up the look and feel of the BBS.  In this case, the user reconfigured the Message List line to support a specific user's need where the field order was significantly different, resulting in Outpost not correctly parsing the fields. 

RESOLUTION: In the F6FBB file "english.txt" (located in the /etc/ax25/fbb/lang directory), find and confirm the Message List configuration line is set up as follows:

#
$WMsg# TSLD Size To @ BBS From Date/Time Title (LC-choice: $l)$W
# Contents of each line when listing:
$M $t$s$r%r $n $G$0 $P $i $1$W

The variables are documented here: http://www.f6fbb.org/fbbdoc/doc.htm, then click on Variables. 

Return to Top

4440: Problems retrieving the BBS message list [1030]

SYMPTOM: Outpost stops when the BBS asks a question that is unexpected.

CAUSE: The BBS is in "new user" mode and not Expert Mode.  

BACKGROUND: Some BBSs have a new user mode that guides the user through the interaction with the BBS.  The prompting is verbose (read: excessive) and not conducive to automated handling by Outpost.  Outpost assumes it is talking to a BBS in Expert Mode with no superfluous prompts being displayed.

RESOLUTION:  Manually log on to the BBS and reset the user mode for your logon to Expert.  For example, on the W6XSC-1 BBS (AA4RE BBS software), entering a "H N" (Help on the "N" command) gave me this output:

Type H if you need Help>
h n
NE       - Toggle your "expert user" status.
NH xxxxx - Enter your 'Home BBS'. Aids in routing mesages to you.
NN xxxxx - Enter your first name into user data base.
NZ xxxxx - Enter your zip code into user data base.
NF x     - Change the format of message listings.
           Allowed values of x are from 0 to 4.
NL x     - Change your language setting (only works if your BBS
           supports multiple languages)
NP xxxxx - Change your telephone modem port password. Can only be
           issue from modem port.
NS l w   - Change your screen size info. l = length, w = width
Type H if you need Help>

The command to use is "NE".

For F6FBB BBS, enter an "? O" (Help on the "O" Option Command) to get this output:

The "OP" command to toggle between 20 lines per page or No Paging.  You want No Paging.  Also, Set select Expert Mode with the "X" command.

For MSYS BBS, the user must change his or her users settings to expert on, and lines set to zero.  This can be done two ways. 

1. The user can do it by logging on to the BBS with a terminal program (Hyperterm or Outpost's ipserial.exe) and issue the command "X 0"  ("0" in this statement is the number zero). 

2. The sysop can also do it from MSYS's F-1 screen and do EU for edit user and the callsign. When scrolling through the setting your going to change user to an expert and the lines to 0 (again the number zero).

Return to Top

4450: Problems retrieving the BBS message list [1048]

SYMPTOM: There is no text when we retrieve messages.

CAUSE: This is still under investigation.

BACKGROUND: The TNC used is an Alinco DR235 w/ EJ-41U, a TNC that appears to be the problem.

RESOLUTION:  Unknown as of  3/22/05.  Any additional information people can send me on this would be helpful.   Until this is better understood, Outpost does not support the Alinco DR235 w/ EJ-41U TNC.

Return to Top

4460: Problems retrieving the BBS message list [1011, 1013]

SYMPTOM: Outpost stops when the BBS asks "press enter to continue... "

CAUSE: A user setting on the BBS is incompatible with Outpost.

BACKGROUND: Outpost connects to the BBS and starts to download a message, but when the BBS sends "Please enter a blank line to continue, anything else to halt output",  Outpost doesn't send a response. Thus, only the first few lines of the message are received.  The same occurs for very long message listings.

This situation occurs on some BBS's where the BBS is set up to pause every so-many lines (usually 20) so the user could read the message.  This feature was extensively used before the days of PCs and would prevent the text from scrolling off the screen of a dumb terminal that had little or no memory.

To resolve the problem for the W6XSC-1 users, using Outpost's Interactive Packet Window (or some other terminal program), log into the BBS and type "NS".  It will either (i) show you the screen height and screen width setting, or (ii) prompt you for new settings.  If it prompts you, enter "0" at each prompt.  The "NS 0 0" should also do this in one command.  When done, exit from the BBS, run Outpost with this BBS configured, and try to retrieve the bulletins.

Your BBS should have a similar command like that shown above.

Return to Top

4470: Problems retrieving the BBS message list [1101, 1102]

SYMPTOM: Outpost generates an Error 13 Type Mismatch for the KPC-3/9612 PBBS

CAUSE: The PBBS Date/Time Format is not set configured correctly.

RESOLUTION: Reset the date/time format display. There are 2 ways of doing this:

1. Reset the Date/Time Format. The KPC-3 and KPC-9612 TNCs use the DAYSTR command to set the FORMAT of your date/time display. DO NOT enter an actual date or time, but simply enter the form of the display you would like. The format you enter is used for all time stamps, including the PBBS, KA-Node, Mheard list, etc.

For Outpost to work correctly, enter the following TNC Command exactly as shown:

Return to Top

4480: Outpost did not retrieve an NTS message I posted to the BBS

SYMPTOM: After sending an NTS message to the BBS, the message was not downloaded even though  I selected Retrieve NTS messages.

CAUSE: Outpost currently is designed not to retrieve NTS messages that the originator may have posted to the same BBS.

BACKGROUND:  In the original Outpost implementation, once an NTS message was posted BY SOMEONE ELSE, if Retrieve NTS was selected, Outpost retrieved and deleted the message.  To avoid deleting your own message, Outpost was designed not to retrieve NTS messages that you post.

Subsequently in Release v2.0, Outpost was changed to retrieve but not delete non-originated NTS messages.  The "Accept" option was added to the message form that allowed the receiver to decide whether they wanted to ACCEPT and service the message (and delete off the BBS) or skip this (and not delete it).

RESOLUTION: The question was posted to the Outpost users as to whether NTS message retrieval by the originator should be permitted.  The feedback received was that the implementation should be left as is (7-Jan-08).

Return to Top

4490: Outpost did not retrieve any message with KPC3 TNC [1148]

SYMPTOM: With a KPC3, Could send messages, but could not retrieve them even though there were messages visibly there.

CAUSE: KPC3's STREAMEV and STREAMSW parameters were not correctly set.

BACKGROUND:  The user saw the following in the Send/Receive text window:

Outpost expected to see a the Message Number as the first entry on the resulting LM listing.  Instead, it saw a "|A" thereby causing Outpost to disregarded the rest of the line and not retrieve the message.  

The STREAMEV command controls when the stream indicator is  displayed.  Additionally, the STREAMSW selects the character to be used to signify that a new "stream" or connection channel is being addressed.  Outpost does not expect or to see any stream indicators at all.

RESOLUTION: The user resolved this by entering the following TNC commands:

Return to Top

4491: Outpost cannot decode message time from a KPC3 PBBS [1232]

SYMPTOM: When retrieving messages from a KPC3-P, Outpost generated a Date/time conversion error.  The message listing looked like this:

CAUSE: A hard reset was not performed on the KPC3-P PBBS after a Clock Chip was installed.

BACKGROUND:  Ken from Kantronics Support provided the answer to this one:

RESOLUTION: User issued a hard reset and problem was resolved.

Return to Top

4520: Problems retrieving a BBS message

SYMPTOM: Outpost connects and displays the list of messages, but does not retrieve them.

CAUSE: The messages were previously downloaded, OR the “Keep on BBS” option is set.

BACKGROUND: There are 2 conditions when messages will be listed but not downloaded:

1. Previously downloaded Bulletin and NTS messages.  Outpost always checks to see if a bulletin or NTS message listed on by BBS were previously downloaded.  If it was, Outpost will not download it again.  Once the message is completely deleted from Outpost (first the In Tray and then from the Deleted Folder), Outpost will download it again.

2. Previously downloaded Private messages with the “Keep on BBS” flag set.  Usually, once a private message is downloaded, it is immediately deleted off of the BBS, UNLESS the “Keep on BBS” option was set (Tools >> Send/Receive Settings >> Receive Tab).  This option could be used if 2 sites are sharing the same tactical call and want to see the same messages.

RESOLUTION:  For Bulletins, the description above is standard Outpost functionality.

For Private messages, check the following:
1. Tools >> Send/Receive Settings >> Receive Tab.
2. Uncheck the “Keep on BBS” box.
3. Press OK.
4. Press Send/Receive.
3. Verify the Private messages are retrieved again, then are deleted off of the BBS.

Return to Top

4530: Problems retrieving a BBS message [1044]

SYMPTOM: Only a portion of a retrieved message was saved.  This occurred when retrieving a specific bulletin that someone else posted to the BBS.

CAUSE:  The BBS Prompt matched a portion of the message and ended Outpost's message retrieve process.

BACKGROUND: The BBS Prompt that was manually set up in Outpost was too short (not unique enough) and was matching text that was found in the message.  In this case, the BBS did have a prompt of “HELP >”.  However, the user set up Outpost with a  BBS prompt of only “>”.  This problem showed up when an attempt was made to retrieve the following Weather Bulletin:

WWUS43 KLOT 042120
WSWLOT
URGENT - WINTER WEATHER MESSAGE
NATIONAL WEATHER SERVICE CHICAGO IL
315 PM CST TUE JAN 4 2005
A WINTER WEATHER SYSTEM WILL BE MOVING OUT OF THE
SOUTHERN PLAINS AND INTO THE MID MISSISSIPPI VALLEY
THIS EVENING AND INTO THE OHIO VALLEY ON WEDNESDAY.
NORTHERN ILLINOIS WILL RECEIVE SIGNIFICANT
SNOWFALL.  AREAS IN NORTHWEST INDIANA AND LOCATIONS
SOUTH OF INTERSTATE 80 IN ILLINOIS WILL RECEIVE A
SIGNIFICANT ACCUMULATION OF SLEET AND FREEZING RAIN
FOLLOWED BY SNOW ACCUMULATION.
ILZ003>006-008-010>014-050300-
BOONE-COOK-DE
KALB-DUPAGE-KANE-LAKE-LEE-MCHENRY-OGLE-WINNEBAGO-
315 PM CST TUE JAN 4 2005
...HEAVY SNOW WARNING IN EFFECT UNTIL 4 AM CST
THURSDAY...
THE NATIONAL WEATHER SERVICE IN CHICAGO IL HAS
UPGRADED THE WINTER STORM WATCH TO A HEAVY SNOW WARNING.
THE POTENTIAL FOR HEAVY SNOWFALL OF 8 TO 12 INCHES IS
GREATEST NORTH OF A LINE FROM LEE COUNTY TO AURORA TO CHICAGO.
LIGHT SNOW SHOULD BEGIN THIS EVENING OVER LOCATIONS
NORTH OF INTERSTATE 88.  LOCATIONS SOUTH OF INTERSTATE
88 WILL RECEIVE SOME SLEET AND FREEZING RAIN THIS
EVENING BEFORE TURNING OVER TO SNOW.
ACCUMULATIONS OF 1 TO 3 INCHES IS EXPECTED BY MORNING.
 THE HEAVIEST SNOW WILL LIKELY OCCUR FROM THE EARLY
AFTERNOON THROUGH THE LATE EVENING HOURS ON WEDNESDAY.
SNOW SHOULD TAPER OFF TO SNOW SHOWERS FOR ALL OF
NORTHERN ILLINOIS AND NORTHWESTERN INDIANA LATE
WEDNESDAY NIGHT AND EARLY THURSDAY MORNING.
NORTHEAST WINDS OF 15 TO 25 MPH CAN CAUSE BLOWING AND
DRIFTING SNOW.

Only the first 13 lines of this message were saved.  The 14th line contained the string...

ILZ003>006-008-010>014-050300-

... where Outpost interpreted the “>” it read from the message as the configured BBS prompt, and subsequently stored only that portion of the message.

RESOLUTION: Change the prompt defined in Outpost to include more prompt characters than “>”.  In this instance, changing the prompt to “HELP >” resolved the problem. 

NOTE: Check the prompt on your BBS and confirm it is set up correctly in Outpost.

Return to Top

4540: Problems retrieving a BBS message

SYMPTOM: Only a portion of a message retrieved from an MSYS BBS is saved.

CAUSE:  The BBS Prompt was matched a portion of the message and ended Outpost's message retrieve process.

BACKGROUND: This is another variation of the above problem.  In this case, the BBS was an MSYS BBS, that only presents the BBS prompt as ">".

Outpost relies on the uniqueness of the TNC and BBS prompts to know when to send the next command.  The MSYS Prompt does not guarantee that uniqueness.  See the above issue for an example of what can go wrong.

RESOLUTION: Unfortunately, there is no easy answer for MSYS users.  One team in Illinois agreed that this is a user training issue and working to ensure users "pre-process" any copied messages off the internet prior to sending them by Outpost.  While this is not an ideal solution, it does work.

An offer was made to perform a message pre-process in Outpost and substitute the offending character with some other character sequence.  However, this approach would make the message somewhat incompatible and possibly mis-interpreted by non-Outpost users. 

The conclusion... don't send messages on the MSYS BBS with embedded ">" characters.

Return to Top

4550: Problems retrieving a BBS message

SYMPTOM: Outpost hangs with F6FBB via Telnet when retrieving messages.

CAUSE: The Telnet parameter was incompatible with Outpost.

BACKGROUND: This was reported by Bill VE7QC during the initial release of Outpost v2.0 and Telnet support.  When retrieving large files, the BBS prompt was not displayed at the end of the listing.  Outpost stopped and waited (patiently) for the prompt. 

RESOLUTION: Bill reported that he resolved the "stuck packets" problem as follows: in the F6FBB port.sys file, change the MaxFrame parameter from 7 (in Bill's case) to 1...

Before:
# Same number of lines as number of TNCs.
#
#TNC NbCh Com MultCh Pacln Maxfr NbFwd MxBloc M/P-Fwd Mode Freq
6   4     2  t1     250   7     2     20     10/60   UTYW Telnet

After:
#TNC NbCh Com MultCh Pacln Maxfr NbFwd MxBloc M/P-Fwd Mode Freq
6   4    2   t1     250   1     2     20     10/60   UTYW Telnet

Return to Top

4560: Problems retrieving a BBS message [1136]

SYMPTOM: Outpost does not retrieve messages from MSYS after running the KAGOLD program.

CAUSE: KAGOLD sets the KPC-3 LFADD command to ON. 

BACKGROUND: During the initial work with MSYS BBSs, it was determined that strings sent to the MSYS BBS should only be terminated by a Carriage Return (CRs).  Outpost was written to ensure that only CR-terminated strings were sent.  After a review of the logs from this user's sessions, it was clear that a Line Feed (LF) was being sent by the users' system.  The user also confirmed that this problem started after recently running the KAGOLD packet program.  

Apparently, KAGOLD does set specific TNC parameters on initializing the program, one of the parameters being the LFADD command (default is OFF).  The user confirmed that this parameter was now set to ON.

RESOLUTION: User was directed to reset the LFADD command to OFF, and confirmed this resolved the problem.

Return to Top

4610: Other BBS connect problems [1106]

SYMPTOM: Outpost hangs when exiting from a BBS connected through a TheNet X-1J4 node. 

CAUSE: The TheNet node is configured to reconnect to the node after a "bye" from the mailbox.

BACKGROUND: This node type offers a rich set of back-end configurations that control its behavior.  One of these configurations is listed as follows:

"Enable auto-reconnect to Node after "bye" from mailbox to neighboring node"
     0 = disabled
     1 = enabled

When Outpost exits from the BBS, it is expecting all nodes in the path to the BBS to disconnect.  This has been the observed case for KA-node and BPQ Packet switch nodes.  However, in the case when a TheNet node has the above setting enabled, on disconnecting from the BBS, instead of the node disconnecting and Outpost seeing the TNC prompt, the node replies with this message:

RESOLUTION:  The ideal solution is to work with the node sysop to get this setting changed.  Until the setting can be changed, the Outpost user needs to press "Abort Session" on the Send/Receive Manager form when you reach this point in the Send/Receive session. 

Information on the TheNet X-1J4 node is generally available on the web.  Check this link for a description of the configuration settings.  

Return to Top

4710: Problems for other reasons

SYMPTOM: The computer hangs and needed to be re-booted.

CAUSE: RF was getting into the computer through an unshielded interface cable.

BACKGROUND: The user discovered this one during one of his county’s drills.  There were 3 stations participating: 1 at the EOC and 2 in the field.  The EOC and Field Station "A" were  able to successfully send and receive messages with the BBS.  Field Station "B" would send a message, but the PC would immediately freeze.  The operator had to re-boot the computer to recover.  This occurred whenever the station sent in the standard report form by packet.

The user confirmed all Outpost configuration settings were identical between the 3 stations.  On closer inspection of Field Station "B", he discovered that the computer-to-TNC serial cable was a home-brew 3-wire cable.  He replaced the cable with a shielded commercial serial cable and repeated the check.  All messages were sent and retrieved successfully.

Unlike the manual interaction with a standard packet terminal program, Outpost sends large blocks of data to the TNC, and lets the TNC handshake with the BBS.  In this situation and because of these long TNC bursts, RF was getting into the PC through the unshielded serial cable, thereby causing the PC hang.

RESOLUTION: Use only shielded cables between devices, particularly in the presence of RF.

Return to Top

6110: Interactive Packet Window problems [1036]

SYMPTOM: Cannot issue a <cntl-c> to put the TNC back into command mode when it is connected to a BBS.

CAUSE: This is a problem with Outpost prior to v2.0 where the <cntl-c> was really for copying to the clipboard.

RESOLUTION: Upgrade Outpost to the latest version.  As of v2.0, <cntl-c> once again is passed to the TNC and lets the TNC put the user back into command mode.

To copy text from the IPW window, highlight the text, and select Edit > Copy from the menu.

Return to Top