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 server software for DOS. Versions of FBB packet radio BBS server 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 December 1999, 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 on a 286/12 box at home. Five years ago, when I got better box, Pentium I at 166 MHz with 32 MB of RAM and VGA color graphics, I switched to a Windows version of FBB ("WinFBB"). Author of the software, a 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 great 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 more 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
Xwindow 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 channel.
4. All three versions must be capable to
share the same configuration files, i.e.
to be able, for example, to begin a new
session from the exact position where the
other version has finished its own last
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). I mean of RPM packages. So, there
are no source (re)compilations here at the
moment, but in the future we will see :-)
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 & swap partitions. Well, at 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 the 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 automated BBS-to-BBS forwarding protection, using MD2 algorithm. One of the reasons to cover Protus in this document is the fact that its author haven't made a manual in English yet. I keep trying to translate original manuals from Spanish into English, but it is a hard work. 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 may
be translated because they are originated
in Spanish (those files are just the parts of
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 one 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 by the author to make a new directory
/var/ax25/fbb/protus and put *.PRT files there.
I didn't move files from \FBB\PROTUS
but rather copied them into the new location,
because I wanted Protus to continue working under WinFBB
as before. The utility still didn't want to run, unless I
also copied additional two *.PRT files from
\FBB\SYSTEM to the same new location
(/var/ax25/fbb/protus). After I did that, Protus
became 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 graphical
xfbbX client, that I have found not able to become
activated. 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). Uninstall? Why? You will
find out soon, read on ...
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. In addition, all
of these folks who are going to telnet
the BBS, have to be declared as users with
the 'M' flag (modem users). It is up to your
security precautions, if either of them would
eventually have 'root' capabilities
to that one Linux machine itself.
Notice: Maybe I have already explained that I
use Red Hat 6.2 at home. That's why I usually look
for .rpm packages that have been made for
that particular Linux distribution, but not only that. I have
also tried to use Red Hat 7.1 but it seemed not to support
an older Xwindow application, LinFBB 7.00g (04 August 1998).
When I noticed that issue, I returned back to Red Hat 6.2.
xfbb-7.04-2.i386.rpm (07 August 2001)
from
www.f6fbb.org/versions.html
/etc/fbb.conf), in order to avoid
editing the same "defaults" once again and again :-)
xfbbC/X server running ...
xfbbd ready and running ...
on my screen, TNC's PTT lamp confirmed that a beacon was really transmitted.
Connecting localhost ... Ok
Authentication in progress ... Ok
Monitoring channel 0 ...
there appeared no traffic on the screen. In order to really monitor the channel, I had to start another xterm and type:
telnet localhost 6300
Bingo! From the usual FBB's prompt I entered the gateway and typed the familiar "M" ("Monitor") command. 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 as long as that telnet session was closed. I was in doubt if that was OK or not, because there I expected to see the traffic from the radio 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. Instead of that it reported that command couldn't be found. Anyway, xfbbC v3.01 itself appeared to work nice. It is still possible to monitor the working channel too (using the "M" command from within the gateway), but this is not a valuable solution because while "Monitor ON", it is not confortable to do anything else within the gateway. Once again, solutions are 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 can show that new PID). So, there is a question why it returns that [OK] when it is obvious that daemon is not stopped, but rather re-started.
Checking, the FBB daemon
xfbbd dead but subsys locked
while "/A" command ("Stop BBS") returns:
Stop-request accepted, no connection.
before shutting down xfbbC client itself.
Further attempts to re-start either xfbbC client or xfbbd server (using /usr/sbin/fbb start) are not successful, unless an additional /usr/sbin/fbb stop is executed. The result is:
Shutting down xfbbd: [FAILED]
Now another /usr/sbin/fbb status reports:
Checking, the FBB daemon
xfbbd is stopped
so finally, daemon might be re-started again. Here it is also a mystery why it returns that [FAILED] when it is obvious that daemon is really stopped (maybe it is a "failure" when we try to stop the same thing twice).
There are some other commands: "/K" (Re-boot BBS with housekeeping), "/M" (Re-boot BBS immediatelly) and "/L" (Re-boot BBS, waiting users to disconnect) - all of them with slight different behavior. Anyway, those three commands have something in common: they all re-start the daemon (with different PIDs, of course).
2002-10-20
Well, soon after the installation of LinFBB v7.04 .rpm package, I noticed a new "kid on the block", i.e. a new item within the Start menu (under Gnome environment). That was a "HamRadio" group, having several "Xfbb version 7.04" sub-items and one of them was "xfbbd X Client".
It seemed that a mouse click on that "xfbbd X Client" icon was not likely to return any response, although xfbbd daemon has been successfully running before invoking the client. That's why I have been asking for help (related to that issue) from other LinFBB users, but it seemed there was no one capable to solve that problem. Anyway, it looks to me that there is a "dead" link from this "xfbbd X Client" icon to an existing executable.
Trying to find a solution, the other day I was browsing the /usr/sbin directory. I have noticed something that I have already seen for several times. That was xfbbX file. Well, I am sure that I tried to use this executable earlier, but without much success. This time, I have entered the full path, like this:
/usr/sbin/xfbbX
and, finally, the GUI client appeared on the screen.
So far - so good. Soon after, I realized that 'Monitoring' window was capable to monitor the actual traffic on the radio frequency, but not only that. Headers of all packets appear in green and the actual information is in blue, so it is easy to distinguish what is the header and what is the text info (comparing to my old X11 LinFBB application where everything came in black). What I could describe as a disadvantage of the 'Monitoring' window, is that the scroll bar does not give you much of the previous, already scrolled traffic.
The 'All channels' screen was even better, so the system user correspondents' traffic appeared in green, the local user's traffic was in black and the port information was in yellow. Unfortunately, there's no easy way (if any) to change colors (and that's the standard feature in WinFBB) for both 'Monitoring' and 'All channels' windows. Maybe I haven't managed yet to find a switch for that, so any useful info about is appreciated.
What I have also found a bit annoying, was that both windows mentioned above, appear not arranged side-by-side, a form that would be more suitable. Besides that, the third window, 'Console', has to be activated with another mouse click (instead of being activated automatically with the other two windows). Actually, the whole thing of xfbbX client seems to be primarily useful for sysops looking only for BBS's command line, in order to execute some server's commands etc. That's why I have found a bit strange why the console window must be activated separately (OK, I know that's the same with WinFBB's windows, but why not to add some additional feature?)
Anyway, the 'Console' connection window has almost the same functionality as WinFBB's 'Console' window. Here I think of the commands given at the BBS's command prompt, because they are invoked from the usual language *.TXT files.
But, the big disadvantage of today's version of xfbbX client, I've found here, is the absence of several useful icons, that I was very fond of within the WinFBB's user interface. For example, there are no icons for pending mail, users information, disconnect a user, edit a message text or a header etc. It looks to me that xfbbX developers are not likely to offer the full comfort that we have within WinFBB's GUI. It makes me wonder why? There are lots of commands that can not be easily activated without the proper icons. It drives me crazy whenever I have to re-boot to Windows to start WinFBB, in order to perform some simple tasks mentioned, using the mouse.
Besides that, there is no way to activate that nice message editor screen, very useful in WinFBB (also existed in an old Xwindow LinFBB application v7.00g from 1998!) The same goes for replying a message, where a sender does not get the text of a message to be replied to, within the new message body. In short, I don't like absence of all those earlier implemented, but now abandoned features.
Well, I can't imagine what Jean-Paul, F6FBB, and other developers would do in the future, but I am not satisfied with the idea to only keep further development of LinFBB server side, but, in the same time, to abandon the development of LinFBB's graphical client side. And not only that: It looks that MS Windows client for LinFBB server, xfbbW has been reported to be much more functional that described xfbbX, while, in the same time, WinFBB server development has been also stopped. A bit confusing situation, isn't it?
Some amateurs think that it is just a result of "global" IT situation: Linux (as well as other Unix-type platforms) is better suited for servers, but Windows is better for clients. If so, it looks that LinFBB packet-radio system operators, "sysop's", seem to be forced to run at least two computers, in order to get the same functionality they always had with WinFBB. I'd rather suggest to Jean-Paul, F6FBB, and other developers to transfer all known WinFBB's GUI features to xfbbX GUI environment, in order to avoid using two computers.
2002-10-30
A couple of paragraphs ago, I said that "xfbbd X Client" icon didn't work under Gnome environment. It did make me wonder if it would work under KDE graphical user interface. So, this time I started KDE (and I did it as "root" so, in addition, I also got a mailbox icon on the desktop, named "fbb X11". When I located the mouse pointer over that icon, there appeared some more description: "F6FBB bbs Server for Packet Radio").
Well, when I tried to click on that icon, I got a KFM Warning message box explaining that program /root/.xfbbX could not be executed. Fortunately, a "right click" on the icon allowed to enter file's Properties. The Execute card gave me a possibility to change the path for a program to be used. So, I did some browsing and located the new path: /usr/sbin/xfbbX. After that, another click resulted in running the GUI client.
Interestingly, there is some slight difference between xfbbX appearance under KDE and Gnome. Actually, each KDE's xfbbX window has "FBB" logo in the upper left corner (Gnome's windows haven't that). That may indicate that xfbbX client was produced primarily for KDE environment. Besides that, it seems that other features are almost the same, regardless being within KDE or Gnome environment.
On the other side, the already mentioned "xfbbd X Client" item (within the Start menu, under yhe "HamRadio" group), still does not work. I suppose that there should also be some modifications, related to program executable paths, but I do not know how to manage that. Anyway, it does not matter because xfbbX is running here this or that way.
2002-11-17
Notice: Well, folks, I couldn't try to install and use LinFBB client for Windows, because I have not had a second computer for that purpose. The only way to check how this client works, was to borrow a laptop machine and give it a try.
The first task was to link that Windows laptop to a Linux desktop. I had some difficulties with the network card on the desktop box, because it seemed not to be likely to start the appropriate eth0 interface. I'll give you some more details about the equipment here: Linux is Red Hat 6.2 and my ISA network card has UMC UM9008 chip. Long ago, I used some utilities that should "recognize" ISA cards (if I remember their names, that were isapnptools, pnpdump etc).
What I do know, is that such tools should have add some new lines into the existing files, like /etc/conf.modules or, to create some new files, like /etc/isapnp*. Well, I have forgotten what exactly should be done, so I went to look for the right tools. The one that was looking suitable was /sbin/isapnp. Although I got its response on the screen, telling that the UM9008 chip was recognized, there was nothing added to the system files, nor new files seemed to be created.
What I also tried to use, was the old good Linuxconf tool, that was already installed per default within RH 6.2 Linux. I found the right place to add the information related to NIC's IRQ and I/O address. There I seemed to make a little mistake, so I put the value of 220 (for the I/O address), instead of 0x220 that would better fit. The result was as one may expect: the interface eth0 continued to report that a ne module had not found a card at that one address. Then I checked the actual I/O address the card uses under Windows OS (was the same) and tried to fix the parameters (Thanks goes to a UK ham who advised me to have to let Linux know the proper IRQ and I/O addresses).
Interestingly, Linuxconf added a couple of new lines into /etc/conf.modules too. In short, the next time during the system boot, the interface eth0 reported a green [OK], so I could establish the link. So far - so good.
The next task was to download the client package from the FBB's main site. I did it from the "Newest version" web page and the number of the version was 1.12 (it seems that was not a pretty much new version, or maybe the content on that "newest" page has not been updated recently - another task for Jean-Paul?). Anyway, I installed it without any problem, configured its part related to the LinFBB server it was about to access, changed the console font to my favorite one (Tahoma) and started the utility.
At the first sight, the client looked great, because Linux clients still prefer so small letters, that are hard to read (compared to characters on a Windows screen). Now I tried the most used commands like List, Read, Send Reply etc. All of them worked great. What I have found a bit strange, was that the message justification did not work in its message editor window. You see, I like my messages to be justified on both sides. I hope a solution for that problem will be found soon.
Another issue with xfbbW client is that seems not to allow a multiple click onto more than one BBS callsign within pending forward list, comparing to WinFBB's behavior. You know, I am not very fond of opening the same pending forward window repeatedly again and again, in order to start (or to stop) more than one forwarding action.
In general, I like xfbbW client. I hope to install some newer version(s) soon, and I hope some of its features will be upgraded and some new ones will be added in the future. What I would also like to have, is to activate the maintenance of the BBS (a "housekeeping" task) from that client's menu. Another thing I miss at the moment, is the absence of the xfbbW's help system. I mean of a real Windows help, because there's not much use of a Help menu, having only Copyright and About information :-))
2003-01-01
Notice: Until recently, I preferred to download "factory-made" executables in RPM format (something like ZIP in MS Windows world). After getting a RPM package, a click on it activates the program that unpack and install its content. Well, it is great whenever your RPM has been "manufactured" for the very similar distribution of Linux you have. If not ...
xfbb-7.04-2.i386.rpm (07 August 2001), that was
running OK under RH 6.2 distro. And not only that. Its
"packager", Jose HI8GN, has explained that this package
was actually compiled and linked with utilities that came
with RH 6.2 - so under that distribution should be no
problems at all.
xd704h-src.tgz
archive.
--force and --nodeps options to avoid
several dependency obstacles. In sum, Lestiff has come
to its place on the disk.
2002-10-27
Notice: Folks, here I am going to discuss some rule'n'regulation issues that we, radio amateurs, every day face to. These problems make rather significant obstacles for this nice way of communication to be more developed and widely used.
First of all, anybody who might be interested in running Linux amateur radio software, as a way of using radio amateur stations on the international HF waves, in a digital manner, has to learn manual analog Morse telegraphy and pass the similar manual Morse skill test. For a long time now, I have been trying to explain myself, why manual Morse telegraphy is still being kept as the requirement without an amateur is not allowed to use HF radio frequencies under 30 MHz, in order to contact other Linux and remaining digital radio amateurs world-wide. I still have no answer, except that all of those who have wasted lots of time learning Morse, now don't want to allow newcomers to use the same capabilities - without the same (useless) tests!
You all know, there are so many Linux enthusiasts world-wide (including myself) who have been fighting against all types of monopols (like a company from Redmond, USA). The Morse obligatory test is the same: just another type of a monopoly!
That's why I have been trying to persuade all relevant authorities to remove such outdated regulatory principles, that make more and more obstacles for not only Linux users, but for other kinds of computer users - when it comes to the modern ICT technologies. I hope, all of you, readers of this mini-HOWTO, can now understand what does it mean to endlessly use outdated rules and regulations. For example, I often contact people from the academic world, students and scientists, in order to motivate them to join amateur radio wireless activities. They mostly refuse to start with amateur (also called "ham") radio, as soon as they hear they have to pass the Morse test, as the legal requirement before they become allowed to connect to remote computing radio users world-wide, using the HF radio bands and devices. I am sure, the absence of those high educated people in the ham radio is one of the most negative consequences in ICT areas we face to.
I have been thinking what to do, since early ninetees when I was the secretary of YU7 (Vojvodina province in Serbia) amateur radio union. It seemed to me that it was a very hard task to persuade the people who govern the amateur radio organizations, to remove such outdated rule. When I realized that the removing the mandatory manual Morse test is almost impossible to be expected in a short period of time, I decided to suggest the implementation of another regulatory principle: To adopt a new type of amateur radio licenses, a Ham Digital Licence (the HDL in short). The HDL licensees would be allowed to use ALL amateur radio frequencies, including ALL international HF bands under 30 MHz. But, they rather should be allowed to use ONLY digital types of amateur activities, including the use of computers with LinFBB packet radio software. The HDL holders might use some dedicated radio transmitters, without the capability for both voice microphone and Morse key connections, in order to avoid possible misuse of unwanted amateur activities (like voice SSB operations).
All HDL candidates would have to learn various topics like computer hardware and software in general (operating systems and system software configuration, amateur radio software setup etc), connecting amateur radio stations to the computers (connecting radio modems to the transmitters etc), building simple antennas (like 1/2 wave wire dipole for 20m I used long ago), English language (or German etc) in the written exam etc. The Morse requirement would not be used anymore, as well as some other obsolete tests, like highly complicated radio circuits or skills needed for building home-brew radios from the scratch (instead of buying modern factory manufactured devices) etc. Of course, regulatory issues should also be tested (like band plans - in particular recognizing the sub-bands dedicated for digital ham radio), RFI issues and how to avoid them etc.
I believe that amateur radio digital activities have their future only if we all do our best to improve the regulatory principles that govern this fine hobby. You should also know that, besides the telegraphy skill requirement for HF access, here in Serbia we have some further restrictions: we have all to be the members of the national amateur radio unions (SRV in YU7 province and SRS in Serbia in whole), as the legal requirement, before we become allowed to use any type of the amateur radio activities. Such a stupid rule does not exist elsewhere!
Should you want helping us to adopt internationally known principles, that do NOT require to join any type of an amateur radio organizational system, i.e. an amateur radio society (that only wants to get our membership money), you are invited to lobby for that. Our outdated amateur society leadership has their email address: yu0srj@eunet.yu (I suppose they may have more than one email address, but you may try to use this one). You may also use an Internet search engine and scan for more info related to "Savez radio amatera Jugoslavije", "Savez radio amatera Srbije", etc). Your valuable help would be highly appreciated. Case you need more info regarding these legal issues, do not hesitate to contact me too.
If you find yourself interested enough in making amateur radio rules and regulations better and updated (say to spread the idea of liberalize the ICT areas and make them free of any kind of monopols), I would suggest you to look for your national radio amateur society and/or national telecommunication regulatory agency (like FCC in the USA). Lobby to them in order to remove the obsolete manual Morse proficiency test. In addition, should you have some opportunities to attend to some ICT related science conferences or something like that, you are also invited to let me know of.
Case we all do our best to remove obstacles mentioned above and allow the new people who may wish to enjoy the amateur radio digital and Linux-related operations to do so, the technology would become the part of more homes. I hope you, the readers, may help. So I look forward to hear from you soon!
2003-06-01
Notice: Folks, I often visit some (inter)national ICT conferences all around Serbia and Montenegro, submitting papers and having presentations. What I want to do is to spread - as wide as possible - the basic idea and the useful mission of the amateur radio hobby. You bet, whenever possible I want my readers to make it with Linux. Besides that, I have been writing various articles for a variety of scientific and other magazines. Here you have a list of the articles I have written, and the papers submitted to the conferences until now.
Case you want to re-publish or forward my volunteer paper works to some journals or other public media around, you are free to contact me. Some of my papers are written in Serbian Cyrillic, some of them in English and some of them even combined!
- "U prilog I.A.C.", MI (the youth scientists' organization
newspaper), No. 69, 1990.
- "U prilog I.A.C. (2)", MI (the youth scientists' organization
newspaper), No. 70, 1990.
- "Vise od radio-amaterskog hobija", Vojska, No. 163, 1995.
- "Korak ka zvezdama", Vojska, No. 200, 1996.
- "Die Gefahr von Innen - Internet gegen Amateurfunk",
AMSAT-DL Journal, No. 4, Dez./Feb. 96/97.
- "Kakva nam organizacija (ne) treba?", Radioamater,
Feb. 1997.
- "Kakva nam organizacija (ne) treba? (2)", Radioamater,
Apr./May. 1997.
- "Sateliti umiru padajuci", Vojska, No. 235, 1997.
- "The Internet is not the Enemy", QST, Aug. 1998.
- "Novi radio-amateri za novi vek", Antena, June 2000.
- "Racunarske komunikacije putem radio-veza i
zastita pristupa", Bezbednost, No. 3, 2000.
- "Paket-radio - Racunarske komunikacije putem radio-veza",
proceedings, "Info-Teh", Vrnjacka Banja, Serbia, 2001.
- "Racunarske komunikacije putem radio-amaterskih veza",
proceedings, "YU-Info", Kopaonik, Serbia, 2002.
- "Computer Communications over radio", presentation,
"Linux FEST", Belgrade, Serbia, 2002.
- "Paket-radio - Radio-amaterske digitalne veze",
proceedings, "Kongres JISA", Herceg Novi, Montenegro, 2002.
- "Paket-radio (2) - Modemi za radio-veze",
proceedings, "Info-Teh", Vrnjacka Banja, Serbia, 2002.
- "Alternativne racunarske mreze", festival catalog,
"INFOFEST", Budva, Montenegro, 2002.
- "Alternative computer networks", proceedings, "TELFOR",
Belgrade, Serbia, 2002.
- "With rule and regulation improvements to the progress"
proceedings, "TELFOR", Belgrade, Serbia, 2002.
- "Paket-radio (3) - Programske mogucnosti na strani servera",
proceedings, "Info-Teh", Vrnjacka Banja, Serbia, 2003.
- "Paket-radio (4) - Legal rules and regulations in the amateur
computer networks", proceedings, "Info-Teh", Vrnjacka Banja,
Serbia, 2003.
Copyright (c) 2003 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 also look for AX.25 (mini-)HOWTO at the same location where you get this 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 or this one: Linux Documentation Project.
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,
and a variety of helpful radio amateurs world-wide.
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 etc.
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, or this one: Linux Documentation Project, 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.