by Andy Nemec, KB9ALN
Hello, all. I hope you had a pleasant Thanksgiving and are looking forward to a happy holiday season. On behalf of all of the board members of WAPR, Happy Holidays. And to those of you who have supported WAPR in the past and present, a special year-end thank-you is in order. Your help is appreciated!
With the approach of the holidays, a lot of us find ourselves reflecting on the past and looking toward the future. This year is, of course, special. We are fast entering a new millennium, which causes us to look back and forward with special interest.
After all, it wasn't until this century that the technology that we use in our hobby came into being. Our particular niche in this hobby did not even come into widespread use until the 1980s. When we look at the march of history, 20 years is but a couple of footsteps. In our lives, it is significant, of course, and so it is in this hobby and our part of it.
We at WAPR have been looking forward, too. There still is a serious need for a complete Wisconsin packet radio network, and WAPR recognizes this. As we go into the next century, WAPR is committed to doing whatever it can with it's limited resources to see this complete network a reality.
Toward that end, WAPR has been an active participant in the construction of the Ogdensburg node stack in Waupaca County. I am pleased to let you know that the folks in Waupaca county have been hard at work and have a node stack to show for it, and it is on the air!
The backbone node. #446OG:N9WBR-4 and the LAN node. WIWAUP.N9WBR-2 have been activated and are ready for service since the middle of November. A check from the Fox Valley node stack operated by Al, KB9BYQ shows a good link to this node. There is a weak link to #RUD4: W9DQA-5, but this should be taken care of in short order. So far, it has been usable for mail forwarding, as well as node-hopping most of the time.
This opens up a path to our friends in Waupaca that has not been in existence for almost 10 years. Not only does Waupaca have a node stack now, but Aaron, KB9QWC has his BBS in operation as well. So it appears that the efforts of Al N0GMJ, Joel N9BQM, Jeff N9WBR, Al KB9BYQ, Aaron KB9QWC and the rest of the Waupaca gang have paid off well. Congratulations on a job well done!
In other news, the Sheboygan BBS and node stack is operation and seems to be a stable path from north to south. Josh, KG9BO has this set up and is in the process of configuring things for optimal performance. So far his BBS is operational and he welcomes your connect. Look for WISHE.KG9BO-4 on the "nodes" list of your local LAN node.
Last month I also reported on the loss of the Green Lake node suck. Right afterward, Jack KB9WC dropped me an E-Mail message and informed me that like Mark Twain, the rumors of the demise were premature. He's the president of the Green Fox Amateur Radio Club and he tells me that the node stack was discussed at a recent club meeting.
The club decided to retain the node equipment and reserve tower space for it at their voice repeater site. All of this as a service to the Amateur Community. Which is indeed commendable, considering that none of their club members is involved with packet anymore. Recently, the repeater tower was struck by lightning, which apparently affected the node stack. While the repeater is back up using temporary equipment, the node stack is still in need of repair. Currently, WAPR is attempting to provide some assistance to get the node stack back on the air, if needed. Thanks to Jack for his note, and to the rest of the Green Fox Amateur Radio Club for their service to the ham community by providing the node stack.
I also received an inquiry regarding the start and ending of memberships.
This comes in the wake of our recent treasurer changeover and the catch-up work that was needed to bring everything up to date. The question involved when a membership started, and when it ends, and how long the accompanying subscription to the Badger State Smoke Signals runs.
Membership and subscriptions may expire at two differing times. WAPR membership runs from July through June of the following year. When you send a check tit as your membership dues and wish to subscribe to the Badger State Smoke Signals, it is assumed you are joining for the current membership year. If you join in September of 1999, your membership expires with all other memberships al the end of June, 2000. Your Badger State Smoke Signals subscription runs for 12 issues. If you got your first issue in October of 1999, your last issue will come in September of2000.
Of course if you already had a subscription to Badger State Smoke Signals that was due to expire soon (but had not yet), your WAPR subscription to the BSSS would take over when your current subscription expires.
There may be special circumstances regarding the timing of your membership as it relates to when you mailed your check, and when it was cashed. The WAPR board is more than happy to answer any questions, and resolve any membership issues. If you have a question about your membership, please do contact myself, Al N0GMJ, or Joel N9BQM. We'll be sure and try to answer your queries as soon as possible.
Hope this clears up some confusion. In an effort to avoid confusion, I recommend you read the short article concerning the procedure for sending packet mail to the Wisconsin Division of Emergency Management elsewhere on this page. This is important if you plan to operate in the coming Y2K emergency operations that so many hams are preparing to engage in at year's end. There is a process and a few pointers you should know about this. If you operate a BBS, please pay special attention so that messages can be effectively routed to the D.E.M. ham shack BBS.
And that is all for this month. Until next time, 73 from Andy
Linux and Packet Radio - Part 3 by Andy Nemec, KB9ALN
In part two of our series, we took a look at how Linux looks and operates, and took in some general operating system concepts. This time out, we will specifically discuss Amateur Radio and Linux, with some basic configuration concepts.
Kernel-Based AX.25 Operation
In part two, it was mentioned that AX.2S packet radio services can either be kernel-based, or application based. In the first method, the operating system itself manages the basic levels of AX.25 communication - listening for connections, sending out connection requests, and talking to the TNC. In the application- based system, a 1 separate program is run by Linux that handles both basic AX.25 communication, as well as the actual AX.25 application programs. AX.25 applications include a BBS or a simple packet mailbox, a communications terminal or "host" program, or an APRS program.
The kernel is the actual operating system - it talks to your computer hardware and peripherals, and listens to it. (t manages the processing of data inside your computer on the most basic level. It is the link between your command interpreter (like the MS-DOS COMMAND.COM) and the computer's subsystem. MS-DOS has a kernel, as do other operating systems. The Linux kernel can be custom manipulated to make it do specifically what you want it to do. You can make a small, lean system with basic capabilities, or make a larger, powerful server with Linux.
In the case of Linux kernel-based operation, one has to go through a process called "kernel configuration and • compiling" to be certain that AX.25 communication is supported. Most Linux distributions that are sold do not activate the AX.25 system by default - you have to set the kernel up to use the capability. The actual process of making a kernel is too involved to recount here, there are help documents widely available that will guide a user through this. It is not terribly difficult, but does require some attention to detail and reading.
In any event, you must use the proper version of AX. 25 support for your kernel.
What Kernel do I have?
That depends on your version of Linux, how old it is, and who packaged it. Note that this does not mean the seller's version number (like "Red Hat 5;2"), but the software version number of the kernel. If you have a computer set up with Linux, the command: uname -a will tell you this. If you have not installed it yet, and are looking at a particular version, then you will have to determine the kernel version based upon what the vendor tells you. Generally speaking, a kernel version of 2.0.42 or lower is sate to use with AX.25 kernel-integrated support. This includes Red Hat version 5.2 and lower. Red Hat 6.0 does not work too well for this purpose as of this writing, but will be corrected at some time soon. Other distributions may differ, so check carefully before you buy.
AX.25 packages
As was mentioned before, the kernel AX.25 support has to be enabled through the process of kernel configuration and compilation. Once this has been done, you may now select a package of AX.25 applications.
This is all based again, on your kernel version. Each package of basic AX.25 application programs is numbered similarly to kernel versions. For example, kernel version 2.0.36 will require versions of AX.25 program packages that are numbered 2.0.36 to 2.0.42. In short, the AX.25 program package version number means that it will work with that kernel version or one of a lower number. However, it is best to stick with the same version number as that of your kernel.
Once you know the version number, the most convenient form to install it is in the Red Hat Package Manager format, called RPM. This is a big file that is very similar to a self-extracting PK- ZIP file, with an automated basic installation process. Another method involves extracting a large file and compiling all of the necessary programs. Unless you are a very experienced Linux or Unix user, this will be tough and time-consuming. Try and stick with the RPM. If you don't have it, get it, it is very useful.
Configuring AX.2S kernel-based programs
There is plenty to configure in your new packet system after you have successfully installed the AX.25 package. You have a number of files that configure your keyboard console, your personal mailbox, a Net/Rom node (not recommended unless you are operating a node) and perhaps a BBS or APRS setup. There are several files that you will need to edit in order to successfully operate, and they are contained in the /etc/ax25 directory of the machine. While they are very similar from version to version, the configuration parameters are slightly different. For that reason, there are a few README and informational files to help guide you in the process.
Application-Based AX.25
This method does not require the kernel configuration and compilation process, and is less version-dependent than kernel-based AX.25 support. In this situation, the AX.25 support and actual application programs (like the terminal, mailbox, APRS and BBS) reside in the same program that is run by Linux. It is more comparable to a stand-alone packet program that is used in DOS or Windows.
An example of this would be the BBS program JNOS. JNOS is very powerful, and includes all of the usual features of a BBS, and more. While some operators find it to be "overkill" for them, it can be scaled-back to provide a smaller system that is better suited to what most people do on packet radio.
There can be more configuration to JNOS than with kernel-based programs - not any harder or easier, just more. That is because you are configuring both an AX.25 support system and a rather fancy application. There is, like any software, plenty to read about when you are configuring JNOS, but there is also a large user-base that is helpful if problems are encountered.
Advantages and Disadvantages of Each System
The advantages of kernel-based AX.25 support are a little speed gain, less configuration, and performance improvements that come with kernel upgrades.
Disadvantages are security and capabilities. Security is an issue because anyone who connects has the use of the operating system and whatever programs you may give them permissions to use. Clever people can use this to mess with your computer if you are not totally vigilant. This is not too likely to happen to you in a packet radio setting, but it may be something to consider if you have had problems like this in the past.
Advantages to the application-based support are one central program doing all of the work, more BBS capabilities, and the ability to minimize security problems. Having one program doing all of the work is not important as it sounds until you have to configure it. While JNOS uses more configuration options than most kernel-based support applications, the files are grouped on a common file tree that can also be segregated from the rest of the Linux system. In addition, it has it's own security setup.
Disadvantages include possibly having to wade through a lot of documentation about configuration just to conclude you don' t need a particular feature. Another is that if you wish to link it to the standard Linux networking support, the operation is a bit clumsy. This is because the application duplicates some of the services contained in the kernel (such as the handling of TCP/IP).
Conclusion:
What you wish to run on a Linux system can only be answered by you - What do you need, and what do you want to do in the future? Once armed with the proper information, you should get a much clearer idea of what you want. Here are some dandy sources of information for you. Note the mixture of upper-case and lower-case letters here, you must use the proper case.
For general ham radio program information, try: http://sunsite.unc.edu/mdw/HOWTO/HAM-HOWTO.html
For AX.25 installation instructions, try: http://sunsite.unc.edu/LDP/HOWTO/AX25-HOWTO.html
For information on configuring and compiling a kernel: http://sunsite.unc.edu/LDP/HOWTO/Kernel-HOWTO.html
For information concerning JNOS and how to get it: ftp://pc.usl.edu/pub/riam/jnos
This directory contains all kinds of information, JNOS itself, and the zipped document packages. I recommend getting the JNOS document package, as it has a vast deal of helpful information not only about JNOS, but TCP/IP in ham radio in general. There are also referrals to other pertinent information in there as well.
That's all we have for this part of Linux in Ham Radio. Next month, we will add one more concluding part to the series, as there is much more to tell. Until then, 73 from Andy, KB9ALN.
Back to the WAPR Home Page and Index