2/26/92 Preliminary notes -- Using TCP/IP with a ROSE circuit (These are notes that accompany a pre-release NET version for those of you who feel adventuresome. It is K5JB version k05, or later.) This version of NET has a work-around that permits NET to send IP frames over ROSE circuits. Normally, the ROSE system replaces the protocol identifier (PID) in AX.25 information frames with its own when handling packets between switches and does not preserve the PID from the original user's packet's header. In its native datagram mode NET communicates with other NET or NOS stations using un-numbered information frames (UI) but can be made to run in a virtual circuit mode (VC, or connected) if necessary. Although we can initiate VC for our transport mechanism, we can't recognize the IP PID if it isn't there! There are rumors that the next version of ROSE is supposed to cure this problem, but in the mean time I needed to use ROSE, (after all IP is an INTERNET PROTOCOL, eh? Ah, well, bad joke!). Besides, I can control how NET works because I have control of the keyboard! Two things have to be done to use ROSE circuits: 1. Trap incoming IP frames and modify them, 2. Use virtual circuit (VC or Connected) mode on outgoing IP frames. The scheme I used a kludge, but it seems to work OK. First I use a trap that would catch suspected incoming rose information frames and put the IP protocol identifier (PID) back. This trap works good, and when modified for NOS's structures, also works in NOS. To use ROSE for outgoing IP frames, you have to go VC mode. Although you can use the mode command to make an interface use VC for all outgoing traffic, if you do you will forgo the datagram mode which has better performance than VC. (I didn't mean to say that; it slipped out! Actually the protocol performance differences are insignificant when your baselines are really pitiful RF paths.) For outgoing frames, to prevent having to dedicate the async port to the VC mode, I added a command so you can attach a pseudo interface which has most of the attributes of an already attached asynchronous inter- face. You then use that pseudo interface to specify that you want to use virtual circuit. This way, not all transactions that start from that async port need to be VC. (I am not through evaluating the scheme and looking for side effects. If you experience problems caused by the pseudo interface, simply set your async port mode to VC. I have not yet found any fatal problems with the pseudo interface.) NOS has a different way of handling routes for outgoing packets and you can use specify the route mode to be vc for the outgoing AX.25 route you will be using. Though I put the ROSE trap in the version of NOS that I had (PA0GRI v1.7j) I didn't run it. It was tested by N5OWK to my satis- faction. I normally don't use NOS so most of these instructions are for NET. I chose not to do routing the same way in NET as is done in NOS because I am trying to keep NET small as practical. Adding the trap, etc. cost me 488 bytes -- Ouch! First to address received packets... You use the rose add command to create a table of distant IP stations and associated ROSE switches that will be feeding packets to you. This table is used to catch incoming information frames from those stations and put the IP PID back so NET will handle them internally. Syntax for this command is: rose add The distant IP station's call is the AX.25 call, not his host name. Your neighbor ROSE switch's call is its AX.25 call. For an example of calls used, I will describe a test circuit I used. K5JB-10 is my IP station number 1 (host is k5jb), with N0ELS-5 as a neighbor ROSE (address 405771). It will be using async port kp0a which is connected to a Kantronics KPC-4 using logical port a. K5JB-11 is my IP station number 2 (k5jbspook) on another frequency with K5JB-5 as a neighbor ROSE (address 405732). It will use a conventional port named ax0. An example of the rose add command on IP station Number 1 (k5jb) is: rose add k5jb-11 k5jb-5 Where the -11 call is my IP station's call and k5jb-5 is its neighbor rose. If you want to drop a call from the table, the command is: rose drop Because we normally will be able to only create a single return circuit, you should only have one rose table entry for an IP station. This is not a serious limitation because you and the other IP station have to coordinate both ends anyway and set your routes to match. You can have a maximum of 10 IP station/ROSE call pairs in the rose table. This takes care of incoming packets; now to route outgoing packets. Before we describe how to make the port use virtual circuit, we will go through the routing commands. You use two standard NET commands, arp add, and route add. For our purpose, we use a simple form of the arp add command with the syntax: arp add ax25 Using the calls in the example above, the arp add command would be: arp add k5jbspook ax25 k5jb-11 n0els-5 405732 The call sign string is the same as one you would use to make an ax25 connection manually over that ROSE circuit (destination call, neighbor ROSE call, destination ROSE address). For our purpose we use a simple version of the route add command with the syntax: route add And using the example calls, would be: route add k5jbspook kp0a assuming that we are using kp0a as our asynchronous port for this circuit. Thus it takes three command entries for each circuit: rose add, arp add, and route add. (The arp add and route add commands are unchanged for ROSE. You can add all the sophistication you want to them. See the NET manual.) Finally, if you don't use the rose attach command (described next) we need to tell NET to use virtual circuit mode on your async port (ax0 in this example) by using the mode command: mode kp0a v To complete our example, we move to the second IP station (k5jbspook) and use the following to reach k5jb on ROSE: rose add k5jb-10 k5jb-5 arp add k5jb ax25 k5jb-10 k5jb-5 405771 route add k5jb ax0 mode ax0 v Incidentally, if you are using Desqview (you should!) you can use the transfer command to move complicated lines from your autoexec.net file to a running net and avoid typing mistakes. This method also organizes your routing so you don't forget what you were doing. If you don't want to dedicate your async interface to VC (which I didn't) you may want to attach and try the pseudo rose interface, here is how to do it. The command for attaching this pseudo interface is: rose attach If you only have one async interface attached, called ax0, I suggest you simply use the command: rose attach rose ax0 If you are using more than one interface, you might use "ro0", "ro1", etc. If you are using the Kantronics KPC-4 or KAM interface, there is a strict naming convention you must follow. If the interface to be used is kp0a, use the name rosa, ro0a, or whatever, four characters long, ending with the same letter as the end of the kpc port name. In my IP station example above, I would use, rose attach rosa kp0a, (Second port would have been, rose attach rosb kp0b.) This is necessary because of the way the KPC-4 code handles two ports and puts "a" or "b" in that last character's position depending on which logical port received traffic. For various reasons, don't use a name of more than four char- acters long. (DRSI PC*PA driver I implemented in NET uses the same naming convention but this ROSE interface has not been checked against the DRSI driver yet to see if it works. Since we used the DRSI driver as a pattern to handle the dual port KPC-4, it will likely work.) You can add a maximum of 4 pseudo interfaces to 4 corresponding async interfaces. This maximum and the maximum number of IP station/ROSE neighbor pairs can be changed by defines in rose.c. If you use the pseudo rose interface you don't have to use the mode command. A benign disadvantage of doing it the way I did is that if you want to trace incoming data on a port, you need to trace it by its natural interface name and also by its pseudo rose name because incoming packets will appear to come in on either of the interfaces depending on which interface name is serviced first by the interface commutator loop after a packet is received on that port. The pseudo port preceeds the real port in the interface chain but the real port will handle some of the incoming packets if they are received while the pseudo port is working on its data. NET feeds outgoing packets to the ROSE network by looking up the host in the arp table, getting the route from the route table, and since the pseudo rose interface was installed as a VC, initiating an AX.25 connect to the ROSE switch. After some spurious packets from the ROSE switch are read and discarded, you are in business! (These packets are dis- carded by the IP handler because they fail the checksum test and the failures are duly recorded in the statistics displayed by the ip stat command.) If you are using NOS, there is no need for this pseudo interface. The standard outgoing packet routing commands you use are, ax25 route add, and ax25 route mode. Using the same calls as used above, an example command on k5jb-10 to reach k5jb-11 with ROSE would be: ax25 route add k5jb-11 n0els-5 405732 ax25 route mode k5jb-11 vc These notes may not be clear enough to this point because the first two stations that tried this scheme failed because they didn't coordinate what they were doing with the target stations on the other ends of a ROSE circuit. Both ends have to set up tables and routes to match each other. Perhaps someday we will be able to drag a computer out of a box, connect it to a radio, pop up on a network, and have it work without following any rules -- but not yet! Coordinate what you want to do with your buddy and then have at it! In summary: 1. Decide what you want to do 2. Get someone else to agree (use the AX.25 mailbox to pass messages) 3. Use the rose add command 4. Use the arp add command 5. Use the route add command 6. Either use the mode command or the rose attach command, or if using NOS, use the ax25 route add and ax25 route mode commands. 7. Get the other person to set his/her station to correspond. 8. Ping the other station. Watch for the return. 9. Do it again, it won't take so long for a return this time. Now you won't have to use that AX.25 mailbox anymore to send messages to your buddy. Sorry about the kludge, but I had to do something! If all the ROSE switches suddenly start passing the PID byte, we can forget about this. On the other hand, how does TEXNET handle IP frames? BTW, Look at the users list on your neighbor switch after you establish a session. Holy Cow! It says it doesn't know what the 0xcc PID is, heh! I bet it really does! Enjoy! Joe, K5JB