Release History for NOSaprs - Maiko Langelaar / VE4KLM ====================================================== Release 1.15b8 (complete update kit) ==================================== * September 20, 2003 - Official release, complete update kit, not a patch. * Not much for changes, more just wanted to consolidate all the patches and get a complete update kit available. Also, some time ago, Bob (VE3MCH) had noticed the latest JNOS update kit was missing the AXUDP enhancements which I originally created for the JNOS 111f distribution. I've corrected that, and this latest update kit now includes the AXUDP enhancements. * Added code to make sure that any messages originated from the NOSaprs Message Center do not exceed the APRS standard. If a user enters a line with more than 67 characters, the message will be truncated and sent as such, at the same time displaying a warning to the user. * Added code to make sure that the NOSaprs status and position broadcasts do not exceed the APRS standard. If the total length of the body of the status or position broadcasts exceed 62 characters, then no broadcast will occur, and one should then check the aprs log file (if it is enabled) for the error details. This check was put in just to be sure that the sysops don't accidently put in too excessive an entry for the 'aprs bc rfpos|rfstat|pos|stat ...' NOSaprs commands. Release 1.15b7 (critical patch) =============================== * September 3, 2003 - Critical update to deal with packet truncation issues *** IMPORTANT : You MUST be at release 1.15b6 or later to apply this patch *** * Discovered a FUNDAMENTAL flaw in how I read data from the NOS data buffers, in particular the chain-like MBUF structures. This issue surfaced when AA6HF (Jack) received a complaint from KB7ZVA (Dick) regarding WX packets picked up by NOSaprs, then truncated by NOSaprs before being sent out the APRS internet system. I really have to thank them both for their efforts in helping resolve this problem. It turns out that I was not using the proper method to extract data from the MBUF pointers. The MBUF structures are link listed buffers, meaning you can't just look at the first section. You have to traverse the entire chain to get the complete data received. This is now fixed and working. One would think I should have known better, especially since I've been playing with the NOS code for several years now ... Okay, whatever ... * Added buffer overflow protection to the aprs_processing () function, just to be on the *safe* side. Release 1.15b6 (patch) ====================== * July 9, 2003 - MIC-E conversion issues, and some fixes to APRS email handling. *** IMPORTANT : You MUST be at release 1.15b3 or later to apply this patch *** * The primary purpose of this patch is to deal with the issue of MIC-E conversion. Several users recently stumbled across a situation that had the potential to create *fireworks* :-) Thankfully, a bunch of us were able to work together and come up with a solution, and in the end we all got a bit wiser. APRS email also had a few things that needed fixing (described further down after the MIC-E stuff). * It used to be that when receiving MIC-E encoded packets from RF, an APRS internet gateway would convert the data into a more *human readable* form, before sending it off to the APRS internet system. Apparently this is no longer preferred and in actual fact has caused problems (inconsistent posit reports, etc). I have yet to find any *official* note that supports this new way of doing things, but several of the gurus have essentially *requested* that no more conversions be done, and that APRS internet gateways should now be passing MIC-E packets to the APRS internet system as is, raw and unaltered. This latest patch will now do that. Any MIC-E packets received by the NOSaprs software will be passed to the internet system as is. Further more, I've added yet another aprs subcommand as follows for added flexibility : aprs mice [passthru | ignore | convert] If you don't want to intercept MIC-E packets at all, then 'aprs mice ignore' will do the trick, and none of that stuff will make it to the APRS internet system, nor will it show in the APRS heard table. The 'aprs mice passthru' is the default. IF YOU ARE CONNECTED TO THE APRS INTERNET SYSTEM, THEN LEAVE THIS DEFAULT ALONE !!! If for some reason, you want the MIC-E packets converted to a position string, you still have that choice by using 'aprs mice convert'. * THIS HAS BEEN TESTED with actual live RF data. I've done the tests both with NOSaprs on-line to the APRS internet system, as well as off-line. * IF YOU SUSPECT ANY PROBLEMS WITH YOUR SYSTEM PASSING RAW MIC-E to the APRS internet system, at least now you can switch it off immediately without the need to recompile or shut your station down, or whatever. * The APRS Email fix from the last patch did not work for mail destined outside the NOS BBS. Local mail worked okay. Anyways, I have fixed the problem, and tested it to my satisfaction. Also, some cosmetics have been done (it looks good), and the NOS logs now show some useful and important information about the mail exchange. Release 1.15b5 (patch) ====================== * June 24, 2003 - fixed a few minor issues, and some new features and notes *** IMPORTANT : You MUST be at release 1.15b3 or later to apply this patch *** * BIG CHANGE 1 - please update your autoexec.nos !!! First of all, I hope this one does not annoy too many of you. It's just an idea, an experiment of sorts. Perhaps I've already spent more time on it then necessary. If you really DONT like this, please let me know, and I'll stick with what I had before ... The 'aprs email xxxxxx' command has been RENAMED to 'aprs contact M xxxxxx'. Note the addition of an additional parameter before the data (xxxxxx). where M is a flag that denotes how the data is to appear on the 14501 web page generated by NOSaprs. M = t, means the data will show on the 14501 webpage as PLAIN text. M = m, means the data will show as a 'mailto' link (which is what the previous version of NOSaprs did in the code. M = h, means the data will show as a standard 'html' link. WHY ? I wanted to give the sysop the option of specifying how they wanted to be contacted. SPAM is a very serious issue. The 'mailto' link is a wonderful way to let your viewers get a hold of you, BUT unfortunately it's being abused, so if you DON'T want to have a 'mailto' link, I've given a couple of options. Examples : aprs contact t "maiko AT langelaar DOT net" OR aprs contact m "maiko@langelaar.net" OR aprs contact h "http://www.langelaar.net" IF YOU LEAVE 'aprs contact' out of autoexec.nos (ie, if you don't use it at all), then the contact information displayed on the 14501 page will be set to 'not available'. * BIG CHANGE 2 - please update your autoexec.nos !!! The 'aprs emailmode ...' command has been RENAMED to 'aprs email ...', same parameters, just a command name change, nothing more. * DID YOU KNOW - You can send aprs data to NOSaprs using UDP port 16161, and it will go out the APRS rf port. It's actually been like that for quite some time. I have a simple utility I wrote that lets you do this painlessly. Please visit the following website URL for now : http://www.pcs.mb.ca/~maiko/software/klmudp.html Thanks to Rob, VE7TSI, for this idea, since he wanted to broadcast the status of his IRLP node out the NOSaprs port. Rob uses a script by WA0OJS, which we changed to make use of the KLMUDP utility, instead of echo'ing to the comm port like the original script does. The WA0OJS script changes the APRS Beacon Text based on an IRLP status file. * Commented out the debug code in the aprs digi module. Jack, AA6HF caught this for me, seems if 'aprs flags +digi' was enabled, the status bar and main TNOS log was getting a whole bunch of debug stuff printed to it. * I didn't like the fact that the APRS message center tied up the F10 (main) NOS console when invoked by the sysop. It should have created a new session instead, leaving the console open. I have changed it to do exactly that now. It seems to work fine so far. * Put in some code to protect against buffer overflows in the aprsmail() function. Previously, if a station were to sent APRS email data containing NO spaces, then NOS *could* probably crash if the data was *excessive* ! * The mailuser () function that is used to send the APRS email to the smtp server was being passed a NULL string for the 'from' information. I originally did this on purpose, since all the necessary details were logged in the APRS log anyways. Paul (AE6JN) caught the fact that in the NOS mail.log logfile, the smtp entry does not show who the email has been sent from. This is now fixed. The 'from' info will now show 'callsign (APRS)' of the station that sent the email via APRS. It's not a real email address, but it's enough to ID the sender. * No more distinguishing between TNOS and JNOS anymore. This is just plain and simple NOSaprs now, irregardless of which type of NOS is in use. Functionality is the same. * Added the APRS subcommand, 'status'. Why should the sysop have to 'finger aprsstat' or browse their own 14501 page ? You'd think I would have done this long ago ... * Updated the memory allocation calculations used in generating the 14501 page, fixed a minor bugs, where ALOT more memory was being allocated than was necessary. * Fixed up quite a few of the APRS subcommands to be alot more user friendly. * Now that the APRS message center is in place, I have removed the 'imsg' and 'lmsg' subcommands. One should not need these commands any longer. Also, 'aprs show dup' has been removed, I only used it for development purposes. Release 1.15b4 (patch) ====================== * March 29, 2003 - This is a patch to fix a few problems. * Fixed a bug (thanks Ruben EB5ESX for finding it) where certain position data from the internet was not being gated to RF. Positions with a DTI of '=' were not being gated. That is now fixed, and should work properly ! * More work on the keepalive status messages for APRS clients connecting to the NOSaprs server. This is now done properly, and the proper syntax for the aprs client configuration is FINALLY as follows : aprs client add where the interval is in seconds. Value of 0 disables keepalive messages. * By default, the built-in APRS digipeater is now OFF. The sysop will have to use the command, 'aprs flags +digi', if they wish to turn it on (provided they also have the feature compiled into their NOS). * Fixed a bug in 'aprs server kick' command. It never worked (actually, that's not quite true). It worked if you issued the command as 'aprs client kick'. I had it backwards :-) Release 1.15b3 (beta) ===================== * November 18, 2002 - Official BETA release, complete update, not a patch. * BIG ENHANCEMENT - JNOS and TNOS can now digipeat WIDE and WIDEn-N just like an APRS digipeater. This is experimental, and I expect that some of you may be providing me with feedback. I have tested it with very good results. The code also checks for duplicate packets, so there *should* be no problems with packets bouncing back and forth endlessly between NOS and other digipeaters on frequency, when WIDE or WIDEn-N is involved in the PATH. NOTE : This is standard digipeating - NOT pre-emptive like the DIGI_NED software (not yet anyways) ... A flag was added to the 'aprs flags' command. The flag is 'digi', and lets you shutoff or turn on APRS digipeating on the fly. So if things become a problem, then you can shutoff the feature instantly. For example : aprs flags -digi If you don't want to include support for the WIDE and WIDEn-N digipeating, then undefine APRS_DIGI in the 'aprs.h' header file, or for you DOS users, check the 'bcc.cfg' file instead. * The keepalive status messages (sent to APRS clients that connect to NOSaprs) are no longer hardcoded to meet the requirements of the specific client software being used for that particular connection. Instead, each client is now configured with it's own keepalive interval, using the previously unused 'port' parameter in the 'aprs client ...' subcommand. The 'port' value will now contain the interval (in MILLIseconds) at which keepalive messages are sent to the client. The value 0 disables the use of keepalive messages for a particular client. NOSaprs will terminate connections to remote hosts if nothing is heard from the remote hosts after 10 minutes, so if you have any NOSaprs clients, connfigure those clients with a keepalive interval of 590000 (remember milliseconds), nothing higher. * BUG ALREADY FOUND - After I released this, I discovered a small bug. The 'aprs client' subcommand will not let you specify a 'port' value of 0, so if you don't the KEEPALIVE message sent to a particular client, then just put in a really big number for now. I'll fix this in a patch down the road. As long as you are aware of this, then it's no big deal at this time. My apologies for that oversite. Release 1.15b2 (beta) ===================== * November 4, 2002 - Beta, released as a patch. * I have changed the formatting of the POE (Point Of Entry) so that it follows the 'IGATE,I' format, which seems to have become the *standard of choice* over the past year. As well, the Q construct - which has been recently implemented on the APRS IS - expects this format. This change HAD to be made, to ensure compatibility with the Q system on the whole. * Third party frames gated to RF will now contain less *junk*. I have changed it so that ALL information other than the FROM and TO call are stripped out of the source path header before being sent out RF. In previous releases I included digipeaters up to the '*' character, but until KISS Routing becomes a reality within the APRS IS, there is no point sending out the additional information to RF clients, since the APRS IS can't do anything with that information anyway. This change also HAD to be made, based on the *latest* standard. * The RF and Internet System position broadcasts done by NOSaprs now use '=' as the DTI character, instead of '!' as in previous releases. I changed this because NOSaprs is actually capable of messaging, and has been that way for some time. I simply forgot about it over the past year. This is related to the 'aprs pos|rfpos' stuff. * Another small fix to the 'aprs listen off' problem from before. Release 1.15b (beta) ==================== * October 1, 2002 - Beta, released as a patch. IMPORTANT : The destination call used by NOSaprs for this release is now APZ115. SOooo, if you have an 'ax25 route add APZ112' or similar, then make sure you change it so that you are using APZ115. If you have not figured it out already, I use the Release(Version) number in the APZXXX call. * BIG ENHANCEMENT - NOSaprs can now gate POSITION and STATUS information received from the APRS IS, to RF. The gating is controlled by 2 NEW callsign lists, so that the sysop can control from what source calls and/or call patterns the POSITION and STATUS frames are allowed to be gated to RF for. The command, 'aprs calls ...', has two new subcommands. They are 'stattorf' and 'postorf', as illustrated in the example below : # only gate STATUS frames from LW2DTQ and stations whose callsign # starts with VE4 or VA4 aprs calls stattorf lw2dtq ve4 va4 # only gate POSITION frames from N7VMR, VE3MCH, and from stations # whose callsign starts with VE4 and VA4 aprs calls postorf n7vmr ve3mch ve4 va4 For most applications, I would think the stattorf and postorf lists should be identical, but I've separated the callsign lists for added flexibility if anyone seems to think that it is required. If you don't want any STATUS frames gated, then leave the 'stattorf' list undefined. Same for the POSITION frames. If you don't want POSITION stuff gated to RF, then don't define the 'postorf' callsign list. IMPORTANT : In order for you to be able to broadcast the POSITION and STATUS information to RF, NOSaprs needs to connect to the more active server ports on an APRS IS server, for example port 23, or port 10152. The traditional port 1314 only provides NOSaprs with messaging data, not position and status data. If this new feature does not interest you, then continue to use port 1314 as before. WARNING : By connecting to a more active APRS IS server port, you have the potential to significantly increase the amount of data that your NOSaprs has to process from the APRS IS server. This will naturally increase the CPU load of NOSaprs. Keep that in mind, if your NOS seems to be getting slow for your particular PC or platform. * Made the APRS message center a bit more user friendly, in the sense that the user has a much better idea now whether a particular message receipient is available for messaging or not. In this version, if the 'bconlyifhrd' flag is enabled, and the APRS Message center user tries to specify a recipient that was not heard, then the user will be out of luck. I'm considering adding an override feature in an upcoming release, but for now I'm leaving it this way to make sure other aspects of the software are working properly. If the 'bconlyifhrd' flag is disabled, then the APRS Message center user is simply told the recipient was not heard, and they are allowed to continue to send the message out anyways. * The 'aprs listen off' command should now fully stop all APRS related processes. Previously, the UDP listener would die, but the internet side process (aprsx) would remain running, and attempt to connect to the next APRS server configured, effectively behaving like 'aprs server kick'. This little oversight *should* now be resolved, and work properly. * Found a minor *problem* in the aprs client code. Some memory was not being released properly. Really not that big of a deal, but the amount of *lost* memory could technically have 'added up' if there were *alot* of client connect/disconnect scenarios. Release 1.14b ============== * August 22, 2002 - Now an official release. Release 1.14b ============== * June 25, 2002 - Beta, released as a patch * The *send only* client connections are back. I've revamped the code, and re-thought a few things. First and foremost, blind connects by any APRS TCP/IP clients are no longer allowed. Clients must be configured in advance within the NOSaprs configuration files before this is possible. * A new command is available, 'aprs client ...' command, very similar to the 'aprs server ...' command. For example if you want an APRS client at the IP address 10.1.2.1 to be allowed to connect to NOSaprs, then you need to add an entry like the following to your autoexec.nos : aprs client add 10.1.2.1 14825 This beta version is limited to a maximum of 10 client connections. REMEMBER : port 14825 is currently the ONLY port any APRS client can connect to - it is a *send only* port, by which the client can send us APRS data, and not worry about getting the fire hose of data back. This is ideal for stations that simply want to monitor for APRS traffic or for Weather stations. This is also ideal for those stations that have low speed or low bandwith connections from their client site. * The 14501 HTML status page and the 'finger aprsstat' information will now show client connection information (only if clients are configured). Just like the server list, all clients will be shown. Active (connected) clients are highlighted in Yellow (the same way the single active server is). * Fixed up some cosmetics. * Did some serious work on how I use NOS timers (especially in checking for both client and server inactivity). This should now be much more reliable and stable then it was when I first started the client features. * Restructured a bunch of code in order to minimize duplicate code. Adding the new client configuration commands actually created code that was very similar to that used by the 'aprs server ...' command. They both use almost identical memory structures, so I decided to merge duplicate code segments into common functions that could be used by both the server and client configuration. Release 1.12.2y =============== * Fixed a serious bug that will has the potential to crash NOS if any of the callsign lists (fwdtorf, bantorf, ignorerf) are NOT defined at runtime. If this is the case, and NOSaprs receives a message from the APRS internet system or from RF, then NOS will crash. This has been fixed. This bug has probably been present for a long time, but I suspect it will have affected few people, since most of them will have defined the 'fwdtorf' callsigns for their region. Many thanks to Robin Gilks (G8ECJ) for catching this for me. Release 1.12.2x =============== * The NOSaprs message center that is available from the PBBS prompt has some new functionality. The PBBS user can now exchange messages to APRS users on the local RF frequency. Also by default, NOSaprs will now send messages from the message center out to RF. Before it was always to the APRS internet system. There is a new command, '/f', available in the message center that will allow the PBBS user to toggle where their subsequent messages will be sent (ie, out RF or to the APRS internet system). As mentioned already, the default is now out RF. Messages sent out RF are in 3rd party format for legal reasons. We don't want it looking like the BBS is transmitting packets having the source callsign of other stations. Release 1.12.2 ============== * another subcommand added to the 'aprs flags ...' command. The new subcommand is 'bconlyifhrd'. By default it is turned on. To switch it off, use 'aprs flags -bconlyifhrd'. NOSaprs will now (by default) only gate 3rd party messages from the internet to RF if and only if the recipient of the message has been heard by NOSaprs (ie, if the callsign is in the APRS heard table). Previously, if the message recipient was not heard, then NOSaprs would gate the message out the default RF port ANYWAYS. If you want to continue doing it the *old* way, then simply switch this option off, as explained earlier above. See my other note at the end of this document regarding this feature. * callsign filtering - some powerful filter functions ... The previous 'aprs fwdtorf ...' command has been replaced. A new command called 'aprs calls ...' is now in affect. To upgrade, at minimum you should replace your 'aprs fwdtorf a b c ...' with the following : aprs calls fwdtorf a b c ... The new 'aprs calls ...' command let's you setup callsign lists for a variety of different operations. This BETA has 3 new subcommands for the new 'aprs calls ...' command. The names of the subcommands actually reflect the type of callsign lists - 'fwdtorf', 'bantorf', and 'ignorerf'. The best way to illustrate these filter functions is by example. EXAMPLE ------- I want all 3rd party messages from the internet addressed to recipients that start with callsigns VE4, VA4, VE3, VA3, to be gated to RF. At the same time I do NOT want messages for VE4XXX or VE4BAD to go out RF. You could try the following two commands to deal with this. aprs calls fwdtorf ve4 va4 ve3 va3 aprs calls bantorf ve4xxx ve4bad NOTE : these callsigns are examples, no relationship to actual users. The 'bantorf' could be usefull for filtering out bulletins or other stuff as well. Now, let's suppose we have a couple of stations sending *undesireable* APRS packets on RF and we don't want that stuff to get to the APRS internet system, without having to shutdown the entire IGATE itself. Try this : aprs calls ignorerf ve4xxx ve4yyy The calls will still appear in the APRS heard table (and on the 14501 and finger information pages), but the packets FROM them will NOT get sent out to the APRS internet system. NOTE : the 'fwdtorf' and 'bantorf' lists focus on the message RECIPIENT callsign of 3rd party messages coming from the APRS internet system, while the 'ignorerf' focuses on the SOURCE callsign of frames coming FROM the rf side. I have designed the software so that I can easily add other types of lists for future releases of NOSaprs. If you have ideas, let's hear them. * More on this 'bconlyifhrd' flag ... The filter functions above are in affect regardless of whether or not you have the 'bconlyifhrd' flag turned on or off. The purpose of the 'bconlyifhrd' flag is to minimize the amount of RF activity. I mean, what's the point of broadcasting a message from the internet onto RF if the station has never been heard within the range of the NOSaprs server. Some people will have different preferences of course, so this is purely a choice and not forced on you. Release 1.12.1 ============== * April 28, 2002 * Added a new flag, 'dtiheard', allows sysop to enable or disable tracking of the DTI character in the APRS heard table. The heard table can get quite big if we get the same stations using a whole slew of different DTI values. Quite frankly, there's no point tracking the DTI for general use. I simply added the feature because I wanted an idea of the type of APRS traffic being heard by my particular igate. Others may want to track that kind of information as well. The default setting is ON - to shut it off, use the following command : aprs flags -dtiheard * Added a URL locator parameter which (if configured) will allow people to click on the NOSaprs callsign and other heard callsigns displayed in the 14501 page and link to sites like findu.com or canaprs.net, etc. To configure the URL locator, use the following command, for example : aprs locator "http://map.findu.com/" NOTE : you must specify the trailing slash ! * IF the info port parameter in the 'aprs server add ...' command is passed, and IF it is set to 0, then there will be NO HTML link for that particular server in the 14501 status page. You can do this if there is no known link to the site. That also saves your users from wasting their time clinking on links that will never return anything. * Some code cleanup for the sake of efficiency, etc. * Some cosmetics. Release 1.12 Documentation ========================== * April 4, 2002 - documentation is now uptodate and reflects release 1.12. Release 1.12 ============ * Release March 28, 2002 * I have made it so that by default, the APRS client connect server is not part of the compile. You can put it in if you want by changing the option in aprs.h, but it is still very experimental, and has some minor problems associated with it. I plan on redesigning it as time permits, so keep your eyes open. * Some minor fixes put in, some unnecessary code taken out. * Now devoting some time to upgrading the documentation, since it's falling behind. Release 1.11.3 - xNOSaprs 1.11.3 ================================== * Release February 26, 2002 * This is another STABILITY patch - added kernel calls into the APRS server code, to give the more critical NOS services a fair share of CPU time. * Important note about the APRS client connection (44825) server Some problems have been discovered in the APRS client connection server that I added to xNOSaprs in release 1.11 - The server (start 44825) does work, however it seems to have a bad effect on other xNOS timers. I've had people complain that their node broadcast timers suddently stop working. I've watched the T1 ax25 timer go nuts after several hours on my TNOS box for my RF connectionss. Obviously, the client connection services are still buggy and need some work. Unfortunately, I'm on a business trip for the next 3 weeks, so I will not be able to fix it now. In the meantime, the best solution is to simply NOT run the 44825 service. That's easy to do - just make sure you don't have the 'start 44825' in autoexec.nos. Release 1.11.2 - xNOSaprs 1.11.2 ================================== * Release February 14, 2002 * NEW command - 'aprs server kick' - If for some reason you suspect a problem with the APRS internet system server to which NOSaprs is currently connected to, you can issue the 'aprs server kick' command. This will terminate the current connection, and allow NOSaprs to try the next server in the list. I wish I had this command months ago !!! * Added inactivity checks for stale client connections. If a client connection is inactive for just over an hour, it will now be shut down by NOSaprs. * the 14501 HTML information page now shows a 'Since' column for the server and client connections. This new field displays how much time has elapsed since any traffic was last heard over a connection. * Fixed "outbound data" counters for client connections. * Added support for DOS Compiles, so that my code base is now the same for JNOS (DOS), JNOS (LINUX), and TNOS (LINUX). * A minor cosmetic on the 14501 page. If at any time, the time information is not meaningful, a '-' character will appear in the 'Connected' and 'Since' columns of the server connection section. * Added compile time option (aprs.h) for client connections. Cleaned up the compile time options for the 14501 server. Release 1.11.1 - xNOSaprs 1.11.1 ================================== * Release January 31, 2002 * This is a STABILITY update. I have rewritten the main server loop in the hopes that it will significantly improve the stability of NOSaprs. My beta system has been quite stable, however there are particular situations that older versions of NOSaprs may not deal with very well (for example, high rotation rate of the APRS server list). Also, I never did like the way I wrote the original loop, it was wastefull of system resources to name one reason. * This new release of NOSaprs has CONSIDERABLY less downtime to the APRS internet system. If a server connection is lost or can not be established, then NOSaprs will now almost *immediately* try the next server in the list, and so on. Previous versions had considerable delays between connect attempts. * The dreaded 'aprs timer ...' command is NO MORE !!! Please remove it from your system's autoexec.nos file. Known problems : Stale client connections can occur, filling up the client connection table. The maximum number of client connects is currently hardcoded to 10 clients. I'm still working on this. If you require any help or need more information, feel free to contact me. 73 Maiko / VE4KLM Release 1.11 - xNOSaprs 1.11 ============================== * Release January 7, 2002 * BIG BIG ADDITION - APRS clients like UI-View, etc can now connect to NOSaprs on port 14825 via TCP/IP over the internet or a local LAN, provided you have issued the 'start 44825' in your autoexec.nos file. Yes you saw that right, the server is called 44825, but the port number is actually 14825. This is a special TCP port for those clients who only want to send APRS stuff to the internet system, but not get anything back. This is great for those stations that only monitor APRS activity. This present version is still experimental. It is hardcoded to allow a maximum of only 4 clients connects at any time. You may want to consider implementing TCP access rules for NOS so that not everyone in the world can connect to your system. The HTML (14501) and finger information now shows client connections including the logon user name for those clients, as well as packets and bytes in and out, as is shown for the remote server connection. * IMPORTANT Upgrade information - Use the command below to start the above service. start 44825 * Several cosmetic changes, in particular, please note that I don't use the '*' character anymore in the HTML (14501) page to show which remote server NOSaprs is connected to. The yellow shading of the row should suffice. * An attempt is being made to improve the functions used to validate the DTI, and the data associated with any particular DTI characters. This is ongoing. * IMPORTANT Upgrade information - The aprs commands below no longer exist : aprs debug aprs monitor aprs poe They have been replaced with 'aprs flags ...' instead. For example : aprs debug on - use aprs flags +debug aprs debug off - use aprs flags -debug New flag - allows you to turn on or off the logging of 'bad packets' to the APRS log file, for example : aprs flags +badpackets aprs flags -badpackets If you want to see the state of all the flags, just enter 'aprs flags' without any additional parameters and you'll get something like this : aprs flags -debug -badpackets +poe -monitor * By default, 'debug', 'monitor', and 'badpackets' are OFF (-). The 'poe' also known as the Point Of Entry callsign feature is by default ON (+). * I have successfully tested this latest release using client connections from K0RX (UI-View) and VE5BNC (WINaprs). Thanks Dave and Bruce. I was doing some work with a fellow using APRS+SA, but we never completed our tests (it worked, but the APRS+SA was disconnecting all the time after several minutes, even with the keepalive timer running). * Previous versions of NOSaprs did not allow the APRS telemetry packets through to the APRS internet system. This is fixed now and works. * If you are still puzzled about these notes, send me an email. I'll try to get the documentation updated when I have some free time. Release 10 upgrade - xNOSaprs 1.10.1 ====================================== * Release December 27, 2001 * 14501 Cosmetics * added HTML links for each host server configured in xNOSaprs, so that users viewing the xNOSaprs 14501 page can now click on the host server for any info pages that the remote server may have running. The port (ie, 14501) is also configurable, so that if the remote server has no 14501 page, but has a standard html page, you can configure the link to use port 80 instead. Release 10 - xNOSaprs 1.10 (see important upgrade notes following this section) ================================================================================= * Beta released December 4, 2001 * New EMAIL service for local APRS users. Set the destination call to EMAIL in your APRS client, and send a 1 line message as in the following example : maiko@langelaar.net this is a test message xNOSaprs can be configured to deal with this in 3 ways. It can block ALL such requests and ignore them. Or it can simply forward these requests to the APRS internet system for processing, or it can handle the request within NOS itself. New command : 'aprs emailmode passthru | local | block' The default setting is to have NOS itself process the request, and send the email to the desired user. The request is not forwarded to the APRS internet system. Keep in mind that NOS has built in SMTP services, so this makes perfect sense to do. Note to APRS clients coming in over the RF interface ... Send the message with a msgid !!! NOSaprs will acknowledge it if it was able to forward the email request to the NOS smtp services. I have put in dupe checking so that multiple emails will not happen if ACKs or messages are lost along the RF path. If a msgid is not appended to the end of your message, you will not know if the email request was processed or not. I have not implemented a *delivery notice* type of APRS message from NOSaprs back to the APRS client yet. Right now, I rely on the msgid and ACK system to do this. * More flexible broadcast options. xNOSaprs used to send the same status and position information to both the APRS IS (internet system) and the main RF interface. It did so using a hardcoded interval of 30 minutes. New commands : 'aprs bc stat|rfstat status data' 'aprs bc pos|rfpos position data' 'aprs bc ver|rfver on|off' The APRS IS and the RF broadcasts now have their own separate configurations. For example, you can configure the RF broadcast for every 15 minutes, and the APRS IS broadcast for once every 3 hours if you want. You can configure the RF broadcast to have completely different Status and Position data from the APRS IS broadcast if you want that. And lastly, there is an option that lets you switch on/off the insertion of the NOSaprs version at the beginning of the Status broadcast (default is on). Lastly, you don't have to define Status and/or Position information. If the info is not defined, then it simply is not broadcast. * Fixed a problem with the 14501 page when viewed from an Internet Exploder browser. It seems that the newer browsers use persistent connections. Previously anyone using IE to view the 14501 page was noticing that IE was not *stopping* after the page loaded. * Fixed a problem where in some cases, the text based aprsstat information was being loaded onto the end of the HTML code, resulting in a display that was not the most pretty to look at. * Fixed up a few minor internal bugs or issues. Release 10 - xNOSaprs 1.10 (IMPORTANT Upgrade Notes) ====================================================== * The 'aprs bcpos' and 'aprs bcstat' commands are no more. You will need to modify your existing autoexec.nos - see the example illustration below : suppose you have the following configured in your autoexec.nos : # # OLD (tnos 1.09 and earlier) remember that broadcasts are # hardcoded to every 30 minutes # aprs bcstat "IGATE - 441.050 Mhz - ve4klm@ve4umr.ampr.org" aprs bcpos "4948.53NI09707.95W&" it MUST be replaced with something similar to the following : # # NEW (tnos 1.10) # aprs bc stat "IGATE - 441.050 Mhz - ve4klm@ve4umr.ampr.org" aprs bc pos "4948.53NI09707.95W&" # lets send stat and pos to the APRS IS once every hour aprs bc timer 60 # lets send stat and pos to RF every 15 minutes aprs bc rftimer 15 Set the timers for whatever you need. Note the 'rfstat' and 'rfpos' are not defined in this example. That's perfectly okay. The RF broadcast data will simply be the same as that used by the APRS IS broadcasts (no point putting duplicate information into the autoexec.nos file). Release 9 - xNOSaprs 1.09 =========================== * Release October 26, 2001 * The APRS Server now has it's own log file. APRS related events and information are now kept out of the main TNOS log. This was done at the request of several people and rightfully so. No point filling up the main log with junk :-) It was just convenient at the time. Add the following command into your autoexec.nos : aprs log /nos/spool/log/aprslog.txt Make sure it comes before ANY other 'aprs' type command. Also, APRS logging will no longer interfere with the STATLINE on the TNOS console. * xNOSaprs now supports the routing of messages coming from the APRS internet system out the interface that the station was last heard on, instead of through the default APRS interface. Of course if the station was not heard at all, the message simply gets gated out the default APRS interface as before. POWERFUL : That means that users on ANY (yes, ANY) ax25 interface should now be able to do messaging with other stations via the APRS internet system. Sorry, but local port to local port is not supported (yet ??? perhaps). THIS IS VERY EXPERIMENTAL !!! I have tested it and it seems to work, but this could do with more testing out in the field, so if anyone can try it out, that would be great. Please report your results or any problems to me if you can. * A simple, but *useful* APRS Message Center is now available to both the PBBS user and the sysop (from the TNOS console). I've tried to give it a *converse* type of look. This is a start, the commands are very limited, etc. This release requires that the PBBS user must have TELNET permission in order to use it. THIS TOO IS EXPERIMENTAL !!! Don't expect too much. This effectively replaces the use of the 'aprs imsg' command, which was very awkward to use. To activate the message center, just use the command 'aprsc' from either the PBBS prompt or the TNOS console. Some restrictions apply - it can not be run from within SYSOP mode, and PBBS users that have the same callsign as the TNOSaprs server itself are not allowed to use it from the PBBS, they must use it from the TNOS console instead (due to technical reasons). The message center only works with stations reachable through the APRS internet system at this time. You can't use it to talk with stations on the local RF ports. Also, any incoming messages that have a message id are only acked once, unlike the various Windows clients out there that can send multiple acks. * xNOSaprs now forcefully creates a subdirectory called 'aprs' under the main NOS spool area (ie, /nos/spool/aprs). APRS messages are now logged to the 'aprs.txt' file under this new subdirectory. In previous versions, messages were being put in the MailSpool area, which had the potential to conflict with general mailbox use. Note, ALL APRS Message Center messages are currently logged to this file. * Fixed up the code that sends an ack message back for incoming messages that have a message id appended. I didn't realize that the message id can contain both numbers and/or letters. As a result, previous versions of xNOSaprs did not format a proper ack message for reply, if the incoming message id was non-numeric. That is now fixed. * Leading zeros are no longer placed in any message ids generated by xNOSaprs. Release 8 Upgrade - xNOSaprs 1.08.03 ==================================== * Release September 28, 2001 * This is a maintenance release (ie, bug fixes). It includes an addition to the config.h header file (sorry, I had to do that). Usually when this happens the 'make' winds up compiling everthing again, not necessary for the particular changes I made, but I have to be consistent with where I place function prototypes. My apologies in advance. * From time to time, there is ALOT of garbage in the APRS internet stream, some of which can (and has) crashed my TNOSaprs development system. I am sure that other NOSaprs users are going through the same thing. I have put in stronger data integrity checks, which should minimize these incidents. * The 'aprs 14501 [on|off]' command has been scrapped. The mechanism that was originally implemented was flawed, and had a few major problems associated with it. Any attempt to run 'aprs 14501 on' from the TNOS console rendered the console inaccessible (hung). Any attempt to do the same from the sysop mode kicked the user from sysop, terminated the connection, but left the user still logged on as a background process. Also, it seems that DNS lookups were not working once the 14501 server was started. This is now all fixed !!! * The new (and proper) command to start the 14501 server, is 'start 14501'. The command to stop the server is 'stop 14501'. This is the way I should have done it in the first place :-) Release 8 Upgrade - xNOSaprs 1.08.02 ==================================== * Release September 11, 2001 * No new features, however I had to bump up the revision number because of the fact that I now use the SAME code for both TNOSaprs and JNOSaprs releases. Doing so will save me alot of time and effort. Now if I want to make the latest TNOSaprs available for the JNOS environment, all I have to do is take the TNOSaprs code, define -DJNOSAPRS in a makefile, and voila, JNOSaprs will be compiled. Previously, each time I released a new version of TNOSaprs, I would take the code into a fresh copy of the JNOS111f release, and patch it till it compiled. No more. Now, I can finally release TNOSaprs and JNOSaprs simultaneously, and they will both contain almost the exact same features. Release 8 Upgrade - TNOSaprs 1.08.01 ==================================== * Release September 6, 2001 * TNOSaprs now injects a Point Of Entry (POE) callsign into the source path header when sending APRS frames to the APRS internet system. The purpose of the POE is to identify the IGATE that injected the packet into the system. The POE callsign has the format 'CALL-0n', where n is the modulus of the logon callsign SSID, having values from 0 to 9. To distinguish the call as a POE call, there will always be a LEADING ZERO on the SSID. This technique is still not 100 percent agreed upon by some of the major players in the APRS environment, but most agree it is 100 percent backwards compatible with the existing system, so it will work for now. * The sysop can switch off the injection of the POE at any time by using the new TNOSaprs command, 'aprs poe off'. By default it is always on. * The repeated flag (*) in the source path header is now properly set and now accurately reflects the true RF path that was used. Previous versions of TNOSaprs were assuming that it was always the last digi in the path that should have the '*' set. I now check the REPEATED bit of each digi in the list (which is what I should have done from the beginning) to construct the proper information. * Fixed a bug. Found a problem where if the 14501 page is accessed, the logon callsign suddenly reverts back to lower case. This could seriously affect a variety of other functions throughout TNOSaprs, that depend on the logon call variable being in upper case. * The REPEATED bit is now shown in the Path information section of the 14501 and finger aprsstat information pages. If a digipeater in the path has repeated the packet, then a '*' character will be placed beside the callsign of that digipeater. * Cosmetics again, I decided I don't like the little help line at the very end of the 14501 screen. Further more, now that I use the '*' character to indicate the REPEATED bit on a digi in the Path, the former screen layout will just add to the confusion. Release 8 - TNOSaprs 1.08 ========================= * Release August 31, 2001 * Added a couple of more fields to the APRS Traffic Heard section. 1) If a station is heard on a port (interface) other than the configured APRS port, then that port's name will be indicated. 2) If the APRS frame from any station heard includes any digipeaters, then the digipeaters will be indicated for that station. * Some code restructuring required to accomodate the above. Cleaned up some areas of duplicate code, moved the opt-out code from aprssrv.c into the aprs.c section (less overhead, and now allows me to track opt-out's in the statistics, if I want to in the future). * Some cosmetics on the aprsstat and 14501 information pages. Fixed up the memory management for the 14501 server. Corrected a few 'minor' bugs if the APRS heard table is not configured, or if no IGATE servers are in the list. That all works properly now. * MIC-E and 14501 are now compile time options if desired. This is configured in the aprs.h header file. The release has both of them turned on. Whether the options are included or not actually does not affect the overall size of tnos significantly. * Fixed a bug. Sysop can now finally set the size of the APRS heard table to zero on the fly. Before this release, this was not possible, because the parser considered 0 to be an invalid parameter. This is now fixed. * Added another saftey check in the message_handler, to make sure a message recipient callsign was no longer than 9 characters in length as per the APRS specification. I caught this when someone had misconfigured a beacon and TNOSaprs was crashing each time the beacon had come in. * Added code so that TNOSaprs inserts a POE (point of entry) callsign into the packet stream before it injects it into the internet APRS system, but decided at the last minute to hold off on this. It's commented out for now. I've been haggling this over with several of the APRS people, but as of today, I still do not see a light at the end of the tunnel, so it will stay commented out. Release 7 - TNOSaprs 1.07 ========================= * Release August 15, 2001 * Added an APRSD style '14501' HTML Status Page. * If a standard telnet is used instead of a browser on port 14501, then TNOSaprs will simply dump the regular aprsstat information to the client. * Added two new TNOSaprs commands, 'aprs 14501', and 'aprs email'. * Added inactivity timer so that if any of our IGATE connections suddenly *appear dead*, we will terminate them and try the next server in the list. * Added Bytes In/Out information to the 14501 and aprsstat info pages. Release 6 (revision 4) - TNOSaprs 1.06.04 ========================================= * Release July 29, 2001 * Fixed a VERY BAD BUG that would cause TNOS to lock up (never mind just a crash) with out restarting. This is definitely fixed now. * I'm very confident of this latest release. It is very stable. Release 6 (upgrade) - TNOSaprs 1.06.03 ====================================== * Release July 20, 2001 * Ignore messages having source calls starting with 'aprs', from the IGATE connection. No point tying up TNOS CPU usage for APRS server stats. There are other source calls that I need to look at as well. I'll have a better system in place in a subsequent release (I should not be hardcoding calls or portions thereof). * Cleaned up messages broadcasts out the RF port. Each message going out was getting a newline and null character appended to the end. This is now fixed and looks clean. * an RF APRS user can now opt-out of having their APRS packets sent to the internet, by simply specifying the callsign NOGATE or RFONLY at the end of the UNPROTO path. * Some code restructuring to make it easier for me to add future requirements. * A few minor bug fixes, code cleanup, some fixes regarding Newline characters at the end of the data that we receive from the internet side. They are now stripped out before any further processing is done on the information. * The aprsstat (finger) display now shows the RF (IGATE Logon) callsign and APRS RF port. * When using the 'aprs imsg ' and 'aprs lmsg ' commands, you don't have to worry about the case sensitivity of the call anymore. It's forced to uppercase now before any message is sent out. * Fixed a problem where if we receive an APRS frame that originated from us in the first place, we now ignore it. This could happen if a local digipeater repeated an APRS frame that we just broadcast ourselves. All previous implementations of TNOSaprs would actually hear the packet and 'process' it, sending it to the APRS internet system (which really is wrong). * Changed roles of the processes that are spawned when APRS server is started. Up until now I've had the aprsx process spawn a process that reads from Hsocket, where as the father reads from the Asocket. That really is not the way to do it. Asocket will rarely (if ever) die, but Hsocket can on a regular basis (since it's the internet connection). This restructuring is a cleaner approach and may correct an issue I have noticed with JNOSaprs, where when an IGATE connection is terminated, the aprsstat shows more than 1 IGATE connected, making me wonder something has not been closed off correctly. Release 6 - TNOSaprs 1.06x ========================== * Released July 12, 2001 * Wrote a brand new MIC-E decoder function, so TNOSaprs is now capable of receiving and decoding MIC-E packets from rigs like the Kenwood D700. Many thanks to Gary, W7NTF, for testing this software for me. It does work. * TNOSaprs now has an APRS *Message Center* of sorts for the sysop. This is a very powerful feature that allows the TNOS sysop to do 2 way messaging with any other APRS user, either over the local RF port, or via IGATE to any other APRS network world wide. This feature is only available from the console or the sysop mode at this time. Once fully developed, I plan to make it available to the general PBBS user down the road. * 3rd party and RF messages to and from TNOSaprs are now logged in the Mailspool directory, in the file aprs.log file. I should probably put it elsewhere, but for now it works for me :-) * The 'aprs message' subcommand has been replaced by two new subcommands, which are 'aprs imsg' and 'aprs lmsg', meaning IGATE Message and Local Message. The first is to send messages to other APRS users over the IGATE connection. The second let's the sysop send APRS messages to APRS users on the local RF port. * TNOSaprs will now ACK messages destined for itself (logon callsign) if the messages contain a valid message identifier at the end (ie, {xxxxx). Currently only one ACK is sent. I should probably have it send multiple ACKs over time, but that's for a future release. * APRS destination call is now APZ106, not APZ000 ! * The finger aprsstat information now shows TNOS uptime and the IGATE server logon (user) callsign. * Found one too many start_detached_timer () calls in the server connect routines. I'm guessing the extra call *might* have had the potential to add a degree of instability to TNOS, but I'm not 100 percent sure. In any event, hopefully it will be more stable now that the extra call has been removed. Release 5 - TNOSaprs 1.05 ========================= * Released June 12, 2001 * fixed a problem where if the UNPROTO path was set, ie : ax25 route add APZ000 ax0 VE4PKT-8 WIDE the route did not seem to take for 3rd party messages being sent out the local RF port. This was because of the *route by recipient feature* that is incorporated into TNOSaprs. It would still broadcast to just APZ000 (without the digipeaters), even though I had it configured above. Now if a route to the recipient is not found in the ax25 routing table, I then look up the route for the APRS dest call, which in the case of TNOSaprs, is currently APZ000. * will now respond to the Direct queries ?PING? and ?APRST from the internet side. * TNOSaprs no longer cares if the callsigns for 'aprs logon' and 'aprs fwdtorf' are in capital letters or not. It is now case insensitive to that. * Wildcards are now allowed in the 'aprs fwdtorf' command. Instead of doing : aprs fwdtorf KA6 KB6 ... KZ6 you can replace all of that with something much simpler : aprs fwdtorf k*6 * The 'aprs fwdtorf' command can now be run on the fly. Subsequent instances of this command will simply REPLACE the previous lists. * took out that annoying 'APRS Heard Table full', which was filling up people's log files. * The APRS Heard Table can now be dynamically created. It is no longer hardcoded to a maximum of 20 entries. You can initialize it using a new command : aprs hsize If you do not run this command in autoexec.nos, then no APRS Heard table will be started. Subsequent instances of this command will simply delete the current heard table and create a new one (with a new size). * If the APRS Heard Table becomes full, TNOSaprs will now replace the oldest entries with the newest data (which is what I originally wanted to do). The old versions simply stopped logging new entries, and told people the heard table was full (thereby filling their logs). * the dreaded 'aprs internal' command is no longer required ONLY IF you are running TNOSaprs on a linux box where linux is doing the encapsulation instead of TNOS. There seem to be more instances of gateways now where the sysop only has 1 public IP address at their disposal. This command is required ONLY IF you are running a system where TNOS is doing the encap. * if bcpos and/or bcstat are not configured, then do not broadcast to internet and RF port. * should now be a clean compile (no compile time warnings on my development box anyways). * check for arguments in the 'aprs server add | delete' command. Previously, if the incorrect number of arguments was passed, NOS would crash. * check to make sure the data from the internet side starts with an alphanumeric character, which should keep alot of garbage data from getting into our system, including the REMARKS and COMMENTS that some servers send out when you first connect. * put in some changes courtesy of Brian Lantz, so that the TNOSaprs code is in *sync* with his. Release 4 - TNOSaprs 1.04 ========================= * released May 22, 2001 * started using the convention, TNOSaprs 1.XX, to identify my software. Those APRS servers that have the TCP Port 14501 status pages, will show a PROGRAM VERSION of 'TNOSaprs 1.XX'. * TNOSaprs now sends Status (>) and Posit (!) reports about itself to the internet APRS system and RF port. Two new 'aprs' subcommands were added to support this new feature : aprs bcstat "IGATE - 441.050 Mhz - email : ve4klm@ve4umr.ampr.org" aprs bcpos "4948.50N/09707.84W-" * The 'aprs logon callsign' is now the callsign used for the internet status and posit broadcasts, as well as the source call for any RF packets sent out to RF. We don't use the Mycall parameter any more. This lets us setup a callsign/ssid completely separate from the other TNOS services, like BBS call and TCPIP call. * now recognizes APRS type frames that have the destination call, 'ID'. * now validates the DTI (data type identifier). This needs work, but it's better than nothing. * cleaned up a few compile time warnings. Release 3 - TNOS APRS Server ============================ * released May 16, 2001 * fixed up error messages, found some *memory* leaks * fixed a problem where I forgot to close a socket after sending a UDP datagram. Eventually this built up to the point where no more resources were available, and TNOS then crashed. * added APRS statistics, including a heard table showing APRS users and data type identifiers. * added 'aprsstat' command to the existing FINGER commands so that users could remotely access the APRS statistics and heard table information using 'finger aprsstat@ve4umr.ampr.org'. Release 2 - TNOS APRS Server ============================ * released May 4, 2001 * added 'aprs fwdtorf' command to determine which messages are allowed to be gated from the internet side to the local RF network. * added support for 3rd party messages from the internet to the local RF network. * now supports a few more APRS data type identifiers. * now recognizes UI frames that have the destination call, 'BEACON', or starting with 'AP'. Prototype - TNOS APRS Server ============================ * first release April 24, 2001 * forwards APRS type packets heard on the local RF ports, to an internet APRS server, so that users can lookup themselves up on APRS database like http://www.findu.com. * limited functionality, only supports 4 or 5 datatype identifiers at this time. * only recognizes UI frames that have destination calls of the format APZxxx.