INP support within JNOS 2.0i ============================ This is only available for linux, via my RSYNC server at this time. The latest INP code changes were done mid October 9, 2011. This document was last edited mid October 9, 2011. Code Changes / Technical Notes ------------------------------ 09Oct2011 - Fixed another typo, that should be it - please update code ! Using AXALEN instead of AXBUF to declare a string var passed to the pax25 () function can messed up the nodes display and even crash JNOS when users enter the 'nodes' command at BBS prompt. 30Sep2011 - Fixed a bad mistake that I think has been there since early on. The alias was not being parsed from incoming RIF frames when netrom debugging was switched off, contributing to an already excessive number of '##TEMP' entries. If netrom debug was on, you would never have noticed this problem. Also changed the netrom debugging (in nrcmd.c) to just count the number of routeless nodes, rather then displaying (lots of) them. 22Sep2011 - Still seeing too many '##TEMP' entries, it turns out that the 'obsolescence count' mechanism was the culprit, it deletes a node if no routes exist for the node, which goes against the new philosophy talked about on 13Sep2011. I have modified the code to now retain node entries if INP is active. Added some checks. Any temporary alias values, as well as the 'NOCALL' node callsign, will now be rejected if seen coming in on any RIF frame or netrom broadcast. The same rule applies to any netrom broadcasts initiated by JNOS - don't send them out. The current code will actually reject ANY alias that starts with the pound '#' character. IF you don't like that, then undefine the IGNORE_POUND_TYPE_ALIAS directive in the 'newinp.c' file. 13Sep2011 - I am seeing excessive '##TEMP' entries when listing nodes. The issue here is that the ALIAS only comes by every so often within the RIF frame. The only way for me to preserve the ALIAS is to always add a new node regardless of it's quality, and to never delete a node (keeping it preserves the ALIAS call). No more use of the 'nr_routedrop' or the 'nr_routedrop_postread' functions (which take out everything they can). I now use a new function 'nr_unbind' to simply remove any bindings (routes). The idea of the new method is to always keep a node, and simply add, update, or delete the bindings. This means that it will now be possible for *routeless* nodes to exist in the nrroute table, so if you enter the command 'n ', you might now get a message like 'no route(s)', instead of 'no such node'. Currently the 'n' (nodes) command will NOT display *routeless* nodes. In a way this is less work for JNOS, and routing updates should now be technically faster. Think of it as node buffering. Just because a node has no more routes via any neighbours, does not mean it won't have any routes a few minutes later. So why bother deleting it from the nrroute table ? Exactly ! Consequently, the number of '##TEMP' entries is now very low. If you have 'netrom debug on', don't be alarmed by the number of *routeless* nodes you might see in the jnos log when you run the 'n' (nodes) command. It can take time for these *routeless* nodes to clear up. At worse, the 'obsolescence count' mechanism will deal with these when the 'netrom obso' timer expires. 08Sep2011 - Download the latest changes if you have anything older. I've fixed some serious alias problems, improper routing of l3rtt frames between immediate neighbour nodes, and accuracy of the round trip time values of our immediate neighbours. Code changes / technical details - now kept at the END of this file. History (Introduction) ---------------------- Between 2005 and 2006 I tried to add INP support to JNOS 2.0d, based on ideas and code contained in the linux version of INP3 by PE1RXQ. Despite advertising this and believing I was making progress, I actually failed miserably in my attempt, and the project was shelved for a few years. In August of 2011, Gustavo (I0OJJ) pushed me to get it working again, so for one solid week (August 21 to end of August) when my family was away, I devoted a considerable amount of my time to come up with the beginnings of a new working implementation of INP for JNOS 2.0 (linux only). The first week of September was not much different, alot of time spent to iron out bugs and redesign a few things, but the end result is a good preliminary version of a 'read only' implementation of INP for JNOS systems. Capabilities and features as of September 8, 2011 ------------------------------------------------- 1. JNOS will send regular L3RTT queries at 5 minute intervals to any netrom neighbours it knows about. Those neighbours supporting INP will reflect the query back at us, allowing us to calculate a round trip time for the neighbour and subsequently update the quality, hops, and round trip time for all routes to nodes going through that particular neighbour. 2. JNOS will respond to any L3RTT queries it receives from INP neighbours by doing the same - reflecting the query back at them, allowing them to calculate and update routes and similar information on their side. 3. JNOS will process incoming RIF frames from INP neighbours, and update, add, or delete entries from our netrom node tables, based on quality values calculated from the information received in the RIF frames. JNOS will now track the 'number of hops' and 'trip time' for all routes to nodes going through any INP enabled neighbour, so each time new info comes in, JNOS can calculate new quality values and decide if routes are to be updated, added, or dropped from our netrom node tables. The TT of an immediate neighbour node is actually calculated using the response time of an l3rtt query we send to the neighbour node. I ignore the TT of immediate neighbour nodes received in any incoming RIF frames, and would rather use the calculated value (the INP specification says to do it that way anyways). Note : corrupt alias values are ignored, and routes (bindings) with too low a quality are deleted if they exist in our node tables. So it is NOT uncommon to see constant changes to numbers of nodes. 4. This release of JNOS does NOT transmit RIF frames to neighbours, and their is no provision for so called 'negative node information'. That stuff will be dealt with in a subsequent release. That's why I refer to this preliminary version as a 'Read Only' implementation. 5. I am already playing around with routing by 'lowest TT' instead of quality. It's very interesting, and not difficult to do. If you look for the define 'USE_TT_ROUTING' in the nr3.c module, you can see it is quite easy to implement. It is currently undefined, because it will always favor INP routes (only INP routes use TT values). I want to experiment with *smart* routing algorithms that can look at both quality and tt info and make a decent routing decision. That of course is still in the works, stay tuned. Command Changes and Additions ----------------------------- 1. The result of the 'nr' command at the BBS prompt or the 'netrom neigh' command on the JNOS console (F10 Screen) has changed a bit. Where before the contents of the Obsolescence column was just that, I have added the type of route (R for recorded, B for broadcast, P for permanent) along side of it (separated by a slash character). The 'Irtt' Column has been renamed to '(I)rtt', since both INP and BPQ routes can display RTT type numbers. Lastly I have added (---) and (INP) to the neighbour type, just like if a neighbour is using bpq routing, you will see (BPQ) beside it. The (---) means we received a reply to a L3RTT query we sent earlier to an INP capable neighbour. It will stay that way, until the neighbour sends our system a RIF message, at which point it will change to (INP), which is used to indicate a system running in *full* INP mode. Here is an example of the new format : Neighbour Port Qual Obs Dest Tries Retries Perc (I)rtt BBGATE:AA6HF-4 cal 250 6/B 64 54 0 100 % STECAT:VE2PKT-4 (INP) que 249 5/B 83 221 0 100 % 104 Here is an example of the format from previous versions of JNOS 2.0 : Neighbour Port Qual Obs Dest Tries Retries Perc Irtt ONA105:VE3ZDA-7 ont 230 6 1 0 1 0 % CMHNET:KB8UVN-4 (BPQ) oh 230 6 64 1587 48 97 % 135463032 HGRNOD:VK6HGR-15 aus 230 6 2 0 0 0 % QUAKER:N6ROE-3 (BPQ) sca 230 6 145 58 0 100 % 135462957 NET105:VE1FYI-7 fyi 230 6 78 417 32 92 % 2. The result of a 'n ' command at the BBS prompt or 'netrom route info ' command on the JNOS console (F10 Screen) has also changed a bit. I have again added the (---) and (INP) neighbour types like I did for 'nr', however only for the Neighbour column (it only applies to neighbour, not to Node for INP routing). I have removed the 'Type' column, grouping the Type with Obsolescence like I did with the 'nr' command (to make space), and the 'Irtt' column has been renamed to '(I)rtt', same reason as for the 'nr' command. If a neighbour is INP capable, then the number of Hops and rtt to the Node (via the neighbour) is shown, similar to how BPQ uses the Hops and Irtt columns. I had to make space since the line was bleeding over the next line for previous versions of JNOS 2.0 if BPQ or INP were in use. It looks alot better now I think. Here is an example of the new format : Node Neighbour Port Qual Obs Usage Hops (I)rtt XAPE:PI1APE STECAT:VE2PKT-4 (INP) que 246 2/B 23 3 161 Here is an example of the format from previous versions of JNOS 2.0 : Node Neighbour Port Qual Obs Type Usage Hops Irtt XAPE:PI1APE RPAGW:VK3RPA-3 rpa 199 6 B 0 DSNGW:VK1DSN dsn 192 4 B 0 LPGATE:WL7LP-1 ak 184 5 B 0 ALWGW:WA7V-8 wa 199 6 B 0 3. A new 'start inp' command (from jnos console or from within autoexec.nos) has been created to transmit (at 5 min intervals) L3RTT queries to any of our neighbours. Any INP capable neighbours will reflect these back to us, at which point we can calculate RTT to that neighbour, and recalculate the quality for all node routes via that neighbour. Compiler Notes -------------- 1. To include the new INP support into your JNOS compile, you need to first edit your config.h file, and include the following entry : #define INP2011 The default config.h file (config.h.default) already has it included. Note : The original INP3 definition is gone, forget about it completely. 2. Extra variables have been added to the netrom memory structures, so if you have not done so already, do a mass compile. In other words : make clean make Tracing and Crash Situations ---------------------------- 1. For older versions of JNOS (even without INP compiled in), if you traced an interface that had active INP RIF traffic, there was a good chance it would crash. The trace code was buggy for any INP related data, so I have disabled any INP specific trace code for now, until I rewrite it later. 2. Use 'netrom debug on' to get a really good idea of what is going on with regard to the INP and L3RTT traffic and how JNOS processes it so far. -------- (C)opyright 2005-2011 by Maiko Langelaar / VE4KLM