On Mon, Nov 08, 1999 at 10:53:10AM -0800, ritz wrote:
> (A little background).
> Coincidentally, I'm pretty close to getting 9.6K packet going in this area.
>  Redhat Linux 6.1, with 
> libax25-0.0.7-1, ax25-apps-0.0.4-1, and ax25-tools-0.0.5-1.  We are using
> Kenwood TH-D7's (Funded by another research project).
> 
> So my understanding of AX.25 is as follows: The Linux Kernel gets a network
> packet all ready to go, but instead of launching it through it's network
> device (eth0 for example), using IP Masquerading and hard routing commands,
> I can get it to route the information through the serial port.  At which

IP Masquerading has nothing to do with it.  The kernel makes the KISS
serial interface look just like another network interface, so that from
then on the configuration is no different than having two ethernet cards
in the machine and routing traffic.  Usually they are hard routes but
there have been experiments with using RIP on packet too.  Of course in 
referring to routing we are talking about TCP/IP traffic but there is
also a lower-level interface for sending individual packets, and interfaces
for NET/Rom stuff and Rose stuff.

> time the kiss protocol is utilized as a driver so the kernel can send and
> receive packets through the serial port packet device.  And isn't it true
> that the actual protocol of the packets exchanged is AX.25?

Yes, in the same way that on an ethernet cable the packets being exchanged 
are ethernet packets, but there can be higher-level protocols layered on
top, or not, depending on your needs.
> 
> The reason I need to know is because I would like this group of students to
> write a driver for windows 95/98 (maybe NT) to allow the same sort of
> device interaction.  Naturally I'm looking for "double click the setup.exe"
> with minimal instructions.  I'm a UNIX Admin / programmer by trade, but I
> also see the value in making this hobby easier for others, thereby growing
> the hobby.  In my mind I envision Windows 95, and Linux chatting happily
> along using the same protocol Linux is currently using for AX.25.

This has been done already.  Besides the world doesn't need more Windows
device drive authors; in a few years it will be obsolete anyway.  You already
know that Linux is better so I don't see why you need convincing to just
stick with it.  In my area the advanced packet users have mostly skipped 
Windows and gone from DOS/NOS to Linux.
> 
> They also plan on building a radio card for a PC also.  While I think this
> is over the scope of the class, and that it may be too expensive to
> actually distribute, the professor strongly disagrees with me, and insists
> that they can make it work.  They feel they can manufacture enough to make
> them reasonably priced, but he also is willing to sell them in "kit" form,
> to be built by the end user.  The kit's might cost $75.00.  The goal of the
> group is to start at 9.6Kb, and then move up to 19.2.  I should mention
> they want to use the 222MHz band.  And then if all goes well, they would
> move right up to 56Kb.

This sounds like a wonderful project; and after all, they are _electrical_ 
engineers so it's probably more appropriate than writing software.  
If you sell the kits I would probably buy one.
> 
> I'm excited about the potential of this project, but I lack the
> understanding of the actual protocol, and of high-speed packet in general.
> I would greatly appreciate a critique of the proposed plan.   
> 
> Specific Questions
> 1) What is the actual protocol used in the packets via the radio link?

AX.25

> 2) Has anyone already created a driver for windows for this protocol?

Yes.  I don't know where exactly but I'm sure you can find it on yahoo or 
something.

> 3) Is it possible (with a driver, some convoluted way) to get windows to be
> compatible with the Linux AX.25 protocol?   Has it been done before?  Website?

Yes.  AX.25 is a standard and is largely interoperable regardless of the OS
behind it.

> 4) If the above is over ambitious.  What other protocols could be used
> which would be compatible for multiple operating systems?

There is little else on the ham bands, on VHF and above.  On HF there are
lots of other protocols optimzed for dealing with really bad propagaion 
conditions, but they are much slower.  Recently there has been some 
spread-spectrum interest.  There is an overview article of the non-SS
high-speed options at http://www.cnunix.com/tpk/wa4dsy/hispeed.html

> 5) What piece of hardware (within the scope of this project) do you think
> the "global" amateur radio community would benefit most from?  

Your radio/modem on a card sounds like a good idea, and when completed
would be state of the art.  If miniaturizing and dealing with the electrically
noisy environment of the PC prove too challenging you could build a box
with a radio, modem and embedded PC (with good shielding around the radio).
A network appliance for packet, basically.  But it would be more expensive
than just making a card.

Alternatively you could work on a really high speed microwave link.  But
that has been sortof done, just not on a large scale; I think there are
plenty of reliability and ease-of-use problems left to solve.  So far people
have tried using Gunnplexer devices with ethernet cards and slowed-down
(1-2mbit) network interfaces of various kinds.  If using any normal ethernet
card would result in a reliable link it might have potential for widespread
adoption; or else a modern optimized card needs to be developed for whatever
speed can be the most reliable with these cheap gunnplexers.  Just my 
opinion based on what I've read - I have no microwave experience.

Or, you could mess with spread spectrum.  Again so far people have been 
using souped-up commercially available gear, and I'm not sure how much 
room for improvement there is.  Certainly getting a high-power long-
distance link seems like a worthwhile idea.

-- 
  _______                                     http://www.bigfoot.com/~ecloud
 (_  | |_)  [EMAIL PROTECTED]   finger [EMAIL PROTECTED]
 __) | | \__________________________________________________________________

Reply via email to