home *** CD-ROM | disk | FTP | other *** search
/ HAM Radio 3 / hamradioversion3.0examsandprograms1992.iso / tcp / nosnrom / netrom.doc
Text File  |  1991-04-20  |  12KB  |  235 lines
  1. HOW TO USE THE NET/ROM(r) SUPPORT IN TCP/IP
  2. by Dan Frank W9NK
  3.  
  4.    We'll work from the bottom up in describing the facilities added
  5. for the net/rom version of net.  It appeared that for some applications,
  6. it might be worthwhile to be able to have a callsign per interface.
  7. So far, that has only been done for the hapn and kiss attach code,
  8. but the extension is obvious to the eagle and pc100 drivers.  Basically,
  9. if you give an extra argument at the end of the attach line, that argument
  10. will be taken as the callsign for that interface, overriding ax25 mycall.
  11. mycall is still functional, and if you want to use just one callsign for
  12. all your interfaces, just ignore the new feature.
  13.  
  14.    No physical interface is completely dedicated to net/rom, which is as
  15. it should be.  You attach all your AX.25 interfaces, of whatever sort.
  16. Then you attach the net/rom pseudo-interface ("attach netrom").  Then
  17. you identify to the net/rom software those interfaces you want to allow
  18. it to use, with the "netrom interface" command.  The format of this
  19. command is:
  20.  
  21.         netrom interface ax0 #ipnode 192
  22.  
  23. The first argument is the name of the previously attached interface you
  24. want to use.  The second argument is the alias of your node, to be used in
  25. your routing broadcasts.  The alias is never used for anything else (as
  26. you will see!).  The last number is the net/rom quality figure.  This is
  27. used in computing the route qualities; it represents the contribution of
  28. this interface to the overall computation.  For a 1200 baud half-duplex
  29. connection, 192 is the right number.  
  30.  
  31.    You need a netrom interface command for every interface you're going
  32. to use with net/rom.
  33.  
  34.    Once you have set up your interfaces, you need to set some timers.
  35. There are two:  the nodes broadcast interval timer, and the obsolescence
  36. timer.  These are set in seconds, like the smtp timer.  They are usually
  37. set to an hour.  You can set them to something different, if you want.
  38. If your local net/rom nodes broadcast every hour, but you want to do so
  39. every ten minutes, you can say:
  40.  
  41.         netrom nodetimer 600
  42.         netrom obsotimer 3600
  43.  
  44. Every time the obsotimer kicks, the obsolescence counts for all non-permanent
  45. entries are decremented by one.  When the count for an entry falls below
  46. five, it is no longer broadcast.  When it falls to 0, it is removed.  The
  47. count is initialized at 6.  These will eventually be settable parameters;
  48. you can adjust them now by changing the initializers for the variables
  49. in the source file.
  50.  
  51.    When you first come on the air, you can send out nodes broadcasts to
  52. tell the local nodes that you are available.  Use the command:
  53.  
  54.         netrom bcnodes ax0
  55.  
  56. where ax0 is the interface on which you want to send the broadcast.  Do
  57. this for every interface on which you want to do this.
  58.  
  59.    Sometimes you can hear broadcasts from nodes that can't hear you.  If
  60. your routing table gets filled with these unusable routes, your node will
  61. grind to a halt.  The solution to this is node broadcast filtering, via
  62. the netrom nodefilter command.  There is a filter list, which contains
  63. a list of callsigns and interfaces.  Then there is a filter mode, which
  64. indicates what to do with the list.
  65.  
  66.    If the filter mode is "none", no filtering is done.  If it is "accept",
  67. then only broadcasts from the indicated stations on the indicated 
  68. interfaces are accepted.  If it is "reject", then all broadcasts 
  69. except those from the listed stations on the listed interfaces are
  70. accepted.
  71.  
  72.    Because the net/rom code cannot at this time recognize unusable
  73. routes and try alternates, I strongly recommend use of the filter
  74. command to restrict broadcast acceptance to those nodes which you
  75. know you can reach.
  76.  
  77.    The last category of net/rom commands are those used for maintaining
  78. the routing table.  They fall under the "netrom route" subcommand.
  79. "netrom add" adds a permanent entry to the routing table.  Its format
  80. is:
  81.  
  82.         netrom route add #foo w9foo ax0 192 w9rly
  83.  
  84. This command adds an entry for w9foo, whose alias is #foo, route
  85. quality 192, via w9rly on interface ax0.  Let's talk about what this
  86. means.  w9foo is the *destination* node, the one to whom you want 
  87. the packets routed by the net/rom network.  w9rly is your *neighbor*,
  88. the net/rom node to which you pass the packet to be forwarded.  Since
  89. w9rly may appear on more than one interface (the callsign may be used
  90. by more than one net/rom node on different bands), we specify that 
  91. we are to use ax0 to send the packet.
  92.  
  93.    With net/rom, like IP, we don't know exactly what route a packet
  94. will take to its destination.  We only know the name of a neighbor
  95. which has indicated a willingness to forward that packet (of course,
  96. the neighbor may be the destination itself, but that's unlikely in
  97. our application).  Net/rom sends the packet to the neighbor, with a
  98. network header specifying our callsign and that of the ultimate
  99. destination (in this case w9foo).
  100.  
  101.    We can use the netrom route add command to establish a digipeater
  102. path to the neighbor.  For example:
  103.  
  104.         netrom route add #foo w9foo ax0 192 w9rly wd9igi
  105.  
  106. This will cause us to use wd9igi as a digipeater in establishing our
  107. connection to the net/rom node w9rly.
  108.  
  109.    What if you have a net/rom node or nodes, and you'd like to attach
  110. them to your computer via their serial interfaces, and use net as a
  111. packet switch?  It's very easy:  you have to attach those interfaces,
  112. using the "attach asy" command, but specifying type "nrs" instead of
  113. "slip" or "kiss".  "nrs" is the net/rom serial framing protocol, which
  114. is like KISS, but uses different framing characters and has an 8-bit
  115. checksum.
  116.  
  117.    When you attach an nrs interface, it can be used for passing IP
  118. datagrams or AX.25 frames over serial lines or modems.  To use it
  119. for net/rom, you have to identify it to the netrom code just like
  120. any other interface, with the "netrom interface" command.
  121.  
  122.    Now you know all the commands, but how do we actually use net/rom
  123. for IP communications?  This takes two steps:
  124.  
  125.    Step one:  update the routing table.  In all likelihood, you will
  126. use net/rom to gateway two IP subnets.  So, you'll probably want to
  127. identify a station on each end as a gateway.  Let's say we're on the
  128. Milwaukee subnet, and we want to talk to someone in Madison.  If
  129. we're not the gateway, we just have a routing table entry like this:
  130.  
  131.         route add [44.92.0.0]/24 ax0 wg9ate-pc.ampr
  132.  
  133. This specifies that wg9ate should get all packets for the 44.92.0.x
  134. subnet via interface ax0.
  135.  
  136.    Wg9ate has this routing table entry:
  137.  
  138.         route add [44.92.0.0]/24 netrom w9mad-pc.ampr
  139.  
  140. (presuming that w9mad is the Madison gateway).  Now, when the IP layer
  141. at wg9ate gets datagrams for Madison, it knows that they have to go via
  142. net/rom to w9mad.  Notice that we don't specify a "real" interface,
  143. like ax1 or nr0, in the route entry.  The net/rom network layer will
  144. pick the right interface based on its net/rom routing tables.
  145.  
  146.    We're not done yet, though.  w9mad-pc.ampr is not an ax.25
  147. callsign.  The net/rom send routine called by the IP layer needs
  148. to map from the IP address to an ax.25 address.  It does this via
  149. a manually added arp entry:
  150.  
  151.         arp add w9mad-pc.ampr netrom w9mad
  152.  
  153. [We kind of fudged by using the arp table for this purpose, since
  154. there is no way to do automatic address resolution for net/rom,
  155. and arp messages are never sent or received for net/rom nodes.
  156. However, the arp table does contain precisely what we have here:
  157. mappings from IP addresses to callsigns, and it saved a lot of
  158. code to do it this way.]
  159.  
  160. Notice also that no digipeaters are ever specified in the arp entry
  161. for a net/rom node.  Also, the callsign to which we are mapping
  162. is the final destination of the packet, not the non-destination
  163. neighbor.  That neighbor will be picked based on the net/rom 
  164. routing tables.
  165.  
  166.    So, as a summary, let's look at what happens to a packet that
  167. reaches the IP layer on wg9ate, destined for Madison.  The IP
  168. routing code looks the destination IP address up in the table,
  169. and discovers that it should go via net/rom to w9mad-pc.ampr.
  170. So, it passes the packet to the net/rom send routine.  That
  171. routine uses the arp table to translate w9mad-pc's IP address
  172. to the callsign "w9mad".  Then it passes the packet to the
  173. net/rom routing code.  That code checks to see if the destination
  174. callsign (w9mad) is the same as that of any of its assigned
  175. net/rom interfaces.  Since it isn't, it puts a network layer
  176. header (a.k.a. net/rom level 3 header) on it, and looks for
  177. w9mad in its routing tables.  Presumably, it finds an appropriate
  178. neighbor for the packet, and sends in out via ax.25.  The net/rom
  179. network does the job of actually getting the packet to its 
  180. destination.
  181.  
  182.    At w9mad, the packet's protocol ID causes it to be sent to
  183. the same net/rom routing code that handled the outgoing packet
  184. from wg9ate (running on a different computer, of course).  Now
  185. the destination callsign matches, so the net/rom network layer
  186. header is stripped off, and packet is passed up to the IP layer.
  187. (Net/rom network headers don't have a protocol ID byte, so 
  188. we just hope for the best.  If a net/rom node addresses a
  189. net/rom transport layer packet to us, it is likely to be dropped
  190. by IP for any of a number of reasons.)
  191.  
  192. -------------------------------------------------------------------
  193.  
  194. Some notes, added November 1988:
  195.  
  196.         1) As of version 871225.33 (alpha w9nk.1), the format of IP
  197.            datagrams in net/rom network packets has been changed.
  198.            This was for several purposes, including to eliminate
  199.            the bug in tracing that caused net/rom - ip packets to
  200.            appear garbled after the IP datagram sequence number 
  201.            field incremented beyond 255.
  202.  
  203.         2) As of version 871225.33 (alpha w9nk.2), the default mode
  204.            for routing broadcasts is *not* to send the contents of
  205.            the routing table, but instead to just broadcast the
  206.            callsign and alias of the station.  NET/ROM routing is
  207.            fragile enough without our help.  If you need to make
  208.            routing broadcasts, because you are really contributing
  209.            some useful routes to the network, "netrom verbose yes"
  210.            will turn on full broadcasts.
  211.  
  212.         3) There have been some complaints that if station A is
  213.            making NODES broadcasts picked up by his local net/rom
  214.            B, and station C connects to B and then asks B to connect
  215.            to A, that the connection is not successful.  This is
  216.            because B thinks that A is a net/rom, and tries to open
  217.            a transport connection to A, which is not supported.
  218.            As of late versions of NET, we now explicitly reject
  219.            such attempted connections, rather than letting them
  220.            time out.  If C wishes to connect to A through B, C
  221.            should connect to B, then issue a connect to A using
  222.            a digipeater.  This will cause B to use AX.25 rather
  223.            than NET/ROM transport.
  224.  
  225.         4) I can not stress enough that "route add" and "netrom route add"
  226.            are two different commands, with different purposes.  In general,
  227.            you only need a "netrom route add" if you need to add a route
  228.            to a net/rom node via a digipeater path.  If you find yourself
  229.            using this command, ask yourself, "Why am I doing this?"  Many
  230.            people do not understand that net/rom does automatic routing
  231.            (well, sort of :-)).
  232.  
  233.    Good luck!
  234.     73, Dan Frank, W9NK
  235.