Setup for Thru-Modem Devices

Attaching for AX25 Utilities or JNOS

The Thru-Modem:
Ready to go on-line
A

ssuming you have all your hardware in place for the thru-modem , which would include an RS232 nine (or 25) pin cable, the modem itself, either a Baycom or "baycom-like" device, and a connector to the radio, we can now load and configure the supporting software which will set up the needed network interfaces/devices.

We have two options. We can set up the drivers for the AX25 Utilities, or we can set them up for JNOS, or any NOS system running on Linux. If you want to use JNOS as the application software for a baycom hardware device, you could obtain the complete AX25 Utilities package, although, you may not need to do this. At the very least, you need a copy of net2kiss and sethdlc, which are both usually included in an AX25 Utilities distribution. (You may be able to obtain these two pieces of code independently in a separate "baycom" distribution.)

Preliminary to either set up, JNOS or the AX25 package applications, the baycom device drivers must be loaded into the kernel, either at compile time, or by using the insmod command to load them as modules. I prefer to load them as modules. On the older software, the device names are bc[0-3] and on the newer versions they are bcsf[0-3]. At a minimum you will need these modules:

  • bsd_comp.o
  • hdlcdrv.o
  • baycom.o

NOTE: You may need more modules depending on what you want to do, your network requirements, and the software release. (And if you are using a newer release, the baycom module will probably be called baycom_ser_fdx.o, responsible for the bcsf[0-3] interfaces.) So everywhere it says bc0 below, substitute with bcsf0, etc...


