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 [1000]

Setup problems [2000]

No troubleshooting notes available

Send/Receive problems [4000]

Problems when interacting with the TNC [4100]

Problems connecting to the BBS [4200]

Problems sending a message to the BBS [4300]

Problems retrieving the BBS message list [4400]

Problems retrieving a BBS message [4500]

Other Problems talking to the BBS [4600]

Problems for other reasons [4700]

Viewing Message problems [5000]
No troubleshooting notes available

Interactive Packet Window problems [6000]

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:



Could not open the file named:
C:\Documents and Settings\username\My Documents\My Downloads\Software\Ham Radio Software\Outpost\op220c194_contents\

[     OK     ]

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]

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,

  • deleting a BBS (one of the provided samples) caused runtime 6 error.
  • deleting a BBS that was user-added (not one of the samples that came with Outpost) will cause all of the local ones to be deleted (conclusion: it must be going to a different file).

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. 

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:

  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.

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:

  1. Right-click on the program icon (i.e.: Outpost.exe) and then choose 'Properties'.

  2. In the Properties window, click on the 'Compatibility' tab.

  3. Under Privilege Level, check the option titled  'Run this program as an administrator'.

  4. Also, under Compatibility mode, check the option titled 'Run this program in compatibility mode for:' and then choose an OS from the drop down list, in this case 'Window XP (Service Pack 2)'.


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.

Return to Top

2014: Various Runtime Errors

SYMPTOM:Running program causes a Runtime Error

DESCRIPTION:  After installing Outpost and running one if its programs, any one of the following error messages are displayed:

  • Runtime Error 53 File not found
  • Runtime Error 75 Path or file access error
  • Runtime Error 380 Invalid Property Value
  • Runtime Error 429 ActiveX Component can't create object

CAUSE:  The 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.

Return to Top

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=31This 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:

 Adaptor Windows XP Windows Vista
IO Gear works works
Airlink Adaptor works mixed; fails with 8020 for one ham, worked for another on Vista.  No information on the Vista or driver versions used.
Quatech www.quatech.com works works; this is a Vista certified adaptor.

Return to Top

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 earlierThe 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: 

Help > KPC3, KAM prompts, note the space between "Help" and ">" 
Help> AA4RE BBS, note this example does have a space after "Help"
ARES> DXNET BBS, custom prompt
W6XJC BBS> F6FBB Example, custom prompt

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, 1st 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:

PBBS Connect Command Disconnect Command
PK-88, PK-232, DSP-232 mdcheck bye
MFJ-127x sysop cntl-c
all other TNCs connect bye

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:

Connecting by Telnet to Host ab8cd.no-ip.org... 
˙ű˙űCallsign :

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 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

SYMPTOM: The user saw commands sent to the TNC (a KPC-3+) that should have been 
my KJ6xx-n" but were displayed back in Outpost as "my J6xx-n".  Essentially, the K was lost.  Further checking pointed to the1st character of all strings sent back from the TNC were missing.

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.

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

SYMPTOM: 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 following error: 
Address error - please try again...

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.

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...


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.

See also: [4415] Outpost hangs when connecting to a WL2K/CMS after the message listing.

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.

PREVIOUS RESOLUTION: If this is the only Telpac node in your area that you can access, this can be resolved in this manner:
1. User defines prompts that will work in limited situations:
(i) Go to Setup > BBS..., Tab 1 (BBS Name). Check "User Defines the BBS prompts"
    (ii) Go to Setup > BBS..., Tab 2 (BBS Commands).  Set the prompts as follows:

         1st field: for Command Prompt, enter...  ">"
         2nd field: uncheck the box, enter...        "
been sent >" (include all spaces)
         3rd field: leave checked, defaults to the Command Prompt.

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.

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:

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

Msg#   TSLD  Dim  To    @ BBS   From   Date/Time Title
117    PNL     23 KR6CO         KN6PE  1212/1302 New info
   T$L    141 95014 @NTSCA  KN6PE  1230/0957 QTC 1 …

 1244 PN    85 N9AAA  KB9BBB   W9WK  040208  NTS Message
 1243 PN   190 N9AAA  KB9BBB   N6NKO 040208  EOC Status

Msg#  Stat Size To          From Cnt Date/Time Subject
31704 P     327 KN6PE@N0ARY KN6PE  0 0925/0921 CUP108: 
31653 P B   208 KN6PE@N0ARY KE6AFE 1 0924/0433 KI msg

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

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 BBSsIf 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:

? O

O-command gives you different options:
O alone shows you what language you are using, paging & base-number.
- Type OP to toggle paging on messages.
- Type OP [number-of-lines] to select paging with a specific number
  of lines per page.
- Type OL alone to get a list of available languages.
- Type OL[space][language-number] to choose a language.
- Type ON alone to see your base-number.
- Type ON [number] to choose a new base-number. The number you type, 
  will be multiplied by 1000, so if you type ON 54, your base-number 
  will be 54000.  After that, you can type R 25 to read message 
  number 54025.  It is also allowed to type ON 54000.
- Type OR to choose if you want to be able to list and read all 
  personal messages in the BBS (if your BBS allows this...).
- Type OM to choose if you want to receive the list of new messages 
  at every connect.


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.

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>
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 "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.

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.

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.

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:

cmd:|A*** CONNECTED to K0ABC-1
You have mail.
(AEA PK-232M) 18396 free (A,B,H,|AJ,K,L,R,S,V,?) >
|AMsg# Size To From @ BBS Date Time Title
|A 13 PN 56 N9DEF K0ABC 02-Apr-08 20:05 DELIVERED: Repeater Status

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
cmd: Streamsw 0

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.

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:


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...



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:

"The only way I have seen the date/time go awry, is when the real-time clock chip has been installed, but a Hard Reset was NOT done after installing that chip.  The Hard Reset is needed, because those real-time clock chips default to 12 hour time (am/pm), but the KPC keeps time in 24 hour format.  After installing that chip, the KPC Hard Reset will configure that chip for 24 hour time.  If the Hard reset was not done, the display of hours will be in error after 12:59:59 pm (instead of going to 13:00:00)."

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
315 PM CST TUE JAN 4 2005
315 PM CST
TUE JAN 4 2005

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.

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...

# 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

#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:

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.  

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

General Feedback

Please send any feedback to

updated:  July 10, 2010