>Greetings,
>
>Here at Washington State University, we have a group of Electrical
>Engineering students who are doing a senior design project. This is a
>multi semester project (About 2 years) and promises to have a big impact as
>long as we can steer them in the right direction.
Neat.
>
>(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
>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?
Yeah, approximately. The linux kernel, from what I've seen, has 'devices'
and 'protocols'. Devices represent individual pieces of hardware. Their
source is in the /usr/src/linux/drivers/net/hamradio directory. The drivers
call a function that sticks their packet into a single queue for all
of linux.
Then, another hunk of code scans the queue, and
either applies that packet to a particular protocol, or optionally, the packets
can be scanned by all the protocol drivers to determine if it's a packet
for them. The protocols are in /usr/src/linux/net directory. Then the protocols
check for all the open sockets that are appropriate to that type of data.
For outgoing, the protocols, like ax25, put the blocks of data into the to
appropriate device queue. Each device, I recall, has a seperate outgoing
packet queue. I don't recall exactly how stuff gets from tcp/ip to
ax25, but I do know that packets go through ax25 protocol before they
get to the drivers.
IP Masquerading and firewalling and all that stuff happens in the code
in /usr/src/linux/net/ipv4. That is in the tcp/ip specific code. There's a magic
byte in the ax25 header, I believe, that tells the ax25 protocol handler that
the packets are TCP/IP and then, the ax25 protocol handler calls a function
in the ip code to receive all the tcp/ip stuff.
I believe, in 2.2 at least, that KISS is mainly used as a hack to
talk from the ax25 to the drivers -- as they have some KISS commands
built into them (which is a little clunky, but not really a problem, imo since
this is just all in ram anyway.). If you look in the driver source files, you should
see some commands for processing the KISS commands. As an application
you only see the KISS commands in the way that some functions are set (Though
I think these, in a sane world would be ioctls). And if you want to run kissnets
and things using the mkiss device driver.
Linux knows whether a packet is for ax25 just because the socket is opened
with AF_AX25, or the
>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.
On Windows, I've used SV2AGW www.forthnet.gr/sv2agw which has native
ax25 drivers for Windows -- and supports all kinds of hardware. Other people
run nos variants, which I'm not too familiar with. I believe the new Linux kernels,
that is the 2.3 versions will have some new improvements with ax25 and ip,
and it'd be nice to get some native Windows libraries that's compatible when
that stuff comes up, (in my humble opinion.) In sv2agw, the programming
interface isn't as clean as with Linux, since Linux you can just open an ax25 socket
-- I'm not sure if that's possible with WIndows or not. I use sv2agw, to work
9600 baud using a sound card. Seems to work pretty good, (Though I think
there's some latency (1/3 sec?) on the receiving of packets through the sound card. I
haven't tried measuring this though.)
>
>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.
Good idea. Me, I'd really like simple crystal-controlled FSK radio for 38K baud, since
my KPC9612, supposedly can suppport that speed. I did hear there's a group
in LU-land, Argentina -- right?, who all built 38K packet radios by hand, and have
pretty good network going down there. I'd suggest a 440mhz radio, since I'd have a
better
chance of getting a 100khz channel on this band.
>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?
Not sure. It's on the ftp.tapr.org, I thought I heard someone say.
>2) Has anyone already created a driver for windows for this protocol?
>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?
http://forthnet.gr/sv2agw
>4) If the above is over ambitious. What other protocols could be used
>which would be compatible for multiple operating systems?
>5) What piece of hardware (within the scope of this project) do you think
>the "global" amateur radio community would benefit most from?
Well, the global community would be more interested in 440mhz
than 222mhz, since most of them don't have 222mhz.
>----------------------------------------------------------
>David M. Ritzenthaler http://www.eecs.wsu.edu/~ritz
>[EMAIL PROTECTED] (509)335-7301
>Washington State University Work Fax (509)335-3818
>School of Elect. Engr & Comp Sci. - Pullman, WA 99164-2752
>----------------------------------------------------------
