After fighting with my bullet M2 Conrad helped me through email and now I have a AREDN node in Zachary, Louisiana.
I like the idea with the mesh nodes, it would be neat to see a hamnet type intranet using the internet as a back haul between nodes. Something similar to tor but not tor, just ham radio.
If there was a central server that all internet connected nodes connected to it could provide a central pbx gateway for true coast to coast connectivity.
Now I just need to get a few more ubiquiti devices, mainly the rocket devices so I can cover all the bands.
I like the idea with the mesh nodes, it would be neat to see a hamnet type intranet using the internet as a back haul between nodes. Something similar to tor but not tor, just ham radio.
If there was a central server that all internet connected nodes connected to it could provide a central pbx gateway for true coast to coast connectivity.
Now I just need to get a few more ubiquiti devices, mainly the rocket devices so I can cover all the bands.
Regarding the idea of a central PBX, that can support experimentation but is unlikely to be useful to the AREDN focus on emergency communications support - which tend to be local or regional activities.
You may want to post questions or suggestions about this in the VoIP Forum, where Mark N2MH is a moderator. He is very knowledgeable about VoIP and PBXs. He has established VoIP extensions in several states on his PBX which get to him via tunnels.
73,
Randy WU2S
".... a central server ..." == a single point of failure. Perhaps not.
Good that you got a node up and running, we all need to do that.
73 & pax vobiscum
...dan
Hi,
Rather than a central server, some form of Distributed Hash Table might be an appropriate way for internet gateways to find each other and exchange routing information. see: https://en.wikipedia.org/wiki/Distributed_hash_table
However, unfortunately, some of us don't have "real" layer-2 internet access as we are behind abominations like CGNAT (at least dynamic-IP still works with incoming connections, once the IP address is known by the remote station). So, to make it work, those nodes with "real" internet access would probably have to end up (automatically) proxying packets when two nodes both behind CGNAT etc want to communicate with each other.
I think that we should be seriously considering using IPv6. There is more than sufficient bits to encode callsigns in IPv6 addresses - this will eliminate the risk of "birthday collisions" that we currently face by using the lower 24 bits of an ethernet MAC address as the lower 24 bits of a 10.x/8 IP address. Almost all of our computers already have support for IPv6 (even Windows XP!). Do you think that the ham world would be able to get the IPv6 equivalent of the 44.x/8 block that we have for IPv4? (else we'd just have to use part of the "private network" IPv6 address space?).
Also, if you sign up for Logbook Of The World, the ARRL check that you really do have a ham license, and then sign your public key (X509 certificate). While this is intended for digitally signing eQSLs for LoTW, it can also be used to sign any other data. This means that say in the case of internet forwarding, that my node here in New Zealand would be able to verify that your node has a valid certificate (signed by the ARRL) and is thus under control of a ham, and then permit forwarding your internet traffic to the RF mesh here in ZL. If you load your LoTW certificate into your web browser, you can already use it to log in to aprs.fi and prove that you are a ham.
These certificates can also be used to prevent tampering of data in transit aka authentication without encryption - all data sent in the clear, for anyone to see (the contents of the message is not obscured), but there is a long number tacked on the end which anyone can use your public key to verify. Anyone who has the ARRL's public key (which is readily available) can check that your public key has been signed by the ARRL.
This could be used (with a patched dropbear to enable null-encryption), to enable say a sysop to log into a node via RF, and issue privileged commands, with all communications sent in the clear for all to see, but it is impossible for a bad guy to "snoop" on the admin password since this is never sent over the radio, or to hijack the link (TCP session hijacking etc) because the bad guy does not know the sysop's private key.
Another use would be to sign routing data, and if a node is broadcasting bogus routes, you could "blacklist" that node's certificate, causing your node to ignore the bogus routes (this would probably be pretty important if we started automatically internet linking nodes to each other).
73 ZL2WRW
Ross Whenmouth