USER of BBS FEATURES
JNOS supports multiple simultaneous users with services such as conferencing and email. The basic user service from JNOS is commonly called the 'mailbox' or BBS. It is very similar to most of the well-known amateur radio BBS programs.
This page is dedicated to the top-level understanding for the Site User who may be remote to the host with access via ham radio packet station to one of the RF ports or via Internet. The Site User can discover the neighborhood from the login text, using the INFO, JHEARD, IHEARD, IPROUTE, plus other commands at his/her disposal, and chatting with other users or the administrator.
BBS ACCESS
Access to jnos BBS on the local host is attainable using a variety of methods. This list is presented as an "Inbound" sense because this document is designed to describe the detail of the owners site. Access to remote sites is similar, but access is further complicated by remote software and configuration details. It is important to note that access may be widely available via Internet depending on network connections, firewall configuration, and permissions...
Here is a partial list of the options available from the:
Users host command line: ...$ telnet ip where the IP address is serviced by jnos on a local host or remote host known to the routing algorythms. The sysop should provide this address for site users from his configuration work.
Users host command line: ...> telnet localhost where "localhost" points to itself.
Users host GUI terminal window: ...$ telnet URL where “URL” name can be resolved by DNS into an IP on the network. Again, the sysop should provide the URL for the site users.
NOS BBS session: ...> connect port station-ssid where the station is accessable via AX.25 prootocol. The syntax and station ID will vary when used at remote hosts as the remote software in use and the stations accessable from that localle change.
NOS BBS session: ...> connect station where "station" (or alias) is known to the NET/ROM network over the AX.25 protocol.
NOS BBS session: ...> telnet URL where DNS can resolve the name and routing provides a path to the remote host.
jnos sysop console: ...> bbs is a shortcut for the telnet command.
The first response prompt from the site will be: “...login: “. This prompt is a request is for you to supply your userid. Upon a users first login (or: if you mis-spell your userid), a registration process is initiated to collect pertinent data. it is typical to use your own call as your userid and your first name as your password. While this practice does not meet contemporary Internet practices, it is seen as adequite for the closed amateur network over RF paths and encapsulated IP links.
The second prompt will be “passwd: “. A password is used to validate authenticity, it is unencripted thruout the entire process so don’t put great stock in secrecy.
Upon completing the login process successfully, the site will respond with the prompt string like:
You have 0 messages. Area: ve4klm Current msg# 0. ?,A,B,C,D,E,F,H,I,IH,IP,J,K,L,M,N,NR,O,P,PI,R,S,T,U,V,W,X,Z >
where “ve4klm” is the current area being viewed and “# 0” is the number of the first mail message waiting to be read. In all cases the BBS allows access to mail, bulletins, etc, per the permissions established by the owner / sysop of the node. Access to remote BBS's from jnos BBS is attainable via a variety of methods.
It sould be noted that if a remote site is also a jnos site that the prompt you see may be identical to the local site but the command will be processed by the remote site - so beware!
BBS COMMAND LANGUAGE
The command set available to the user is described in BBSCommands in detail and again in BBSCrib intended for quick use after printing the page for use as a crib sheet. The user commands may be abbreviated by using only the first letter of the command. As an example: entering "send" and "s" yeild the same results. Where commands have alternative forms, the command comes in two-letter form. Again for example: the "send response" varient of the "send" command is entered as "sr".
Now to expand on the commands a bit with some examples of use. There are many more than found here, it is the enginuity of the user and his/her ability to ferret out new twists from the Internet that will build on the basics presented herein:
GATEWAY SERVICES
One of the key features of BBS's in general is the ability to change hosts in a hop-scotch manner and obtain services of remote hosts. The process is generally known as connecting to other hosts. The varieties include basic manual, NET/ROM, etc, and the paths of interconnection include radio RF, and Internet.
Connect to a neighbor station over RF
In range of the radio used on a port, there are normally other packet radio stations. To contact those stations use the “connect" command. It is common but not required to announce the presence of the host using the beacon facility as set up by the sysop. Stations actively engaged in communications and beacon stations will be listed in the list from the command:
...> jheard
Upon choosing the desired station to contact, use the command:
...> connect port_name call
The pactor modem is slightly different than the conventional packet modem. The detail for this mode is contained in ConnectPactor by VE4KLM. Wwith packet modes, at times, the stations heard are on the fringe of reception and a digipeater will assist. To enlist the aid of a digi, use the command :
...> connect port_name call via digi_call
Multiple digipeaters may be listed, but beware of the declining benefit as the list becomes longer.
Connect to a network station via NET/ROM
Laying beyond the range of the radios of the host are normally additional packet stations. Some of the remote stations may be contacted again using the “connect" command. The NET/ROM feature permits a networking of nodes and simplifies the connection process for the user. Remote stations are contacted by creating a chain of stations leading to the desired remote host. Many good references are available to fully describe the details of NET/ROM, for the purpose herein use the
...> node
command to determine the list of hosts presently in the network. Nodes are listed as “alias:call" in alpha order by alias. Establish a contact with the command:
...> connect alias
or
...> connect call
Connect to a network station via TCP/IP
In addition to AX.25 protocol, jnos supports TCP/IP protocol communications and may be a host in the AMPRNET amateur network. These hosts are registered and have been assigned an IP number in the class A network 44.0.0.0. Contact with these hosts is made with the “telnet" command and the path of communications may be a combination of RF and Internet links. The command
...> iheard
is the principle tool to find other active stations on the local site. Unlike NET/ROM the TCP/IP network does not announce its presense to the local site. The AMPR.ORG maintains a web presence at http://www.ampr.org/ with considerable discussion and tables of known nodes. To connect with another IP host use the command:
...> telnet IP
or when the DNS facility can resolve the IP number use the command:
...> telnet host.ampr.org
to make the link.
The CONVERS Bridge
The chat facility is named CONVERS. Enter the the chat mode with the command:
...> convers
and jnos will respond with
Conference at k8rra Type /H for help. Welcome message configured by the sysop.
The bottom line is blank, and whatever text is entered by the user is reproduced on all other converse participants who quality at the time an end-of-line <CR> is entered. In the single screen mode, the input may be interupted by text from other sites (a bit un-nerving).
The concept of CHANNEL is similar to "chat room" in that text is replicated for only those sites who share the same channel.
- This library is free software; you can redistribute it and/or modify it under the terms of the GNU Lesser General Public License as published by the Free Software Foundation; either version 2.1 of the License, or (at your option) any later version.
© 2005 Ian Laurenson, KlausHeinisch, Marc Santhoff
E-MAIL SERVICES
Email is referred to as time-displaced communication. This author presumes the user is familiar with internet mail handlers. Normal use of jnos is to log in under the users FCC call sign. The area logged into is seen as the users call sign, and mail from others is addressed to the users call sign. For the most part the FCC call sign is used to tie this activity together. All services are not available to all hosts, so the user must find the specifics for the site - often shown under "info" command of the BBS.
Reading mail posted by others
Upon login jnos announces the presence of new mail in the mailbox. The prompt string contains the message number considered to be the "current" message under consideration. Listing the mailbox contents is done using the various "List" commands thus giving the user an overview of messages, senders, and subjects. Reading mail is done with the "read" or "verbose" commands, and certain abbreviated commands such as "#" or number or even the simple "CR" or carriage return (enter) key. See the command reference for detail syntax. A message may be read as many times as desired. There is no facility to dispatch a message to a printer, however various tools exist on typical user terminals to permit capture and/or printing of text that allow mail to be printed when needed.
Once the message is displayed a status flag seen in the mailbox listing is changed from "N" or not-read to "Y" or yes-read. The message will remain in the mailbox list of mail until the "Kill" command is executed.
Posting mail to others
Sending mail to other users of the same node the user is logged into is done with the simple command of "send call" where the call is the users call sign. The "send" command has additional features to "reply" to messages, "forward" messages, and include additional recipients to messages called "courtesy copies". These syntax rules are well covered above.
One simple means of delivering mail to other sites is for the user to connect to the remote host of his recipients choice, perhaps using NET/ROM tools, followed by creating the mail on the recipients host.
Addressing messages takes a little more information to complete. By appending "@" to the call followed by host information can cause mail to be delivered from the host being used at the moment to the host of the recipients choice. When the remote site is also a registered ampr.net site, delivery is made by SMTP and is totally automatic and reasonably reliable. Under certain circumstances, the target host may be an Internet site or a service site such as the WinLink Mail service. To utilize WinLink, the sysop must make a manual transport as part of his routing duties. WinLink2kMail describes interfacing jnos to WinLink.
Forwarding mail to another BBS or host
When forwarding is configured for the jnos node, then mail posted locally will be passed on to another node. Forwarding function is typically an automatic scheduled task for jnos, and is configurable in two flavors - AX.25 and TCP/IP. To determine the configuration of the local node requires information from the administrator.
Hosts in AX.25 networks known as "full service hosts" typically support mail forwarding to and from other full service hosts. When AX.25 forwarding is configured, the administrator will support forwarding to selected remote hosts to create a cluster of users each able to post mail to his own host and allow forwarding to assist in delivery. In addition to host-to-host forwarding, this feature also provides for user name aliasing by implementing a "rewrite" function. One example of rewrite permits mail addressed to "A" to be redirected to "B". In fact "B" may be a list of recipients so group delivery is possible. Please note this feature is quite flexible but not robust since broken links in the forwarding configuration can hamper delivery to very remote hosts, it is best applied fairly locally and quite static.
Using TCP/IP network technology permits forwarding via SMTP to remote BBS hosts or to Internet mail servers. Once the destination host is determined in the forwarding process, SMTP uses established routing paths to deliver outgoing mail to remote sites.
Jnos may also be configured to support incoming mail delivery from POP mail servers. Remote servers may include other jnos sites with POP servers as well as Internet providers mail services.
FILE SERVICES
Jnos provides the "Upload" and "Download" commands to move blocks of ASCII data, and "What" to explore the directory structure where files reside. The transfer is to/from the users terminal screen. File-to-file moves may be acomplished by using a terminal (emulators?) that include a spooling feature. The transfer mechanism is restricted to ASCII text and does not incorporate any form of integrity check, thus the method is prone to some error. By using Binary-to/from-ASCII utility tools most forms of data can actually be moved, but be wary of transfer error. While this may seem burdensome, other tools are implemented in the TCP/IP components of jnos that simplify these tasks at the expense of requiring network connectivity at the users disposal.
GENERAL SERVICES
Most of the other serveces from BBS are to support the activity described above and have already been shown in some detail. The remaining services have general utility. [tbd]
SSID SERVICE ACCESS
We talk about SSID here in the context of configurations. While configuration is the subject of other parts of this site, the user is forced to interact with jnos and remote stations in a manner that is very much the consequence of configurations. Yet there is no standard way to configure therefore there is a steep learning curve before "understanding the neighborhood". That is the way it is with AX.25 networks.
The BBS may be bypassed and services may be provided by connecting via "J0NOS-#" directly. With this method of connection, the one service identified is available to the user giving the option of networking on a service basis. There is no standard of configuration for use of SSID numbers at this time. This section [tbd] uses one set adopted by MI-DRG for application at member sites.
J0NOS CONNECT Connection to a home station with a -0 or blank SSID
J0NOS-1 CONNECT Connection to the home host BBS -- typically a TNC based PBBS
J0NOS-2 CONNECT Connection to a gateway station BBS like the DRG network enabled BBS
J0NOS-3 CONNECT Connection to a full service BBS with AX.25 mail forwarding
J0NOS-4 CONNECT Connection to a network node supported by NET/ROM, TCP/IP, or other network
J0NOS-5 CONNECT Connection to a keyboarding/printer site
J0NOS-6 CONNECT Connection to the DRG converse bridge
J0NOS-7 CONNECT Connection to a crossband digipeater site
J0NOS-9 CONNECT Connection to a mobile or moddata site
J0NOS-10 CONNECT Connection to a WinLink site
There is reason to be careful in picking SSID assignments. While it is true that there is no standard involved in picking specific SSID numbers for services, there may be consequences to picking certain patterns of SSID numbers. It seems there is not a right/wrong solution, but a does/does-not consequence is present.
The issue is seen in the BBS connect process from remote stations. The fact is that jnos can not select an appropriate response under some conditions. That condition is when the BBS SSID is the same as a competing service SSID - not all services compete. When the BBS SSID is ambiguous, the BBS response will wait until further input resolves the ambiguity.
As a consequence of configuring the local station with a duplicate SSID, a typical situation at the remote station is that the connect command responds at the remote will be "a connection has been established". Then no more output is presented until perhaps a "carriage return" or "null input" is made, then the remainder of the BBS connection output will appear. The blank line is enough to resolve the ambiguity.
So the rules for selecting various SSIDs might well be:
- Select SSIDs that are significant to your own situation. Perhaps as simply as -0 is home station, -1 is the truck station. Perhaps it will be as simple as adhering to the pattern selected for a group of stations.
- To avoid the consequence of special input to the BBS, select a unique SSID for BBSCALL.
Simple enough? However you choose -- publish the choice perhaps selecting a broadcast message to convey the choice.