Commentary : This article is a retraction of the first edition of this page! I made a foolish error! One that I should have suspected all along. I used software that was mis-matched and out-of-date! This pertains to the net2kiss code and JNOS. You want the latest rendition of this utility which is about 21K bytes, not the older one which is about 9K bytes (I couldn't find version numbers.) That is what is compatible with my JNOS 1.11f. I have now tested the newer version of net2kiss (21Kb) on JNOS and it works very well!



Loading the Modules and Configuring the Interfaces

If you don't have the bc devices already compiled into the kernel, then you may load them in the order shown using this general command syntax:

  • insmod [ -f ] <path>/<modules>

where path is /lib/modules/<ur_os_version>, for example:

  1. insmod [ -f ] <path>/bsd_comp.o
  2. insmod [ -f ] <path>/hdlcdrv.o
  3. insmod [ -f ] <path>/baycom.o

Your "ur_os_version" can be obtained from the command:

  • uname -r
An example command line from my system:
  • insmod -f /lib/modules/2.0.30/net/hdlcdrv.o
You should initially load these manually from the console to verify that each step has worked. Later on, you may build a script that will automate these installs. The "-f" indicates a force and will attempt a load whether the module version and the OS version match. It may "complain" that the module does not match, and it may not work correctly if at all, so the "-f" switch is only marginally useful and thus is optional.

After you have issued these commands, you should see their listing in the modules table. The command lsmod should display:

The Installed Modules Table 

Module:        #pages:  Used by:
baycom             2            1
hdlcdrv            2    [baycom]        4
bsd_comp           1            0
dummy              1            1
ne                 2            1
8390               2    [ne]    0
ppp                5    [bsd_comp]      0
slip               2            1
slhc               2    [ppp slip]      1
                      

This indicates that the modules are now "a part" of the kernel and are ready to be configured. Note that the baycom driver uses the hdlcdrv driver. Also, note the short length of this table which was excerpted from the bambi.ampr.org machine, a very "light" radio router.

As further confirmation, you should also see these devices appearing in the /proc/net directory in file dev. So before the insmod command, these network interfaces will not be listed in this table and after the module insertion, they will be listed. And one more point, if you had these interfaces compiled into the kernel, they would already be in the file dev.

The Listing of Interfaces Available in the Kernel (/proc/net/dev) 

Inter-|   Receive                  |  Transmit
 face |packets errs drop fifo frame|packets errs drop fifo colls carrier
    lo:     18    0    0    0    0       18    0    0    0     0    0
   nr0:      0    0    0    0    0        0    0    0    0     0    0
   nr1:      0    0    0    0    0        0    0    0    0     0    0
   nr2:      0    0    0    0    0        0    0    0    0     0    0
   nr3:      0    0    0    0    0        0    0    0    0     0    0
  eth0:   1392    0    0    0    0     1300    0    0    0     0    0
dummy0: No statistics available.
   sl0:    852    0    0    0    0      573    0    0    0     0    0
  bpq0:      0    0    0    0    0        0    0    0    0     0    0
   bc0:   1742    0    0    0    0      255    0    0    0     0    0
   bc1:      0    0    0    0    0        0    0    0    0     0    0
   bc2:      0    0    0    0    0        0    0    0    0     0    0
   bc3:      0    0    0    0    0        0    0    0    0     0    0

Notice the four (4) interfaces bc[0-3] now resident in this kernel table. The detail information is nearly the same as returned by the ifconfig command. This table can sometimes be useful when troubleshooting a device. (The newer versions will be listed as bcsf[0-3].)

OK, we now have "offical" network devices in place ready to be configured and activated. The configuration utility is called sethdlc and it performs the final required hook ups for the network interfaces bc[0-3]. It links the interface/device to a serial port, such as COM1, ttyS0, or cua0. So we need to pass in an argument that matches what we have on the COM's card, i.e., a hardware address and an irq number. We also need to specify what "mode" we are using since this driver "does it all." And we need to disable the existing uart on the port line we have chosen using setserial. Here are example commands:

  1. setserial /dev/ttyS0 uart none
  2. sethdlc -p -i bc0 mode ser12* io 0x3f8 irq 4
So, first we disable the existing COM's line with setserial. This essentailly takes it "off-line." Then we re-initialize this line using sethdlc to the new parameters that we want. The mode parameter is specified as ser12* which means use a serial device at 1200 baud with an open squelch, the "*".

If you were to do an ifconfig on bc0 at this point, you should see a new line added to the interface information display, the "Interrupt" and "Base address" line. This proves that the device is potentially tied to the COM's card.

Network Interface Parameters Table 

bc0       Link encap:AMPR AX.25  HWaddr KA1FSB-7
          inet addr:44.56.26.14  Bcast:44.56.26.255  Mask:255.255.255.0
          UP BROADCAST RUNNING PROMISC  MTU:256  Metric:1
          RX packets:692 errors:0 dropped:0 overruns:0
          TX packets:448 errors:0 dropped:0 overruns:0
          Interrupt:4 Base address:0x3f8

We now need to set some operational parameters for the radio. Again, we use the sethdlc utility featuring the "-a" switch:

  • sethdlc -i bc0 -a txd 250 txtail 20 slot 100 ppersist 63 half
This is where you can specify your customary values similiar to what you might use on a regular TNC. Be sure to specify "half" for half duplex. (It is capable of full, but it doesn't make sense given the nature of packet radio transmissions.)

OK, we are almost done! One final required step is to make sure the interface is up. By up, I mean activated, appearing on the "big" list as a result of the ifconfig command. You can do all the above steps, but if it isn't up, it won't work! Here is the last essential command, including the mtu parameter for packet size:

  • ifconfig bc0 mtu 256 up
Now, you have a fully configured network interface. It is ready to be used by either the AX25 Utilities or JNOS. However, you still may wish to further modify this interface by using the ifconfig command to optionally add an IP number, a netmask, or a broadcast address.
  • ifconfig bc0 44.xx.xx.xx netmask 255.255.255.0
  • ifconfig bc0 broadcast 44.xx.xx.255
You would fill in the "xx" values based on your network. And you might want to add routes to the routing table as well...

Looking back, recall that the interfaces may be named bcsf[0-3], depending on your software release. (And, there might be another name for a dedicated, half duplex interface group, bcsh[0-3].) You would need to substitute the correct name for the bc0 examples given above if they differ for your package.

Commentary : You may need to try several COM's lines before you find one that will work. Sometimes, the line will transmit and the called station will reply, but your software will not "hear" the response. (Until recently, I had this happen when I tried to get more than one thru-modem working at a time.)

On Mid-February 04, I attached and configured a second baycom device! (So, in theory, you should be able to attach all four devices!) My radio router is a 386, quite old and slow. Some of the comms cards are flea market specials and may date back to the late 70's! These "stubby" cards will not work with the baycom drivers. They probably are missing crucial control registers which the newer cards have on-board. When I switched over to an HDD card, which also had serial "slots," the problem was solved! The device transmits and receives just fine! If you are having difficulties, make sure you are using fairly recent comms cards. Linux is very forgiving of older equipment, but even Linux has its standards!

EXTRAS: If you are in a troubleshooting frame of mind, here are some handy commands that could help in diagnosing faults:

  1. setserial -bg /dev/cua*
  2. sethdlc -i bc0 -p
  3. sethdlc -i bc0 -a
The first shows the status of the ttyS*/cua* lines. The second shows the mode and COM's values for the port/device/interface, bc0. The third shows the communication parameters for the radio.

How To Setup for AX25

If you want to use your new interface as a port in the AX25 Utilities, you are 90% of the way to your objective. All you have to do is to make sure this port is defined in the axports file and configured in the ax25d.conf file. (For a more complete discussion, see the sections on the AX25 Utilities. )

Sample Data Values for Axports and Ax25d.conf Files

bc0 entry in the axports file: 
     bc0 KA1FSB-7 1200 256 1 145.070 Mhz "Wellesley, MA" 1200 bps Radio AFSK Modem
bc0 entry in the ax25d.conf file: 
     # FSB-BBS on bc0
     [KA1FSB-7 via bc0]
     NOCALL * * * * * * L
     default 1 10 3 300 10 5 -       root    /usr/sbin/node node %d %s

Then you either will have to re-start the ax25d daemon or give it the "-HUP" signal and it will re-read the ax25d.conf file and pick up your newly added port. Here is what the signal command looks like:

  • kill -HUP <pid_of_ax25d>
where the "pid_of_ax25d" is found by listing the process table using ps ax. And to log this activity, you will have to start the mheardd daemon again by a kill and a re-start; it can't be "hupped."

To verify that the port is active and "listening," use the netstat command with the "--ax25" switch:
  • netstat --ax25
You should see the port listed in this table as an active AX.25 socket.

The Active AX.25 Sockets Table 

Activate AX.25 sockets
Dest       Source     Device  State        Vr/Vs  Send-Q  Recv-Q
*          KA1FSB-7   bc0     LISTENING    00/00  1228    0

And you should be able to call out on this port as well:
  • call -r bc0 <callsign>
where "callsign" is a well known station that always comes back to your requests for a connection. (test, test, test... )

How To Setup for JNOS

Setting up the internal "links" for JNOS is not too troublesome, in fact, it is relatively straightforward. Recall, though, that at a bare minimum, you need to obtain the newest net2kiss code, or the kiss part of the AX25 Utilities, or the whole package. This code forms a "bridge" between the baycom driver and the JNOS application. (The code may be available along with the baycom drivers, separate from the AX25 package.)

As an interesting and peculiar aside, you may use both JNOS and the AX25 Utilities at the same time and with the same SSID, "sharing" the same hardware device, although I don't recommend this for normal use! They can both call out, but the result on receive is unpredictable! Sometimes, one or the other receives, and sometimes they both receive together. To solve this, you may kill the ax25d server if you don't need it, and still be able to call out using the AX25 package! Now all receives for the "shared" SSID go to JNOS. (Of course, if you are using different SSID's for the AX25 package than you are using in JNOS, there will be no problem.)

NOTE : By way of clarification, you do not need the AX25 Utilities package, nor do you need to configure the axports or ax25d.conf files, to use the baycom drivers for JNOS! All you need to use are net2kiss and sethdlc. The sethdlc "talks" to the hdlcdrv driver module which you installed earlier, and the net2kiss set ups a bridge or link between the driver and the JNOS application via a pseudo-tty.



Once you have an active and configured bc0 interface, you need to choose a pseudo-terminal , such as ptyqa. You may choose any one that you like. Make sure it is not in use anywhere on the system. A quick look at the PID table (ps ax) is a good place to begin. This will create the internal communication link between the network interface, bc0 and the JNOS application, i.e., JNOS's network interface, whatever you decide to call it. (I labelled mine bc0 as well.)

The "glue" that makes this work is a program named net2kiss. It links the system interface with JNOS's interface by means of a pseudo-terminal. Here is the command:

  • net2kiss -i bc0 /dev/ptyqa &
This program also encapsulates the data packets in a kiss format, hence, its name. (JNOS needs to see it coming across as kiss.) It then "un-kisses" the packet and extracts the original data.

On the JNOS side, you need to set up an attach statement to "grab" the other side of the "pipe." You also need to label the JNOS interface. Here are the sequence of commands that are run from your autoexec.nos:

Configuration Statements for Attaching the bc0 Device in the Autoexec.nos File 

attach asy ttyqa - ax25 bc0 1024 256 1200
asyconfig bc0 txq 5
asyconfig bc0 rxq 5
ifc bc0 description " VHF port on 145.070 BAY    MDM 1200 baud 
ifc bc0 broadcast 44.56.26.255
ifc bc0 netmask 0xffffff00
ifc bc0 ax25 bctext "JNOS/Linux 1.11f [44.56.26.17] 145.070, Wellesley, MA"

The pseudo-terminal ttyqa is the slave side of the "pipe" and hooks into the ptyqa side. As you can see, I have named my JNOS interface bc0. Once inside JNOS, you can label it anything you like. You may then go on to further configure this device in JNOS just as you would for any TNC.


Updated: 06-17-06     Restoring an Inactive Device
 
Sometimes on the older machines, the device will not "hook" into JNOS properly. It may transmit, but it won't receive. This can be a real inconvenience to say the least! Fortunately, this has a fairly simple fix which can be implemented live! The first step is to take down the device in Linux:

  • ifconfig bc0 down

The next step is to kill, with a -HUP, the net2kiss code that ties the device into the pseudo terminal, ptyqa, or whichever one you are using.

  • kill -HUP <net2kiss_process_id>

You would think at this point that all you need to do is start this process up again, but if you do, it won't work because the other end of the "pipe" is still engaged! So, as the sysadmin for JNOS, detach the device with this command from the JNOS console:

  • detach bc0

Now the device is free to be re-attached in both Linux and JNOS! Begin with the Linux side first by re-issuing the net2kiss command:

  • net2kiss -i bc0 /dev/ptyqa &

This time, the pseudo terminal/pipe will setup properly and won't fuss. You should also do another ifconfig:

  • ifconfig bc0 up

Now, returning to JNOS, run the startup script again from the command console for the device bc0, the same one that was run on JNOS boot up. (The one I run is "source /jnos/scripts/do_bc0". This script attaches the device bc0 to the pseudo terminal/pipe ttyqa on my system. Or, use the bc0 device configuration lines listed above. The do_bc0 script is more convenient and argues forceably for the use of scripts in your autoexec.nos file for all devices!)



Commentary : Just as a reminder, it is very critical to have a match between drivers when you are attempting to coordinate operations between several pieces of code! For example, the older bc0 interfaces work fine with the older net2kiss driver for the AX25 Utilities, but not as reliably for JNOS. However, if you are using the newer bcsf0 interfaces, then you need the newer version of net2kiss, which works fine with JNOS!



In summary, since I began using the "correct" version of net2kiss, I have had good success with this thru-modem approach on both JNOS and the AX25 Utilities; and I really like the idea of it! The thru-modem is not difficult to build and quite inexpensive compared to commercial TNC's. I hope this has been of some help to you in your endeavors with packet on Linux. If you have any ideas or suggestions, please pass them along. - Karl :-)

(Courtesy KBNorton Computer Services)