Curious, is anyone using the tactical callsign feature?
(If you didn't know about the feature, I'd like to know that as well) ;-)
thanks
Theme by Danetsoft and Danang Probo Sayekti inspired by Maksimer
Theme by Danetsoft and Danang Probo Sayekti inspired by Maksimer
I'm currently using them, but am finding they have little value... here's why: Node names need to be unique across the mesh, and so do tactical callsigns. I'd love to be able to use simple names such as "Pi" or "Switch", "Camera", and so forth, but can't get away with this since someone else will surely also use the same name... rendering both tactical callsigns useless. In the end, I don't see the value in having two callsigns for the same node when both names must adhere to the same rules of uniqueness.
Also, what I find I do 99.9% of the time is click node/advertised-device names in the Mesh Status screen to navigate or use a clickable reference guide I've created of network devices and their respective IP addresses rather than using the tactical callsign.
I recall a couple years ago thinking this was a cool feature, but when put to practical use... not so much.
Andre
There is a way that something like "tactical callsigns" might be implemented using standard Internet facilities, namely the Domain Name System (DNS).
As far as I can see, BBHN/AREDN is using something much like the old Internet "hosts table" scheme that the DNS replaced back in the 1980s. The node names I see even resemble the host names that were common back then. The DNS replaced it because it had already grown far too unweildy.
As everybody knows, the DNS is hierarchical, parsed from right to left. What not as many people know is that DNS resolvers, as an implementation feature, can be configured to supply one or more default zones for domain names that are not "fully qualified" (i.e., specify the complete name ending in the top-level zone). For example, when I worked at Qualcomm my Linux /etc/resolv.conf file at home contained the line
search ka9q.net qualcomm.com
So if I said something like "ping foo", my resolver would first look for foo.ka9q.net on my home network, and that didn't exist it would look for foo.qualcomm.com.
This should make it easy to set up simple names for your own machines that may duplicate the names used by others, and as long as you have the proper search path configured everybody will get what you want. For example, I could have pi.ka9q.something (see below) and you could have pi.k6ah.something and they could coexist.
The DNS also allows for aliases through the CNAME record; e.g., had I wanted to I could have set up "work.ka9q.net" as an alias for my workstation at Qualcomm, flanders.qualcomm.com, so that giving either name would get me the same thing.
While all this searching may seem inefficient, it really isn't because both records and non-existent entries are cached, and the hit ratios are usually pretty high.
I've been thinking for some time that AREDN and BBHN could benefit from a more complete and Internet-compatible naming scheme based on the DNS, e.g, by placing all the names in our mesh networks under a valid DNS zone. Way back in the mid 1980s Brian Kantor WB6CYT and I requested the top level zone ".ham" but were turned down (this was long before commercial registrars). We got ampr.org instead, which is still around and available for use. I thought about broadening our request to a top level zone that would be open to any government-assigned radio/TV station callsign following the ITU prefix scheme, as they're already unique world-wide, but I couldn't think of a good candidate name (.radio? .rf is the Russian Federation) so I didn't pursue the matter further. We actually could still create .ham, but believe me, we can't afford it.
Thanks Phil. That might be a good way to resolve (pun intended) the issue.
Perhaps we could do the following:
For the "normal/main" host name of node: <CALLSIGN>-<UNIQUE_IDENTIFIER>.local.mesh
For a "tactical" host name: <TACTICAL>.<CALLSIGN>.mesh
Eh.. thinking this still doesn't solve the "tactical" situation where I may want to swap out my node with another, but, keep the tactical name the same...
Ie. the EOC tactical shouldn't be tied to MY callsign domain...
If I understand the problem, you should be able to do this with CNAME records in the DNS.
Here's an example. My primary domain is ka9q.net, but I also have ka9q.com. So if you look up "www.ka9q.com" the DNS returns these two records:
www.ka9q.com. 604800 IN CNAME www.ka9q.net.
www.ka9q.net. 21600 IN A 192.185.225.245
I.e., you're automatically redirected to the canonical name and IP address. So if you swap out a node with one having a different name, you just change the CNAME record with your "tactical" name to point to the new node name. Depending on how often you expect to do this, you may want to keep the TTL (time to live) fields small. That's what 604800 and 21600 are in those records; they're the TTLs in seconds.
We'd have to think about how to actually implement the DNS in our mesh networks. RIght now olsr "floods" name/IP address pairs throughout the mesh, piggybacking them on topology announcements. The nodes cache them, typically in /run/hosts_olsr in the old "host table" format. There's a DNS resolver in the node firmware that will return them, but .mesh is an isolated namespace; it's not a valid top-level domain. If you want your host computer to talk to both the mesh and the "real" internet, you have to do some ad-hoc stuff in your resolver to combine the two. Somebody on the "real" internet would have no idea how to resolve a .mesh address.
So one approach is to pick a valid top-level domain (e.g., ampr.org, though it could be anything), set up name server records to point to a few nodes that are on both the mesh and the regular internet, and have them serve requests out of their caches. It would be a good idea to have a subdomain for each mesh, at least until they get some sort of direct interconnection. E.g., we might be sdg.ampr.org.
And of course we also have the problem that we're using non-routeable RFC-1918 addresses like 10.0.0.0/8 that can't be reached from the external Internet. Eventually IPv6 will solve this problem by giving everyone a fully routable address.
KA9Q wrote: