Outpost Packet Message Manager
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 
Setup problems 
No troubleshooting notes available
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):
The user reported this solved the problem and Outpost did open correctly.
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.
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.
this is not immediately possible or this release does
to resolve the problem, then notify KN6PE of the problem, and then do the following:
2012: Problems, Errors, or unexpected results running Outpost after installing on Vista, Windows 7 
Runtime Error 6 Overflow when deleting a TNC, BBS config running on Vista, Windows 7 
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:
CAUSE: The problem seems to point to the Microsoft's VirtualStore implementation.
BACKGROUND: The general consensus of those working the issue is that the error condition is associated with data that is (or should be) written to Vista or Windows 7's VirtualStore. The VirtualStore is part of Microsoft's User Account Control (UAC) File Virtualization subsystem. It essentially changes the target file path for a legacy process (Outpost?!) that tries to create a file in a system-global location (like C:\Program Files). The legacy process believes that the operation succeeds when it really created the file in different location that is fully accessible by the user. This does not happen when running a Windows Vista (and Windows 7) application with standard user rights.
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:
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:
After you have installed Outpost (or any "legacy" program for that matter) and you find things are not working quite as intended, you can run the program in compatibility mode or as administrator, or both. To do that:
NOTE: The above 2 methods were confirmed by users with this problem. Your results may vary. If you identify another method, please let KN6PE know.
SPECIAL THANKS to David W7DMM, Gary KC6USN, Brent, Bob K6HEW, and Cap KE6AFE for helping to characterize and experiment with solutions to get this resolved.
causes a Runtime Error
DESCRIPTION: After installing
Outpost and running one if its programs, any one of
the following error messages are
most common cause is when Outpost is installed on an
Windows XP, Vista, Windows 7, or Windows 8 system
without Administrative privileges.
BACKGROUND: Outpost needs to be installed from account with administrative privileges to ensure it can access its various data and configuration files correctly.
RESOLUTION: The most common resolution for this is to uninstall the program, and re-install it from an account with administrative privileges.
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.
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.
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.
NOTE! After installing the driver, do not forget to restart the computer.
Here is a summary of what I have heard from several users:
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:
are 2 ways to correct this problem:
Determine the correct BBS Command
Prompt, then enter it in the BBS Setup menu:
2. Upgrade to Outpost v2.2. This version automatically detects the prompts for most popular BBSs currently in use.
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.
are 2 ways to correct this problem:
2. Upgrade to
Outpost v2.2. This
version simplifies the BBS setup for this
customization as follows:
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.
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:
RESOLUTION: See the app note titled "Setting up KA-Node/Netrom network access" for a description of how to configure different kinds of nodes.
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.
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 >
For MFJ-127X, do the following:
1. From Outpost, Setup >
SYMPTOM: When connecting to the the a BBS by telnet, I see the following character string:
by Telnet to Host ab8cd.no-ip.org...
CAUSE: The "˙ű" character sequence is part of the Telnet Protocol.
BACKGROUND: Telnet supports
a series of handshakes between 2 connecting stations.
See the Telnet
RFC for details on the protocol. In this
The user saw commands sent to the TNC (a KPC-3+) that should have
CAUSE: KPC3 was not operating correctly.
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.
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.
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.
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.
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.
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.
implements Hardware Flow Control (handshaking) with the
this to work, you need to do 2 things:
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
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.
Outpost connects and retrieves message from the
Telpac/RMS node, but messages with email addresses in
the destination are not sent, and the user gets the
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 (firstname.lastname@example.org). To properly qualify an internet address, the "SMTP:" prefix is required as part of the address entry (example: SMTP:email@example.com).
RESOLUTION: Add the "SMTP:" prefix to the front of all internet addresses.
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.
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.
SYMPTOM: Outpost hangs with Telpac after the message listing.
CAUSE: Outpost incorrectly determined the Telpac prompt.
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...
KN6PE VIA KE6AFE-10 DE K4CJX >
In this example, this string is repeated as the prompt for all normal user interactions. Outpost sets the prompt as " K4CJX >"... the last 8 characters.
However, for the 2 other Telpac nodes in the SF Bay Area, the first instance of this string is:
Connected via WA6LIE-10 to CMS Detroit >
Outpost calculates the prompt to be "etroit >"... the last 8 characters. However, all subsequent prompts sent by the Telpac node are only ">". Because Outpost is looking for a "etroit >" string and never sees one, Outpost stops processing.
So what does it do this? It appears that some Telpac operators are connecting to PMBOs (Participating Mail Box Office) for the message feeds, some are connecting directly to the CMS (Common Message Server). The CMS reference in the prompt above seems to imply a Telpac to CMS link. It is not clear if this is a standard configuration.
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.
RESOLUTION: If this is the only Telpac node in
your area that you can access, this can be resolved in
1st field: for Command Prompt, enter... ">"
2. Request that the Telpac node sysop change the PMBO away from a CMS station to a PMBO station.
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.
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  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  for the workaround to this problem.
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:
AEA-, DSP-232 PBBS
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.
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)
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.
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:
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>
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.
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.
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.
RESOLUTION: Turn off this feature on the BBS. While all BBSs are not the same, the AA4RE BBS had an "unlisted" command that is part of the BBS user registration process that sets this up. Check your BBS command list for something similar. I found the "(N) Register" command under the Miscellaneous command group. On AA4RE BBS, entering a "H N" (Help on the "N" command) gave me this output:
Type H if you need Help>
The command to use is "NS".
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.
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.
BACKGROUND: Outpost expects each type of BBS to generate its message listing in a specific order and format, see the KPC3 BBS page for a description of what is expected. If the date or time format is not set up correctly, Outpost will fail to decode these fields, stop processing the message list, and end the Send/Receive Session. In the reported cases for this problem, the date/time format was changed to be inconsistent with what Outpost was expecting.
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:
cmd: DAYSTR mm/dd/yy hh:mm:ss
Again, do not enter the actual time, just the format. See the DAYTIME command for setting the current date and time of day.
2. Hard Reset of the TNC. To restore to the default factory settings (including the date/time format), enter the following TNC command:
cmd: RESTORE Default
This command will force the TNC back to it's original factory default settings, perform the AUTOBAUD routine, and erase PBBS memory (deleting all messages, and non-default PBBS parameter settings). I recommend you enter this command as a last resort.
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
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:
cmd: Streamev OFF
Setting STREAMSW to 0 got rid of the bar (|). Setting Streamev to OFF turned off the display of the stream and stream switch. The resulting Send/Receive display was then clean and messages could be retrieved.
SYMPTOM: When retrieving messages from a KPC3-P, Outpost generated a Date/time conversion error. The message listing looked like this:
MSG# ST SIZE TO FROM DATE SUBJECT
14 B 424 ALL N4XXX 05/02/2009 51:43:19 DCA-117: Welcome...
13 PN 1277 KE4ZZZ N4XXX 05/02/2009 51:33:46 RE: DIGIPEATERS...
6 B 47 ALL KE4ZZZ 04/26/2009 21:39:38 DIGIPEATERS AND...
ENTER COMMAND: B,J,K,L,R,S, or Help >
Note the time is 51:43:19 when the message was actually sent at 11:43
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.
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
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
Only the first 13 lines of this message were saved. The 14th line contained the string...
... 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.
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.
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...
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.
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"
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:
OSO:KI6AG-1} Welcome back.
,,, and Outpost stops, still waiting for the TNC prompt.
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.
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.
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.
Please send any feedback to
updated: July 10, 2010