🚀 go-pugleaf

Archive-name: linux/howto/ham/part2
Last-modified: 22 Nov 95

-----BEGIN PGP SIGNED MESSAGE-----

*** The `Linux HAM HOWTO' is posted automatically by the
*** Linux HOWTO coordinator, Greg Hankins <gregh@sunsite.unc.edu>.  Please
*** direct any comments or questions about this HOWTO to the author,
*** Terry Dawson <94004531@postoffice.csu.edu.au>.

- --- BEGIN Linux HAM HOWTO part 2/2 ---


  13.2.  SunClock


     Author
        John Mackin, john@cs.su.oz.AU

     Description
        A clock that will show you instantly what parts of the globe are
        exposed by sunlight and what parts aren't.

     Status
        Released.

     System requirements.
        X-Windows.


     Detail
        sunclock is another of those desktop gadgets that most people
        think look nice but really don't have a lot of use for. I use
        sunclock to obtain an at-a-glance indication of the time
        anywhere in the world.  In its iconic form it sits in a small
        Mercator projection. When maximised it produces the same image
        but obviously larger with slightly more detail.  It also
        displays the date, local time and UTC. sunclock actually
        calculates mathematically what parts of globe are sunlit and
        which aren't, it seems quite accurate, so long as you assume the
        earth has no atmosphere.

     Where and How to obtain it.
        I haven't seen any precompiled sunclock binaries for Linux
        about, so check your nearest archie server. sunclock compiled
        straight out of the box for me.

     Licensing/Copyright
        Public Domain and may be freely copied as long as the notices at
        the top of sunclock.c remain intact.


  13.3.  Xearth


     Author
        Kirk Johnson, <tuna@cag.lcs.mit.edu>

     Description
        A rotating earth for X-windows root window. It has real life
        shading, and options for geostatic view, and non geostatic view.
        A prettier and more modern version of sunclock but requires a
        bit more processing power.

     Status
        Version 1.0.

     System requirements.
        X-Windows.

     Detail
        xearth is a sophisticated program which draws a colour picture
        of the earth onto your X Windows display. It offers either an
        orthographic view as you would see from space or the map like
        mercator projection. You have a number of options in determining
        the behaviour of the view. The details are available from the
        xearth Home Page <http://cag-www.lcs.mit.edu/~tuna/xearth/> and
        in the documentation which is supplied with the package.

     Where and How to obtain it.
        The source can be obtained from its home site at cag.lcs.mit.edu
        <ftp://cag.lcs.mit.edu/pub/tuna/> or just about any X11/contrib
        directory.

     Licensing/Copyright
        Copyright (C) 1989, 1990, 1993 by Kirk Lauritz Johnson. The
        copyright notice included states that xearth is freely
        redistributable so long as the copyright notice is left intact,
        and be included in documentation.

     Contributed by:
        Kirk Johnson" <tuna@kanchenjunga.lcs.mit.edu>




  14.  Installation, Configuration, Hints and Tricks.

  This section provides some detail on how to actually install and use
  some of the listed software. It will also detail some solutions to
  some tricky problems that you might encounter with the software.


  14.1.  AX.25/NetRom - Packet Radio protocol software.

  The AX.25 protocol offers both connected and connectionless modes of
  operation, and is used either by itself for point-point links, or to
  carry other protocols such as tcp/ip and netrom.

  It is similar to X.25 level 2 in structure, with some extensions to
  make it more useful in the amateur radio environment.

  The NetRom protocol is an attempt at a full network protocol and uses
  AX.25 at its lowest layer as a datalink protocol. It provides a
  network layer that is an adapted form of AX.25.

  Alan Cox developed some early kernel based AX.25 software support for
  Linux.  Jonathon Naylor <g4klx@g4klx.demon.co.uk> has taken up ongoing
  development of the code, has added NetRom support and this is
  available in ALPHA form for you to experiment with. The Linux code
  supports KISS based TNC's (Terminal Node Controllers), the Ottawa PI
  card and the Z8530 SCC driver.  Any bug reports relating to the AX.25
  or Netrom software should now go to Jonathon.

  The User programs contain a simple PMS (Personal Message System), a
  beacon facility, a line mode connect program, `listen' an example of
  how to capture all AX.25 frames at raw interface level and programs to
  configure the Netrom protocol. Included also are an AX.25 server style
  program to handle and despatch incoming AX.25 connections and a NetRom
  daemon which does most of the hard work for NetRom support.


  14.1.1.  Where to obtain the AX.25/Netrom software.

  The AX.25 software is comprised of two components, the kernel source
  and the utility programs. As of the version 1.3.* release of Linux
  kernel source the AX.25, Netrom, Z8530 SCC and PI card drivers are all
  included as a standard. I recommend you obtain and use the version
  1.3.* kernel source.  There are three reasons I'm recommending you use
  the alpha version software and they are:

  o  it makes the process of building and configuring the software a
     whole lot simpler. There are no patches to apply it is a simple
     matter of configuring and compiling a kernel with the appropriate
     options enabled.

  o  it is the most recent software and is most likely to provide the
     most satisfactory results.

  o  like all new software, it needs testing and bug reports. The more
     people that take the software and attempt to use it in their own
     configurations the more likely it will be that bugs are uncovered
     and the easier it will be to get the software debugged. Join the
     team, contribute bug reports and help everybody.

  Be warned though, this software is alpha and may have problem that you
  wouldn't otherwise encounter. Please take all the usual precautions
  and be sure to keep a working kernel as backup when testing new
  kernels. It is wise to test a new kernel by booting from it from
  floppy before actually installing it with lilo, though I haven't
  bothered for about 90 kernels revisions so I'm fairly confident you
  can pretty safely run with alpha kernels.
  You can obtain the latest kernel source from:

  ftp.funet.fi


       /pub/OS/Linux/PEOPLE/Linus/v1.3/




  You will also need the utility programs. The latest version of those
  can be found at:

  sunsite.unc.edu


       /pub/Linux/apps/ham/ax25-utils-1.3.30.tar.gz




  or:

  ftp.ucsd.edu


       /hamradio/packet/tcpip/incoming/ax25-utils-1.3.30.tar.gz






  14.1.2.  Installing the AX.25 software.

  The software comes in two parts, the kernel source, and the user
  programs.


  14.1.2.1.  The kernel source.

  If you are using the 1.3.* kernel source then all you have to do is
  build the kernel as you would normally.

  The following should be safe:



       # cd /usr/src/linux
       # make config
       # make dep;make






  o  Be sure to answer `yes' when you are asked if you should include
     the AX.25 support in the make config step.

  o  You will also need to answer `y' to including SLIP if you want the
     AX.25 code to support a KISS TNC or if you intend running a version
     of NOS on your system and you wish to be able to link it with the
     rest of your system.


  o  You will be asked if you wish to include the Z8530 driver.

  o  If you wish to support the Ottawa PI driver then you must answer
     `y' when asked: Do you want to be offered ALPHA test drivers ?

     and: Other ISA cards ?

     then `y' when prompted:

     Ottawa PI and PI/2 support.


  14.1.2.2.  The user programs.

  To install the user programs you should try:



       # cd /usr/local
       # gzip -dc ax25-utils-1.3.30.tar.gz | tar xvvof -
       # cd ax25-utils-1.3.30
        ... if you are using a.out binaries:
       # install.sh a.out
        ... if you want to install ELF binaries:
       # install.sh ELF




  If you want to compile your own binaries then you should do the
  following:



       # cd src
       # make clean
       # make install





  14.1.3.  Configuring an AX.25 connected mode interface.

  Configuring an AX.25 port is very similar to configuring a slip
  device.  The AX.25 software has been designed to work with a TNC in
  kiss mode or an Ottawa PI2 card. You will need to have the TNC
  preconfigured and connected to your serial port. You can use a comms
  program like minicom or seyon to configure the TNC into kiss mode if
  you wish.

  You use the axattach program in much the same way as you would use the
  slattach program (refer to the NET-2-HOWTO for more information on
  slattach and the other network software for Linux). For example:



       # /usr/local/sbin/axattach -s 4800 /dev/ttyS1 VK2KTJ-1 &
       # sleep 2




  would configure your /dev/ttyS1 serial device to be a kiss interface
  at 4800 bps, with the hardware address VK2KTJ. The sleep of 2 seconds
  is necessary just to give the kernel a little time to do some
  housekeeping that it has to do before you try and change the
  interface.

  You can use the axsetcall command to change the callsign of an AX.25
  interface after it has been created if you wish.

  All this step has done is to actually activate the device in the
  kernel, you need to run other programs before you an actually make use
  of the port. The AX.25 ports have a configuration file that can be
  read by any program that wants to use AX.25 to find information about
  the port. This file is called the:



       /usr/local/etc/axports




  file. The format of the file is as follows:



       callsign baudrate window label




  where:


     callsign
        is the AX.25 callsign you want to assign to the port.

     baudrate
        is the speed at which you wish the port to communicate with your
        TNC.

     window
        is the AX.25 window (K) parameter. This is the same as the
        MAXFRAME setting of many tnc's.

     label
        is a name for the port.

  In my case, mine looks like:



       VK2KTJ-1 4800 1 radio




  At this stage not all of this information is used, it will be picked
  up and used in later developments. You now should be able to make
  outgoing AX.25 connections. To test AX.25 connected mode you could use
  something similar to the following:



       /usr/local/bin/call VK2DAY via VK2RVT




  The call program is a linemode terminal program for making AX.25
  calls. It recognises lines that start with ` ' as command lines.  The
  ` .' command will close the connection.

  Please refer to the man pages in /usr/local/man and the README file in
  ax25-utils-1.3.30 distribution for more information.


  14.1.4.  Configuring Linux to accept Incoming AX.25 connections.

  Linux is a powerful operating system and offers a great deal of
  flexibility in how it is configured. With this flexibility comes a
  cost in configuring it to do what you want. When configuring your
  Linux machine to accept incoming AX.25 connections there are a number
  of questions you need to ask yourself.  The most important of which
  is: "What do I want users to see when they connect?". As detailed in
  the software list at the start of this document there are BBS systems
  that are being developed that you might want users to see when they
  connect, alternatively you might want to give users a login prompt so
  that they can make use of a shell account, or you might even have
  written your own program, such as a customised database or a game,
  that you want people to connect to. Whatever you choose, you must tell
  the AX.25 software about this so that it knows what software to run
  when it accepts an incoming AX.25 connection.

  You do this within the /usr/local/etc/ax25d.conf. This file is the
  configuration file for the ax25d AX.25 daemon which handles incoming
  AX.25 connections.

  The file is a little cryptic looking at first, but you'll soon
  discover it is very simple in practise, with a small trap for you to
  be wary of.

  The format of the ax25d.conf file is as follows:



       # This is a comment and is ignored by the ax25d program.
       [<interface_call>]
       <peer1>  window T1 T2 T3 N2 <mode> <uid> <cmd> <cmd-name> <arguments>
       <peer2>  window T1 T2 T3 N2 <mode> <uid> <cmd> <cmd-name> <arguments>
       defaults window T1 T2 T3 N2 <mode> <uid> <cmd> <cmd-name> <arguments>
       <peer3>  window T1 T2 T3 N2 <mode> <uid> <cmd> <cmd-name> <arguments>
       default  window T1 T2 T3 N2 <mode> <uid> <cmd> <cmd-name> <arguments>




  Where:

     #  at the start of a line marks a commment and is completely
        ignored by the ax25d program.

     <interface_call>
        is the AX.25 callsign of the interface that this particular
        paragraph is for.

     <peer>
        is the callsign of the peer node that this particular
        configuration applies to. If you don't specify an SSID here then
        any SSID will match.

     window
        is the AX.25 Windows parameter (K) or MAXFRAME parameter for
        this configuration.

     T1 is the Frame retransmission (T1) timer in half second units.

     T2 is the amount of time the AX.25 software will wait for another
        incoming frame before preparing a response in 1 second units.

     T3 is the amount of time of inactivity before the AX.25 software
        will disconnect the session in 1 second units.

     N2 is the number of consecutive retransmissions that will occur
        before the connection is closed.

     <mode>
        provides a mechanism for determining certain types of general
        permissions. The modes are enabled or disabled by setting or
        resetting bits in an 8 bit map. You set that map by setting
        <mode> to the sum of the following values:

        1  Setup utmp, and run on a ptty (planned).

        2  UNUSED.

        4  UNUSED.

        8  UNUSED.

        16 UNUSED.

        32 UNUSED.

        64 Disallow digipeated uplinks, only allow direct connections.

        128
           Lockout, Barred, immediate disconnect.

     <uid>
        is the userid that the program to be run to support the
        connection should be run as.

     <cmd>
        is the full pathname of the command to be run, with no arguments
        specified.

     <cmd-name>
        is the text that should appear in a ps as the command name
        running (normally the same as <cmd> except without the directory
        path information.

     <arguments>
        are the command line argument to be passed to the <:cmd> when it
        is run. You pass useful information into these arguments by use
        of the following tokens:

        %U AX.25 callsign of the connected party without the SSID, in
           uppercase.

        %u AX.25 callsign of the connected party without the SSID, in
           lowercase.

        %S AX.25 callsign of the connected party with the SSID, in
           uppercase.

        %s AX.25 callsign of the connected party with the SSID, in
           lowercase.

  You need one section in the above format for each AX.25 interface you
  want to accept incoming AX.25 connections on.
  There are two special lines in the paragraph, one starts with the
  string `defaults' and other starts with the string `default' (yes
  there is a difference). These lines serve special functions.

  The `default' lines purpose should be obvious, this line acts as a
  catch-all, so that any incoming connection on the <interface_call>
  interface that doesn't have a specific rule will match the `default'
  rule. If you don't have a `default' rule, then any connections not
  matching any specific rule will be disconnected immediately without
  notice.

  The `defaults' line is a little more subtle, and here is the trap I
  mentioned earlier. In any of the fields for any definition for a peer
  you can use the `*' character to say `use the default value'. The
  `default' line is what sets those default values. The kernel software
  itself has some defaults which will be used if you don't specify any.
  The trap is that the these defaults apply only to those rules below
  the `default' line not to those above. You may have more than one
  `default' rule per interface definition, and in this way you may
  create groups of default configurations.

  Ok, an illustrative example:



       # ax25d.conf for VK2KTJ - 21/11/95
       # This configuration uses the AX.25 port defined earlier.
       [VK2KTJ-1]
       NOCALL     *     *  *  *  *   0    guest /usr/games/fortune
       defaults   1    10  *  *  *   0    root  /bin/login ax25login
       VK2XLZ-1   *     *  *  *  *   *      *     *         *
       VK2DAY-1   *     *  *  *  *   *      *     *         *
       default    1    10  5 100 5   0    root  /usr/local/bin/bbs bbs %u
       #




  This example says that anybody to the interface on my machine with the
  callsign VK2KTJ-1 will have the following rules applied:

  Anyone whose callsign is set to `NOCALL' should use the kernel default
  parameters and have the fortune program run as guest for them.

  The defaults line changes two parameters from the kernel defaults
  (Window and T1) and will run the /bin/login login program for them.
  Any copies of login run this way will appear as ax25login in a ps
  listing so that you can easily distinguish AX.25 logins from others.
  Following are definitions for two stations who will receive those
  permissions.

  The last line in the paragraph is the catch all definition that
  everybody else will get (including VK2XLZ and VK2DAY using any other
  SSID other than -1).  This definition sets all of the parameters
  implicitly and will cause the bbs program to run with a command line
  argument of the callsign of the connecting peer in lower case with no
  SSID.

  If you wanted to define rules for another interface, even a Netrom
  interface, then you would add another paragraph coded in the same way
  with rules and callsign appropriate to it.

  This example is a contrived one but I think it illustrates clearly the
  important features of the syntax of the configuration file. Jonathon
  includes a much longer and more detailed example in the ax25-utils
  package.
  14.1.5.  Configuring an AX.25 interface for tcp/ip.

  If you want to carry tcp/ip over the AX.25 port you have configured,
  all you need to do is use the ifconfig program to configure the ip
  address and netmask details for the port and add a route via the port.



       # /sbin/ifconfig sl0 44.136.8.5
       # /sbin/ifconfig sl0 netmask 255.255.255.0
       # /sbin/ifconfig sl0 broadcast 44.136.8.255
       # /sbin/ifconfig sl0 arp mtu 256 up
       # /sbin/route add -net 44.136.8.0 sl0
       # /sbin/route add default sl0




  The commands listed above are typical of the sort of configuration
  many of you would be familiar with if you have used NOS or any of its
  derivatives or any other tcp/ip software. Note the default route might
  not be required if you have some other network device conifgured.

  To test it out, try a ping or a telnet to a local host.


  14.1.6.  Configuring an AX.25 interface for Netrom.

  To configure Netrom for an AX.25 interface you must configure two
  files.

  The first is the /usr/local/etc/nrports file. This file describes the
  Netrom port.

  This file is formatted as follows:



       callsign  alias     description




  Where:

     callsign
        is the callsign that the Netrom traffic from this port will use.

     alias
        is the Netrom alias this port will have assigned to it.

     description
        is a free text description of the port.

  An example would look something like the following:



       VK2KTJ    MTCOLAH   Netrom Switch Port




  Note again that the first line refers to the first Netrom interface,
  the second line refers to the second Netrom interface and so on.

  The second file is the /usr/local/etc/nrbroadcast file.

  This file is formatted as follows:



       port min_obs def_qual worst_qual verbose




  Where:

     port
        is the port number obtained from the /usr/local/etc/axports
        file. The first line in the file describes AX.25 port number
        one, the second describes port number two etc. If you do not
        have an entry in /usr/local/etc/nrbroadcasts for a port then
        this means that no Netrom routing will occur and any received
        Netrom broadcasts will be ignored for that port.

     min_obs
        is the minimum obselesence value for the port.

     def_qual
        is the default quality for the port.

     worst_qual
        is the worst quality value for the port, any routes under this
        quality will be ignored.

     verbose
        is a flag determining whether full Netrom routing broadcasts
        will occur from this port or only a routing broadcast
        advertising the node itself.

  An example would look something like the following:



       1    1       200      10         1
       2    1       200      10         1





  14.2.  Ottawa PI/PI2 card driver.

  The Ottawa PI card is a Z8530 SCC based card for IBM PC type machines
  that is in common usage by Amateur Radio operators worldwide. While it
  is most commonly used by Amateur Radio Operators, it could be pressed
  into service in other fields where it is desirable to have the
  features of a Z8530. It supports a high speed half duplex (single DMA
  channel) port, and a low speed (<9k6bps interrupt driven) half duplex
  port. The PI2 is a new version of the card that supports an on board
  radio modem, and improved hardware design.

  A driver for this card has been written by David Perry,
  <dp@hydra.carleton.edu>, and is available from in the standard linux
  kernel. Please refer to the AX.25 section above for details on how to
  configure the kernel to include the PI card driver.

  Once you have the PI card driver configured into your kernel then you
  should reboot and when you do you should see mention of the PI card
  driver in the messages that appear on the screen while the kernel is
  booting. The kernel tests each of the I/O port addresses that a PI
  card might be configured for and reports any that it finds. You should
  then look at the /proc/net/dev file and you should see reference to
  devices called pi0a and pi0b etc.

  If you don't then recheck that you have configured and compiled your
  kernel correctly and that you are in fact actually running your new
  kernel. If you still don't then this suggests that your PI card was
  not detected by the kernel while it is booting and may indicate that
  you have some sort of hardware conflicting with your PI card that
  prevented it being detected.

  If all of the above went as planned then you will need to configure
  your PI card for IP. The configuration of the PI card is virutally
  identical to that of any other IP interface. Something like the
  following should work ok for you:



       # /sbin/ifconfig pi0a 44.136.8.5
       # /sbin/ifconfig pi0a netmask 255.255.255.0
       # /sbin/ifconfig pi0a broadcast 44.136.8.255
       # /sbin/ifconfig pia arp mtu 256 up
       # /sbin/route add -net 44.136.8.0 pi0a
       # /sbin/route add default pi0a




  Note that pi0a refers to the `a' port on the first PI card found, and
  that pi0b would therefore refer to the `b' port on the first PI card
  found etc.

  As usual, when this has been done you can test the interface with the
  ping or telnet command to ensure it is working.


  14.3.  HOWTO link NOS and the Linux kernel networking software

  Many people like to run some version of NOS under Linux because it has
  all of the features and facilities they are used to. Most of those
  people would also like to have the NOS running on their machine
  capable of talking to the Linux kernel so that they can offer some of
  the linux capabilities to radio users. Brandon S. Allbery, KF8NH,
  contributed information to explain how to achieve this.

  Since both Linux and NOS support the slip protocol it is possible to
  link the two together by creating a slip link. You could do this by
  using two serial ports with a loopback cable between them, but this
  would be slow and costly. Linux provides a feature that many other
  unix-like operating systems provide called `pipes'. These are special
  pseudo devices that look like a standard tty device to software but in
  fact loopback to another pipe device. To use these pipes the first
  program must open the master end of the pipe, and the open then the
  second program can open the slave end of the pipe. When both ends are
  open the programs can communicate with each other simply by writing
  characters to the pipes in the way they would if they were terminal
  devices.

  To use this feature to connect the Linux Kernel and a copy of NOS, or
  some other program you first must chosoe a pipe device to use. You can
  find one by looking in your /dev directory. The master end of the
  pipes are named: ptyp[1-f] and the slave end of the pipes are known
  as: ttyp[1-f]. Remember they come in pairs, so if you select
  /dev/ptypf as your master end then you must use /dev/ttypf as the
  slave end.
  Once you have chosen a pipe device pair to use you should allocate the
  master end to you linux kernel and the slave end to the NOS program,
  as the Linux kernel starts first and the master end of the pipe must
  be opened first.  You must also remember that your Linux kernel must
  have a different IP address to your NOS, so you will need to allocate
  a unique address for it if you haven't already.

  You configure the pipe just as if it were a serial device, so to
  create the slip link from your linux kernel you can use commands
  similar to the following:



       # /sbin/slattach -s 38400 -p slip /dev/ptypf &
       # /sbin/ifconfig sl0 broadcast 44.255.255.255 pointopoint 44.70.248.67 /
               mtu 1536 44.70.4.88
       # /sbin/route add 44.70.248.67 sl0
       # /sbin/route add -net 44.0.0.0 gw 44.70.248.67




  In this example the Linux kernel has been given IP address 44.70.4.88
  and the NOS program is using IP address 44.70.248.67. The route
  command in the last line simply tells your linux kernel to route all
  datagrams for the amprnet via the slip link created by the slattach
  command. Normally you would put these commands into your
  /etc/rc.d/rc.inet2 file after all your other network configuration is
  complete so that the slip link is created automatically when you
  reboot.  Note: there is no advantage in using cslip instead of slip as
  it actually reduces performance because the link is only a virtual one
  and occurs fast enough that having to compress the headers first takes
  longer than transmitting the uncompressed datagram.

  To configure the NOS end of the link you could try the following:



       # you can call the interface anything you want; I use "linux" for convenience.
       attach asy ttypf - slip linux 1024 1024 38400
       route addprivate 44.70.4.88 linux




  These commands will create a slip port named `linux' via the slave end
  of the pipe device pair to your linux kernel, and a route to it to
  make it work. When you have started NOS you should be able to ping and
  telnet to your NOS from your Linux machine and vice versa. If not,
  double check that you have made no mistakes especially that you have
  the addresses configured properly and have the pipe devices around the
  right way.


  15.  How to contribute or update an entry.

  I'd like for this list to be as complete and up-to-date as possible.
  So I'm keen to hear about any developments or products that I don't
  already know about, or that the entry is obselete or outdated for.

  What I'd like as a minimum set of requirement would be something like
  the following:


     Name
        The name of the software in question.
     Author
        Who wrote, or ported the software. An email address, or some
        other means of contacting them is also essential.

     Description
        A single line description of what the software does.

     Status
        An indication of the software's status. Is it still in testing?
        Is it a production release? Is it still in the design stage?

     System requirements
        What does the software require to run? Does it require X-
        Windows? Does it need a soundcard? Does it need a certain
        version of kernel? Does it need other software to support it?

     Detail
        I'm not keen on including a large amount of detail on each piece
        of software as this would consume a lot of time reading and
        trying to keep up to date. So instead what I'd like to list is
        what makes this software unique, anything special about it.
        Perhaps its most outstanding features, that sort of thing.

     Where and How to obtain it.
        If the software is freely distributable then ftp details would
        be great.  If it is commercial software then the name of the
        company distributing the software, and an address or telephone
        number. If it is available only by some other means, say mail
        order, then details on where and how to obtain it.

     Licensing/Copyright
        Is the software Copyleft? Copyright? Shareware? Public Domain?
        Restricted in use in any way?

  Don't worry if you don't know all of these details, just send me what
  you do know and I'll list what I can. I'd rather have an incomplete
  listing than no listing at all.

  Please mail any contributions to:

  94004531@postoffice.csu.edu.au or terry@perf.no.itg.telecom.com.au

  I'd list a packet radio address too but I'm still not properly
  operational again yet after moving house.


  16.  Discussion relating to Amateur Radio and Linux.

  There are various places that discussion relating to Amateur Radio and
  Linux take place. They take place in the comp.os.linux.* newsgroups,
  they also take place on the HAMS list on vger.rutgers.edu. Other
  places where they are held include the tcp-group mailing list at
  ucsd.edu (the home of amateur radio tcp/ip discussions), and you might
  also try the #linpeople channel on the undernet irc network.

  To join the Linux linux-hams channel on the mail list server, send
  mail to:


       Majordomo@vger.rutgers.edu




  with the line:

  subscribe linux-hams




  in the message body. The subject line is ignored.

  To join the tcp-group send mail to:


       listserver@ucsd.edu




  with the line:


       subscribe tcp-group




  in the body of the text.

  Note: Please remember that the tcp-group is primarily for discussion
  of the use of advanced protocols, of which tcp/ip is one, in Amateur
  Radio. Linux specific questions should not ordinarily go there.


  17.  Copyright.

  The HAM-HOWTO is Copyright (c) 1995 Terry Dawson.

  Permission is granted to make and distribute verbatim copies of this
  document provided the copyright notice and this permission notice are
  preserved on all copies.

  Permission is granted to copy and distribute modified versions of this
  document under the conditions for verbatim copies above, provided a
  notice clearly stating that the document is a modified version is also
  included in the modified document.

  Permission is granted to copy and distribute translations of this
  document into another language, under the conditions specified above
  for modified versions.

  Permission is granted to convert this document into another media
  under the conditions specified above for modified versions provided
  the requirement to acknowledge the source document is fulfilled by
  inclusion of an obvious reference to the source document in the new
  media. Where there is any doubt as to what defines 'obvious' the
  copyright owner reserves the right to decide.

- --- END Linux HAM HOWTO part 2/2 ---

-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
Comment: finger gregh@cc.gatech.edu for public key

iQCVAwUBMOnOHXtNTo2suu5NAQGcHgP6An08XS64PXjl2JiKXoZcCGqRt9GQzpYm
F7/mdE8Qtfjlprzu9WyoG307hzGz4oUR/7R/tw3mbKM1eAdqhJrbngCEtSKsgWMn
IsNzjnrrYUsYvEoyqgy51h9lxddsh+8f51uXuiliscw9Pldx80QuOxv97pj4kT1r
8KsHDyfPwkQ=
=k4pW
-----END PGP SIGNATURE-----