Packet Radio and TCP/IP

Packet Radio and TCP/IP

Postby AI2Q » Fri Jan 25, 2019 10:14 am

Wither or whither KA9Q .NET?

With all the talk these days about BPQ, it might be worthwhile mentioning what the venerable “ancient” package called .NET is about. I think it still offers powerful low-overhead capabilities to the ham radio packet network builder.

Released by Phil Karn, KA9Q, to the Amateur Radio community back in the heyday of packet radio, the .NET program was intended to implement the Internet Protocol in the ranks of ham radio packet.

Over the ensuing years the KA9Q software morphed into JNOS, TNOS, etc. in the hands of skillful hackers, software gurus, and networking experts. However, in all fairness, the original software still offers a viable, simple, and straightforward TCP/IP environment for hams wishing to experiment with a powerful suite of networking tools.

A drawback of the .NET program is that it was intended to run under Unix or Linux, or (gasp) DOS. While I have yet to try running Phil’s wares using DOSbox or DePam, or other MS-DOS emulators on a Windows machine, I and others have successfully run .NET on old Windows XP machines by shelling out to the command C: prompt.

My old friend N2HLE compiled the version I run from KA9Q’s C source code. John added color packet tracing, a screen clear function, and a few other niceties, but it has one serious operational bug. Although the bug can be assiduously avoided by the prudent packeteer, it is a shortcoming.

However, in light of the ongoing revisions and (dare I say?) bugs in the development of other popular packet programs this isn’t all that serious, especially when you consider the benefits of using .NET in an Amateur Radio packet network.

In short .NET implements the Internet Protocol in FCC-mandated AX.25 frames. It also supports “plain vanilla” AX.25, so if you wish to use it to “connect” to a BPQ node or another unmodified TNC-equipped AX.25 system, it let’s you do that.

Those traditional "connections" are replete with the SABM Connect frames, the various ACK and NACK handshakes, and the series of Disconnect frames such as DM, etc. With .NET connected stations can enter “Talk” and “Mail” modes on a KA9Q box if desired.

However, .NET really shines when it comes to implementing a connection-less network. Yes, connection-less. KA9Q’s product lets you send and receive true Internet-like datagrams. These datagrams sidestep the extra overhead of AX.25 connected-oriented packet radio. Fewer packets spell a faster exchange.

The datagrams handle delivery, arrival time, and order of arrival, and that is all handled by information packets using AX.25’s inherent “beacon” un-numbered information (UI) frames.

Primary routing of this beaconed data is handled in a TCP/IP ham radio network by the use of Internet Protocol addressing. The AX.25 portion is also accommodated, so in use it forms a very robust “connectionless” network using IP addresses and callsigns. The assignment of the 4-octet IP Address (IPA) is handled by the Amateur Packet Radio organization, known as the amprnet.

For example, one of my IPA's is The 44 denotes the Amateur Packet Radio Network. The 118 routes for the state of Maine. The third octet using a 2 in my case is my local area. The last octet, the 1, is my PC.

Once the various files are installed on a DOS machine, you can use .NET to digipeat along with a KISS TNC. The system also supports NetRom. I have also operated my .NET node across 50-Mbit/second mesh gear, but that’s another story. You can also use .NET to “ping” another .NET node and see how long it takes to get a reply, or to determine if a node is on the air.

On a PC, you start .NET at a DOS prompt. Then the fun begins. The .NET program supports routing of the datagram “beacon” connection-less packets based on IP addresses. The IP addressing is contained in the data frame of the AX.25 packet.

This routing is accommodated by manually setting up routing tables between participating stations. So, for example, if I need to route a packet to N1ABC and my neighbor KC1XYZ reaches that station but I don’t, then my routing table points my IP address-laden AX.25 beacon frame for N1ABC towards KC1XYZ and then it, in turn, sends N1ABC-bound UI packets with my data.

As you might expect, error detection for each packet is inherent in AX.25. Significantly, no ACKs are required. If the data gets lost, corrupted, or trashed on its way through the amprnet network it simply get re-sent. For the .NET operator the system transparently keeps track of packet data ordering and re-assembly.

The .NET program lets you perform file transfers using the Internet’s File Transfer Protocol. With FTP you can go to another operator’s station running .NET and peruse a sub-directory. If you wish, there you can even create and navigate to a sub-directory of your own naming off that “public” directory.

You can also grab files there or place files of your own, both ASCII text files and binary files such as small JPG images or small programs. You can even do this with more than one .NET-equipped station, simultaneously. Likewise, other stations can do the same on your .NET system. You can send and receive files simultaneously.

In addition to FTP file transfers, you can use .NET's Telnet function to communicate with a remote .NET node. That lets you enter a “chat” with a target station. These chat sessions can remain “nailed up” indefinitely. I occasionally establish a chat session with a remote node and leave a message that’s time-stamped by my keyboard.

Moreover, you can send and receive e-mail between .NET stations using the Internet’s Simple Mail Transfer Program. SMTP lets you send and read e-mail with as many stations as there are on the network. Back in the day we used a program for this purpose called Bdale’s Mailer. It was written by N3EUA, now KB0G. it is still available, along with others.

Importantly, there is no store-and-forwarding. In a store-and-forward network your e-mail can be lost, or trashed in a remote crash, or accidentally by an intervening operator. In an IP network your e-mail goes directly to the recipient station.

Also, a "finger" text function lets you learn about another .NET station's history, operator name, features, etc.

I’m not adept at compiling C source code, but if there is someone out there that can do that Phil’s source files are still available on his Web site.

There's more, but that's enough for now. Any interest? My TCP/IP node running .NET is AI2Q on 145.Ø1 MHz from Kennebunk. You can also digipeat through it to get to AI2Q-4, my BPQ node.


Vy 73, AI2Q, Alex
Posts: 187
Joined: Thu Oct 20, 2011 11:36 am

Return to A Starting Point

Who is online

Users browsing this forum: No registered users and 0 guests