NET/ROM support in the KA9Q NET Package Dan Frank, W9NK INTRODUCTION The NET/ROM support for the KA9Q package serves three purposes: 1) Existing NET/ROM networks may be used to send IP traffic. 2) NET may be used as a NET/ROM packet switch. 3) NET may be used to communicate with NET/ROM nodes, and its mailbox facility can accept connects over the NET/ROM network. SETTING UP THE NET/ROM INTERFACE No physical interface is completely dedicated to net/rom, which is as it should be. You attach all your AX.25 interfaces, of whatever sort. Then you attach the net/rom pseudo-interface ("attach netrom"). Then you identify to the net/rom software those interfaces you want to allow it to use, with the "netrom interface" command. The format of this command is: netrom interface ax0 #ipnode 192 The first argument is the name of the previously attached interface you want to use. The second argument is the alias of your node, to be used in your routing broadcasts. The alias is never used for anything else (as you will see!). The last number is the net/rom quality figure. This is used in computing the route qualities; it represents the contribution of this interface to the overall computation. For a 1200 baud half-duplex connection, 192 is the right number. You need a netrom interface command for every interface you're going to use with net/rom. TRACING ON THE NET/ROM INTERFACE If you want to trace your NET/ROM datagrams, don't try turning on trace mode for the "netrom" interface. Nothing will break, but nothing will happen. You should trace the individual AX.25 interfaces instead. ROUTING BROADCASTS Once you have set up your interfaces, you need to set some timers. There are two: the nodes broadcast interval timer, and the obsolescence timer. These are set in seconds, like the smtp timer. You should usually set them to an hour. You can set them to something different, if you want. If your local net/rom nodes broadcast every hour, but you want to do so every ten minutes, you can say: netrom nodetimer 600 netrom obsotimer 3600 Every time the obsotimer kicks, the obsolescence counts for all non-permanent entries are decremented by one. When the count for an entry falls below five, it is no longer broadcast. When it falls to 0, it is removed. The count is initialized at 6. These will eventually be settable parameters; you can adjust them now by changing the initializers for the variables in the source file. When you first come on the air, you can send out nodes broadcasts to tell the local nodes that you are available. Use the command: netrom bcnodes ax0 where ax0 is the interface on which you want to send the broadcast. Do this for every interface on which you want to do this. By default, the NET/ROM code does not broadcast the contents of your routing table. This is as it should be, since usually we just want to be the endpoints of communications rather than relaying NET/ROM traffic. If you want to be a switch station, include the command: netrom verbose yes in your autoexec. Sometimes you can hear broadcasts from nodes that can't hear you. If your routing table gets filled with these unusable routes, your node will grind to a halt. The solution to this is node broadcast filtering, via the netrom nodefilter command. There is a filter list, which contains a list of callsigns and interfaces. Then there is a filter mode, which indicates what to do with the list. If the filter mode is "none", no filtering is done. If it is "accept", then only broadcasts from the indicated stations on the indicated interfaces are accepted. If it is "reject", then all broadcasts except those from the listed stations on the listed interfaces are accepted. Because the net/rom code cannot at this time recognize unusable routes and try alternates, I strongly recommend use of the filter command to restrict broadcast acceptance to those nodes which you know you can reach. THE NET/ROM ROUTING TABLE The next net/rom commands are those used for maintaining the routing table. They fall under the "netrom route" subcommand. "netrom add" adds a permanent entry to the routing table. Its format is: netrom route add #foo w9foo ax0 192 w9rly This command adds an entry for w9foo, whose alias is #foo, route quality 192, via w9rly on interface ax0. Let's talk about what this means. w9foo is the *destination* node, the one to whom you want the packets routed by the net/rom network. w9rly is your *neighbor*, the net/rom node to which you pass the packet to be forwarded. Since w9rly may appear on more than one interface (the callsign may be used by more than one net/rom node on different bands), we specify that we are to use ax0 to send the packet. With net/rom, like IP, we don't know exactly what route a packet will take to its destination. We only know the name of a neighbor which has indicated a willingness to forward that packet (of course, the neighbor may be the destination itself, but that's unlikely in our application). Net/rom sends the packet to the neighbor, with a network header specifying our callsign and that of the ultimate destination (in this case w9foo). We can use the netrom route add command to establish a digipeater path to the neighbor. For example: netrom route add #foo w9foo ax0 192 w9rly wd9igi This will cause us to use wd9igi as a digipeater in establishing our connection to the net/rom node w9rly. To drop the route to w9foo, you would type netrom route drop w9foo w9rly ax0 To see the contents of your routing table, you may type netrom route and to see the routing entries for an individual station you can type netrom route info You may not use an alias as an argument to the netrom route info command. I can not stress enough that "route add" and "netrom route add" are two different commands, with different purposes. In general, you only need a "netrom route add" if you need to add a route to a net/rom node via a digipeater path. If you find yourself using this command, ask yourself, "Why am I doing this?" Many people do not understand that net/rom does automatic routing (well, sort of :-)). THE IMPORTANCE OF THE ROUTING TABLE The NET/ROM routing table is analogous to the IP routing table: if there is nothing in it, your NET/ROM traffic will not go out. You must either manually enter a list of routes (perhaps via your autoexec.net) or wait to receive routing broadcasts from your neighbors before your NET/ROM traffic will leave your station. If you go to send packets via NET/ROM and nothing happens, even if you have trace mode on, make sure that the destination node is in your NET/ROM routing table. If sending IP traffic, double check the ARP table for an appropriate NET/ROM ARP entry for the destination node (see below for more information on the use of the ARP table). The ARP table is not used for NET/ROM transport routing. INTERFACING WITH NET/ROMS USING YOUR SERIAL PORT What if you have a net/rom node or nodes, and you'd like to attach them to your computer via their serial interfaces, and use net as a packet switch? It's very easy: you have to attach those interfaces, using the "attach asy" command, but specifying type "nrs" instead of "slip" or "kiss". "nrs" is the net/rom serial framing protocol, which is like KISS, but uses different framing characters and has an 8-bit checksum. When you attach an nrs interface, it can be used for passing IP datagrams or AX.25 frames over serial lines or modems. To use it for net/rom, you have to identify it to the netrom code just like any other interface, with the "netrom interface" command. THE TIME TO LIVE INITIALIZER The "netrom ttl" command allows setting of the time-to-live initializer for NET/ROM datagrams. I recommend a value of 16 for most networks. Use more if you expect to go more than 16 hops. The default is 64. The purpose of the ttl initializer is to prevent a packet from getting caught forever in routing loops. Every router who handles the packet decrements the ttl field of the network datagram before sending it on, and when it reaches 0 it is discarded. USING NET/ROM SUPPORT FOR IP Now you know all the commands, but how do we actually use net/rom for IP communications? This takes two steps: Step one: update the routing table. In all likelihood, you will use net/rom to gateway two IP subnets. So, you'll probably want to identify a station on each end as a gateway. Let's say we're on the Milwaukee subnet, and we want to talk to someone in Madison. If we're not the gateway, we just have a routing table entry like this: route add [44.92.0.0]/24 ax0 wg9ate-pc.ampr This specifies that wg9ate should get all packets for the 44.92.0.x subnet via interface ax0. Wg9ate has this routing table entry: route add [44.92.0.0]/24 netrom w9mad-pc.ampr (presuming that w9mad is the Madison gateway). Now, when the IP layer at wg9ate gets datagrams for Madison, it knows that they have to go via net/rom to w9mad. Notice that we don't specify a "real" interface, like ax1 or nr0, in the route entry. The net/rom network layer will pick the right interface based on its net/rom routing tables. We're not done yet, though. w9mad-pc.ampr is not an ax.25 callsign. The net/rom send routine called by the IP layer needs to map from the IP address to an ax.25 address. It does this via a manually added arp entry: arp add w9mad-pc.ampr netrom w9mad [We kind of fudged by using the arp table for this purpose, since there is no way to do automatic address resolution for net/rom, and arp messages are never sent or received for net/rom nodes. However, the arp table does contain precisely what we have here: mappings from IP addresses to callsigns, and it saved a lot of code to do it this way.] Notice also that no digipeaters are ever specified in the arp entry for a net/rom node. Also, the callsign to which we are mapping is the final destination of the packet, not the non-destination neighbor. That neighbor will be picked based on the net/rom routing tables. So, as a summary, let's look at what happens to a packet that reaches the IP layer on wg9ate, destined for Madison. The IP routing code looks the destination IP address up in the table, and discovers that it should go via net/rom to w9mad-pc.ampr. So, it passes the packet to the net/rom send routine. That routine uses the arp table to translate w9mad-pc's IP address to the callsign "w9mad". Then it passes the packet to the net/rom routing code. That code checks to see if the destination callsign (w9mad) is the same as that of any of its assigned net/rom interfaces. Since it isn't, it puts a network layer header (a.k.a. net/rom level 3 header) on it, and looks for w9mad in its routing tables. Presumably, it finds an appropriate neighbor for the packet, and sends in out via ax.25. The net/rom network does the job of actually getting the packet to its destination. At w9mad, the packet's protocol ID causes it to be sent to the same net/rom routing code that handled the outgoing packet from wg9ate (running on a different computer, of course). Now the destination callsign matches, so the net/rom network layer header is stripped off, and packet is passed up to the IP layer. (Net/rom network headers don't have a protocol ID byte, so we just hope for the best. If a net/rom node addresses a net/rom transport layer packet to us, it is likely to be dropped by IP for any of a number of reasons.) THE NET/ROM TRANSPORT LAYER NET/ROM transport is the protocol used by NET/ROM node to communicate end-to-end. When a user attaches to a NET/ROM via AX.25, and asks for a connect to a node in the NODES list, his local NET/ROM tries to open a transport connection to the destination node over the NET/ROM network. NET/ROM transport packets are carried in NET/ROM network datagrams, just like IP datagrams. You shouldn't use NET/ROM transport when connecting to other TCP/IP stations. TCP is a much better protocol than NET/ROM transport, and makes better use of available bandwidth. Also, BM and SMTP are more convenient to use than a TCP/IP station's mailbox facility. However, for communicating with AX.25 users via the NET/ROM network, the transport facilities in NET will work better (and more easily) than the traditional method of connecting to your local node via AX.25. CONNECTING VIA NET/ROM TRANSPORT To connect to the node whose alias is FOO and whose callsign is W9FOO, you can issue either of the following two commands: netrom connect foo netrom connect w9foo If foo:w9foo is in your NET/ROM routing table, your station will transmit a connect request to the appropriate neighbor used to reach w9foo. NET/ROM transport sessions are very much like those for AX.25. You can use the disconnect, reset, kick, upload, and record commands, and the session command to switch sessions. DISPLAYING THE STATUS OF NET/ROM CONNECTIONS The command netrom status is used to display the status of all NET/ROM connections, which will include those used in keyboard sessions as well as ones attached to the mailbox. For more detailed information on a session, you can use the address of the NET/ROM control block: netrom status <&nrcb> where <&nrcb> is the hex address given in the short form of the command or in the "session" display. NET/ROM TRANSPORT PARAMETERS The NET/ROM transport parameters may be set with the various NET/ROM subcommands. Their meanings are listed below: acktime: This is the ack delay timer, similary to ax25 t2. The default is 3000 ms. choketime: The time to wait before breaking a send choke condition. Choke is the term for NET/ROM flow control. irtt: The initial round trip time guess, used for timer setting. qlimit: The maximum length of the receive queue for chat sessions. This is similar to ax25 window. retries: Maximum retries on connect, disconnect, and data frames. window: Maximum sliding window size, negotiated down at connect time. THE MAILBOX The AX.25 mailbox also accepts NET/ROM connections. The "mbox on" and "mbox off" commands control whether the mailbox is turned on for NET/ROM as well as AX.25, and the "mbox" command displays current mailbox connects of both types. Many people have observed that the AX.25 mailbox requires the user to enter a carriage return to bring up the banner and prompt. This is because of certain defects of that protocol when it is used as the link layer for several different higher level protocols, and is unavoidable. (So stop asking, OK? :-)) The NET/ROM mailbox does not require the carriage return, and will be activated as soon as the incoming connection is completed. WHERE TO GO FOR MORE INFORMATION The paper "Transmission of IP Datagrams over NET/ROM Networks" appeared in the Seventh ARRL Networking Conference papers, available from the ARRL. In it, I describe the more technical details of how the NET/ROM network support works. If you want to learn about NET/ROM, talk your local NET/ROM or TheNET operator out of his or her manual. If you want to learn more, read the source code. That's about it for sources, since the NET/ROM protocols originated in a commercial product. ABOUT THE CODE There has been a great deal of controversy about TheNET, a no-charge NET/ROM clone for TNCs. This is not the place to discuss the truth of the charges leveled by Software 2000 against its authors, but that situation requires me to make the following statement: The NET/ROM transport support in NET.EXE was not taken in any way, shape or form from NET/ROM (whose source I have never seen) or from TheNET. The protocol code is based on protocol 6 from Tanenbaum's excellent book, Computer Networks, as a moderately careful reading of both should show. The source code is freely distributed, so the curious reader should have the opportunity to check this assertion if he or she so desires. The smoothed round trip time calculation, which is not done in "real" NET/ROMs (and should be, by the way -- they'd work a whole lot better) is adapted from that used by KA9Q in the TCP protocol in NET. The dicey business of adapting it to a sliding windows protocol with selective retransmission was done by me, all alone, after my cries for help on the tcp-group mailing list went unanswered :-). I have taken the precaution of copyrighting the NET/ROM code in NET. It may be freely distributed for non-commercial purposes, in whole or in part, and may be used in other software packages such as BBS systems if so desired, so long as the copyright notice is not removed from the source files, and the program in which it is used displays "NET/ROM code copyright 1989 by Dan Frank, W9NK" when it starts up. Any person who wishes to distribute the code, or anything based on the code, for commercial purposes will find me very reasonable, but rather insistent about being compensated for the hours I've spent working on it. ---------------------- Enjoy! Dan Frank, W9NK (dan@cs.wisc.edu, w9nk@w9wi-1 BBS, #MADIP:W9NK)