m.skoric@eunet.yu
I have been using FBB amateur radio software since early nineties. It was the time of DOS operating system, so most of us, system administrators (or, so called system operators - sysop's), used various packet radio software for DOS. Versions of FBB packet radio BBS software for DOS, today are known as "DosFBB".
I still administer one DosFBB database in the SRV (Amateur Radio Union of Vojvodina, a part of SRJ). It is DosFBB v7.00g23 that runs on a 486DX computer with 16 MB of RAM and Hercules b/w graphics. Since last December, it runs without any re-boot (excepting some power failures). Before that, it was a bit tricky to set up all memory management properly, in order to avoid "frozen" system. Although this server runs under DOS, its "radio clients" don't depend on that. In fact, users of that DosFBB might run their client software under DOS, Windows, Linux or any other operating system that offer amateur packet radio abilities.
I have also used DosFBB v5.15c at home. Three years ago, when I got my new box, Pentium 166 with 32 MB of RAM and VGA color graphics, I switched to a Windows version of FBB ("WinFBB"). Author of the software, an radio amateur from France, Jean-Paul F6FBB, has made many versions of WinFBB, including 16 bit variant for Windows 3.x and Windows 9x as well as 32 bit variant for Windows NT. I have run both variants until now (at the moment it is 16 bit WinFBB v7.00g25 that runs ok under Windows NT 4.0).
New: Since Spring 2001, I run WinFBB v7.00i (17 March 2001) under Windows 2000 Professional.
The main difference between DosFBB and WinFBB is that the second one offers you to do other jobs with your computer, while FBB is running as just any other application. Beside that, it is always nice to copy a text from another application (for example, from an Internet email) and to paste it into a packet radio message, or vice versa.
In the mean time, I upgraded my system to the Celeron 400 MHz with 96 MB of RAM and a big hard disk that has enough room to install Linux and try LinFBB ...
New: In July 2001, I added 128 MB of RAM so my home system is very confortable now.
Finally, you should be aware what I want to have here:
1. WinFBB when I run Windows.
2. LinFBB when I run Linux. It should be an
Xwindows application that may be
started/stopped similarly to WinFBB.
That's why X11 LinFBB package is used.
3. LinFBB when I run Linux, but as a daemon
that runs in the background. In addition,
an interface for a local user (myself)
is needed, as well as an interface to
monitor the radio chanell.
4. All three versions must be capable to
use the same configuration files, i.e.
to be able, for example, to begin from
the exact position where the other
version finished its previous session.
5. I am not an expert in Linux, so I am
only able to install "factory-made"
packages for Linux (just like to install
self executing software packages under
Windows). So, no (re)compilations here :-)
x700e_full.tgz
xd700g_full.tgz
x700f01.tgz
x700g.tgz
x700g.tgz
I started to run X11 LinFBB 7.00g (04 August 1998).
Btw, X11 versions are not maintained anymore, but
I still run it here. It has some bugs but I like it.
Notice: Folks, you see, at my place, I have a dual-boot system, consisting of Windows NT and Linux (each of them having their own partition(s) and file system). I wanted to have 'independent' operating systems that won't see each other. So I made two NT's partitions as NTFS partitions and rest of the space used Linux as ext2 partitions. Well, first I have installed WinFBB under NT and X11 LinFBB under Linux. Both of them worked, but there was a big "problem": I could not share their system files. You might say: So, what a big deal. But, my FBB's should serve as packet-radio forwarding stations (regardless of which one I boot at the moment), so it was really needed for new LinFBB to "know", for example, the position where WinFBB has stopped the mail exchange last time (and vice versa, of course).
init.srv -> init_w.srv
forward.sys -> forw_w.sys
port.sys -> port_w.sys
protect.sys -> prot_w.sys
FBB is able to recognize and accept those renamed files.
amsat forward_to_file routine
(located in /mnt/win/fbb/system/fwd directory),
because that file was composed like this (for example):
A AMSAT
*
P @
*
C D:\FBB\SYSTEM\SAT\AMSAT.TXT <-- looks familiar to DOS/Windows only
*
G AMSAT
*
--------
On the other side, LinFBB's amsat.sys (located
in /etc/ax25/fbb/fwd directory) has suggested
something like this:
A AMSAT
*
P @
*
C /var/ax25/fbb/sat/amsat.txt <-- looks familiar to Linux only
*
G AMSAT
*
--------
Well, then I copied LinFBB's amsat.sys
into /mnt/win/fbb/system/fwd directory so
it could become functional. As a result, I got
two amsat.txt files, one of them
for each of WinFBB/LinFBB, and of course, both files
appeared on different locations: the first one was
/mnt/win/fbb/system/sat/amsat.txt and it
was filled by WinFBB; the other one was in
/var/ax25/fbb/sat/amsat.txt and was filled by
LinFBB. I didn't like it that way.
In order to have only one result,
regardless of FBB version, the newly copied
amsat.sys had to be slightly changed:
A AMSAT
*
P @
*
*C /var/ax25/fbb/sat/amsat.txt
C /mnt/win/fbb/system/sat/amsat.txt
*
G AMSAT
*
--------
As you can see now, when LinFBB is active, its
amsat.sys will not forward into
its "native" location of amsat.txt.
Instead of that, it will go to the location
of the WinFBB's amsat.txt and just
add some new materials into it, ok?
Well, now it's up to you to decide what to do
with your growing amsat.txt. An old
DosFBB manual says that the 'batch' file
(I suppose, the old good APPEL.BAT)
should be adopted in order for SATUPDAT.EXE
can update sat tracking data and, after
that, to erase AMSAT.TXT because it is not
needed anymore. Well, I haven't found a way to
manage that in both WinFBB and LinFBB. Actually,
whenever I perform housekeeping from either of them,
it seems that AMSAT.TXT remains intact. Happily,
it doesn't grow too much, so it's not a big problem.
Any suggestion here?
Notice: Well, I have been using Protus connection filters for a long time now. At first, it was version 3.1/1.2 for DosFBB515c and, later, version 3.3 for Dos/WinFBB700. I have found Protus as very useful utility because of its implementation of BBS-to-BBS forwarding protection using MD2 algorythm. One of the reasons I am going to cover Protus in this document is a fact that its author haven't made a manual in english yet. I keep trying to translate the original manuals from spanish into english, but it is a hard process. Any good 'spanish-to-english' translator is welcomed to contact me: m.skoric@eunet.yu.
Protus offers several interesting features:
Well, let's see what should be done in order to implement secure access to the FBB packet radio BBS, using Protus type of, so called, c_filter:
CONFIG.PRT and USERS.PRT
that should be carefully adopted to any
particular situation. Other *.PRT files will
work as they are in original, but they might
be translated because they are originated
in spanish (those files are just textual
information that are sent to users who
connect to the BBS). For your information,
I usualy don't care much about, because my
BBS's are so called "open systems". It means
they work quite normal for all users in the
same way as they worked before implementing Protus.
Only a couple of callsigns have password
installed and, when connecting, they know
what they are doing, so, they don't need
any additional info. Your mileage may vary.
Linux+WinNT
mini-HOWTO and Lilo mini-HOWTO). That means
all Protus stuff has already been installed in
a way WinFBB has required, except Linux
executable of c_filter file. I
put that file into /fbb/bin directory and,
after the next restart of LinFBB, I got the
info mentioned above: {PROTUS-4.0}. But the
password protection was not likely to work.
I was told to make a new directory /var/ax25/fbb/protus
and put *.prt files there. I didn't move *.PRT
files from \FBB\PROTUS but copied them into
the new location, because I wanted Protus to
run further under WinFBB as before. The utility
still didn't want to run, unless I copied
also *.PRT files from \FBB\SYSTEM to the
new location (/var/ax25/fbb/protus). After I
did that, Protus became fully functional.
Notice: You see, folks, that I keep trying to get as many as possible versions of this great software (Jean-Paul, F6FBB, must be very proud after reading these words now). What I think when mention "as many as possible versions" means that we have learned how to get both WinFBB and X11 LinFBB on the same computer. But, that's not all. There is a variety of daemon versions of LinFBB. In this section we are going to discuss how to *add* a daemon LinFBB to the existing two: X11 LinFBB and WinFBB!
libax25.rpm
ax25apps.rpm
ax25tool.rpm
fbbsrv.rpm
package. The archive was composed to make its
own directories, as "base" directories. The last new
version to start with, that I have managed to find as
a .rpm package, was 7.01f Release 4 (09. December
1999).
dirmes.sys
etat.sys
heard.bin
inf.sys
statis.dat
tpstat.sys
xfbbC/X server running ...
xfbbd ready and running ...
Notice: Well, the main trouble I have discovered with 7.01f daemon was the absence of Protus c_filter protection. As I told you before, Protus is a "third-party" product, so it might have some problems with the compatibility to LinFBB itself. Anyway, it is also possible that a daemon version of LinFBB has some special requirements over some "third-party" software.
.rpm package (18 September 2000). I got it
from his site:
http://hi8gn.dynip.com/indice.html. But, when I tried
to install it over the previous version 7.01f, it
complained about some existing LinFBB files.
.rpmsave extensions. It was nice,
so I could use them later to update my new-installed
config files.
xfbbd and xfbbC executables from 7.02g
package (I have made it with adding extensions like
.702 to the files). After that, I *uninstalled* the rest
of that 7.02 .rpm, in order to install the previous
version of LinFBB once again - the version that I was
satisfied with.
7plus
operations). Next, its xfbbC console client looks better
than the previous version. But, I still miss
xfbbX client, that I have found not functional.
I hope it will be fixed soon. Finally, Protus
c_filter utility is active too.
xfbbd.sh with the new one, because during the
first tests with the new 7.02 I was getting lots of error messages.
Looks that the directory structure was a bit complicated for me
to set properly within the new version of xfbbd.sh.
After I returned to xfbbd.sh from 7.01 package, the
BBS finally started to be run, though without some functions
like over-night maintaining (that one problem I solve in a way
to boot the BBS as WinFBB under Windows NT where that task is ok).
In addition, there are still some mysterious messages telling
that m_filter has not been found or something like that.
The next tasks are to solve these issues.
Notice: As I have said in the previous section, I haven't found an easy way to upgrade FBB's (its main executables), without temporary uninstalling an older version, then to install the new version - in order to get new executables. After that is done, a reverse procedure must be put in place.
.rpm package from
www.f6fbb.org/versions.html,
that was suggested by Jean-Paul, F6FBB. Anyway,
soon after there appeared several mirror sites,
offering 7.03 too.
.rpm over the existing LinFBB you will get
some error messages complaining that you already have
FBB installed on the computer). Anyway, after
the uninstallation, there you will find some config
files as .rpmsave files, so you could use
them later again.
.703 (for example).
.703 files won't
be unistalled automatically).
xfbb.sh (in my case, that is 7.01f).
.703) to get
their new extensions (in my case, that is .701).
.703 files
should *lose* their previously attached extensions,
in order to become usable.
xfbbC/X server running ...
xfbbd ready and running ...
telnet localhost 6300
passwd.sys file. And, all of
those who are going to telnet into
the BBS have to be declared as users with
a 'M' flag (modem users). It is up to your
security precautions, if either of them will
have 'root' abilities to the Linux box.
Notice: Maybe I have already told you that I
use Red Hat 6.2 at home. That's why I usualy look
for .rpm packages that have been made for
that Linux distribution. And not only that. I have
also tried Red Hat 7.1 but it seemed not to support
Xwindows LinFBB 7.00g (04 August 1998). When I saw
that, I switched back to Red Hat 6.2.
xfbb-7.04-2.i386.rpm (07 August 2001)
have been downloaded from
www.f6fbb.org/versions.html
/etc/fbb.conf), in order not
to edit usual "defaults" again and again :-)
xfbbC/X server running ...
xfbbd ready and running ...
on the screen, TNC's PTT lamp showed that a beacon was transmitted.
Connecting localhost ... Ok
Authentication in progress ... Ok
Monitoring channel 0 ...
there wasn't any traffic on the screen. In order to really monitor the channel, I had to start another xterm and type:
telnet localhost 6300
and from FBB's prompt enter the gateway, type the "M" command you are familiar with etc. But, interestingly, as soon as I telnet'ed to the BBS, /usr/sbin/monitor window, mentioned above, started to copy whatever was going on the telnet xterm (until that telnet session was closed). I wondered if that was ok or not because I expected to see the traffic passing thru the channel - regardless being connected to the system or not. Any suggestion here?
xfbbC -c -f -h localhost -i [callsign] -w [password]
with missing ./ (dot+slash) before xfbbC, so the script was not likely to be executed, but reported that a command couldn't be found. Anyway, xfbbC V3.01 itself seemed to work Ok. It *is* possible to monitor the channel from here too (using the "M" command under the gateway), but this is also a bad solution because while "Monitor ON", it is not confortable to do anything else. Solutions welcomed!
Shutting down xfbbd: [OK]
but /usr/sbin/fbb status reports:
Checking, the FBB daemon
xfbbd (pid) is running...
Looks that /usr/sbin/fbb stop does not terminate daemon *every* time the command is executed, but re-start it (the only difference is the new PID of the process and ps ax also shows this new PID). So, there is a question why it returns that [OK] when it is obvious that daemon is not stopped, but re-started.
Checking, the FBB daemon
xfbbd dead but subsys locked
while "/A" command (Stop BBS) does the same but returns:
Stop-request accepted, no connection.
before shutting down xfbbC itself.
Further tries to re-start either xfbbC or fbbd (using /usr/sbin/fbb start) are not successful, unless /usr/sbin/fbb stop is executed in addition:
Shutting down xfbbd: [FAILED]
Then /usr/sbin/fbb status reports:
Checking, the FBB daemon
xfbbd is stopped
so, daemon might be re-started again. Here it is also mysterious why it returns that [FAILED] when it is obvious that daemon is really stopped.
There are some other commands: "/K" (Reboot BBS with housekeeping), "/M" (Reboot BBS imediatelly) and "/L" (Reboot BBS, waiting users to disconnect) - all of them with slightly different behaviour. Anyway, those three have something in common: they re-start daemon (with different PIDs, of course).
Copyright (c) 2001 by Miroslav "Misko" Skoric, YT7MPB.
Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.1 or any later version published by the Free Software Foundation; with no Invariant Sections, with no Front-Cover Texts, and with no Back-Cover Texts. A copy of the license is available from http://www.fsf.org/licenses/fdl.html.
Use the information in this document at your own risk. I disavow any potential liability of this document. Use of the concepts, examples, and/or other content of this document is entirely at your own risk.
All copyrights are owned by their owners, unless specifically noted otherwise. Use of a term in this document should not be regarded as affecting the validity of any trademark or service mark.
Naming of particular products or brands should not be seen as endorsements.
You are strongly recommended to take a backup of your system before major installation and backups at regular intervals.
This is not the first release of this mini-HOWTO. I hope to improve it whenever possible. Beside that, there are other documents that may help you to use amateur radio stuff on your computer. You may look for AX.25 (mini-)HOWTO at the same location where you get FBB mini-HOWTO.
This mini-HOWTO would be improved from time to time. If you think that the HOWTO on your Linux installation CD is some out-of-date, you may check for newest release on the Internet. It could be found within the main Linux Documentation Project homepage.
This version of mini-HOWTO can thanks to:
Jean-Paul Roubelat, F6FBB, the author of FBB.
Per Olsen, LA6CU, the author of FBB documentation.
Jesus R., EB5AGF, the author of Protus.
Jose Marte, HI8GN, the packager of 7.02g package.
Any comments or suggestions can be mailed to my email address: m.skoric@eunet.yu.
These are intended as the primary starting points to
get the background information as well as show you how to solve
a specific problem.
Some relevant HOWTOs are Bootdisk, Installation, SCSI and UMSDOS.
The main site for these is the
LDP archive
at Metalab (formerly known as Sunsite).
These are the smaller free text relatives to the HOWTOs.
Some relevant mini-HOWTOs are
Backup-With-MSDOS, Diskless, LILO, Large Disk,
Linux+DOS+Win95+OS2, Linux+OS2+DOS, Linux+Win95,
Linux+WindowsNT, Linux+NT-Loader, NFS-Root,
Win95+Win+Linux, ZIP Drive, FBB packet-radio BBS.
You can find these at the same place as the HOWTOs, usually in a sub directory
called mini. Note that these are scheduled to be converted into SGML and
become proper HOWTOs in the near future.
In most distributions of Linux there is a document directory installed, have a look in the /usr/doc directory. where most packages store their main documentation and README files etc. Also you will here find the HOWTO archive ( /usr/doc/HOWTO) of ready formatted HOWTOs and also the mini-HOWTO archive ( /usr/doc/HOWTO/mini) of plain text documents.
Many of the configuration files mentioned earlier can be found in the
/etc
directory. In particular you will want to work with the
/etc/fstab
file that sets up the mounting of partitions
and possibly also
/etc/mdtab
file that is used for the md system to set up RAID.
The kernel source in /usr/src/linux is, of course, the ultimate documentation. In other words, use the source, Luke. It should also be pointed out that the kernel comes not only with source code which is even commented (well, partially at least) but also an informative documentation directory. If you are about to ask any questions about the kernel you should read this first, it will save you and many others a lot of time and possibly embarrassment.
Also have a look in your system log file (
/var/log/messages)
to see what is going on and in particular how the booting went if
too much scrolled off your screen. Using tail -f /var/log/messages
in a separate window or screen will give you a continuous update of what is
going on in your system.
You can also take advantage of the
/proc
file system that is a window into the inner workings of your system.
Use cat rather than more to view the files as they are
reported as being zero length. Reports are that less works well here.
There is a huge number of informative web pages out there and by their very nature they change quickly so don't be too surprised if these links become quickly outdated.
A good starting point is of course the Linux Documentation Project home page, an information central for documentation, project pages and much, much more.
Please let me know if you have any other leads that can be of interest.
In the end you might find yourself unable to solve your problems and need help from someone else. The most efficient way is either to ask someone local or in your nearest Linux user group, search the web for the nearest one.
Another possibility is to ask on Usenet News in one of the many, many newsgroups available. The problem is that these have such a high volume and noise (called low signal-to-noise ratio) that your question can easily fall through unanswered.
No matter where you ask it is important to ask well or you will not be taken seriously. Saying just my disk does not work is not going to help you and instead the noise level is increased even further and if you are lucky someone will ask you to clarify.
Instead describe your problems in some detail that will enable people to help you. The problem could lie somewhere you did not expect. Therefore you are advised to list up the following information on your system:
Remember that booting text is logged to /var/log/messages which can
answer most of the questions above. Obviously if the drives fail you might not
be able to get the log saved to disk but you can at least scroll back up the
screen using the SHIFT and PAGE UP keys. It may also be useful to
include part of this in your request for help but do not go overboard, keep
it brief as a complete log file dumped to Usenet News is more than a
little annoying.