Well, the first question would be if this would be desired, to be able to exchange messages between the AREDN network and the old fashioned amateur radio packet network. On the AREDN side, the packet interface would probably look like a web page that would look like the output of a TNC. Of course you'd have an account and password access to get into that web page. This interface would live at someone's node. But if all he has at his node is a 1200 baud TNC and a 2m rig, things could get really slow if more than a couple users get on at any one time. Hook directly into a backbone or whatever packet BBS's use to distribute messages world wide?
But if nobody uses packet anymore, there'd be little point... 
You are here
connection between old fashioned packet and Aredn network?
Mon, 01/02/2017 - 16:47
#1
wa2ise
connection between old fashioned packet and Aredn network?
Theme by Danetsoft and Danang Probo Sayekti inspired by Maksimer
There may be some options for what you want via BPQ32 Packet switch software.
This is exactly how BPQ32 works. I have it integrated into my AREDN node. I have a web link that allows various stats to be viewed, along with a web based terminal window you can log into that gives you a CLI. I also provide a telnet link that will give you a text based console window, just as if you're sitting at your TNC. You can come from the mesh, connect to the Packet BBS, read and leave mail, connect out over the radio to the few other nodes in the VDEN in my area, or connect over the internet links to hundreds of nodes worldwide.
John, N9ZL
BPQ32 looks interesting but I see APRS messages being generated and managed in a webUI hosted on the mesh that manages and passes via ip to the XASTIR digipetor thats on 144.390 RF -))))))) This would let one have group chats with others in the field or via the tried and true 1200bps packet. NO one has created a standalone WebUI for APRS messages, just digipetor after digipetor and trackers!
If someone is going to write a plug in for Mesh chat... A web portal for APRS messages. The the discussion has floated around a node hosted plugin or pushing it off to a RPI. Once the functions are pushed off the node. (best option!!) Well then lets go to town and fork the RPI Mesh chat code and write in the functionality of APRS messages transmission. The mesh chat has to generate unique packets for each call sign as well as monitor for the a response. Would we want to use code like that behind Dirwolfe to alow any type of kiss or TCP/IP KISS, serial Kiss. I run xastir on a RPI with a PiTNC to generates kj6dzb-4, but I also lock the screen into 1080p and watch the map, other might not choose to do that, and just run a head less digitetor. Libary support to send messages, thats rather simple to send it to aprs.fi or Xastir with your passcode (I verified this on the python APRS library). The trick that I cant tackle is how Mesh chat receives and strips and sorts the message, via versa. With Mesh chat you have to put your call sign in, well if you want to send one out via aprs you need a passcode so the .fi core servers accept it. Xastir still requires a passcode to monitor the stream. Considering this each user will need to log into mesh chat with there call sign and passcode, and the program need to track and monitor the aprs stream then sort them back off to there "chat groups" of origin. say some one sends a message to multible aprs callsigns, or dose one just attach call signs to chat group?
Mabey just write this into Dirwolf. if Mesh chat isnt going to work because i dont see open code!
73 Mathison
Trevors code is pretty well documented, including its API, http://www.trevorsbench.com/meshchat-messaging-for-mesh-networks/#api
Far as I can tell everything you need can be handled inside of the API (sending messages) and Action Plugins framework (receiving a messages and triggering an action to submit it) no modification necessary (see the example action plugins for a starting point).
If one studies the APRS-IS system you don't even need the "Log In" requirement you mentioned, You log in the operator of the gateway and then the person has the ability to submit data directly for EVERY callsign out there. APRS-IS handles the routing of packets to the 'last known" gateway so you don't even have to worry about filtering them coming back to you. (BTW APRS.FI isn't a core server, its actually just a client tracker on APRS-IS polling off the T2 servers like everyone else, connected listing to the global APRS stream with no filters enabled, possibly via the "No filters" port no different then any other APRS tracker software --- see: http://blog.aprs.fi/2012/05/aprsfi-connected-directly-to-aprs2net.html )
bqp32 (or any other APRS tracker) and a couple of scripts could probably work this up inside of a day (assuming one knows about APRS-IS, if not add a few days to read the full APRS-IS specification and a couple client programs to know what one is linking into see: http://www.aprs-is.net/Default.aspx ) as a standalone plugin without any modification to any existing programs all as stand alone parsing of scripts which massively increases your compatibility across the network and you end up with a well designed Linux program that "does one thing and does it well"
PS: Official AREDN standpoint is not to run anything on node, use the node as what its being designed to be a modem (with fancy linking controls built in but a modem all the same)