While clawing thru the forum posts and documentation, I noticed the very nice feature of being able to assign a Tactical name to a node. Makes sense ...
So I tested that out with one of my nodes, which was initially setup as "AA7AU-example.local.mesh" and was seen by all of the several nodes on our local proof-of-concept build-out mesh network, along with the instance of MeshChat on my node on all those other status pages.
I then added a "Tactical" test name by adding "/Don" to the node name in setup and rebooted. My node was then seen thru the rest of the local mesh as "Don.local.mesh / AA7AU-example.local.mesh", however my MeshChat advertised service was no longer listed in the Mesh Status page of any other mesh node. Also, every other node's "Mesh Status" page only linked to "Don.local.mesh" and NOT to the original "AA7AU-example.local.mesh". That "Don" link did work fine and brought up my node if clicked as a link ... until I changed it again.
So, the Mesh status page apparently prefers the Tactical name over the regular name when forming the link or looking up the node. Which probably clobbered my MeshChat service ad.
I decided to change back and deleted the "/Don" part of the name and rebooted again. All the other nodes in the mesh still display me as above with the "Don" link - which no longer works. I had effectively "cloaked" my existence in terms of the Mesh Status pages - that was NOT my intent, I thought it would would revert to the earlier status before the change and I would reverse it all as if my test had not happened. That did not happen.
I know from experience that if one of those other nodes is rebooted, it will again see me with the proper name and link correctly along with my Mesh Chat instance, but it seems to take a reboot of that remote node to cure this problem. I do not know if MeshChat properly handles this naming problem.
Does this seem right with the way the Mesh Status is handled, looked up, advertised, etc above?
TIA,
- Don - AA7AU
You are here
Nameservice after Tactical name addition/change
Mon, 11/06/2017 - 15:05
#1
AA7AU
Nameservice after Tactical name addition/change
Theme by Danetsoft and Danang Probo Sayekti inspired by Maksimer
As for the rest of it I'm not sure off hand what behavior has historically been so if you think it's something broken in the user interface then a ticket in bloodhound would be a good idea, if you think it's a meschst fault then it's best to send that to the author of meshchat.
Don,
You must be seeing these symptoms: [LINK REMOVED] This is an OLSR bug that doesn't expire a hostname/tactical name. Although note if you power off the node (that had the name change) for a period of time (maybe 15 min or so), the old name seems to expire across the mesh.
If you are seeing in mesh status only the tactical name, I suspect this is a combination of the above issue and that you used the tactical name "don" on another node. This would show duplicate entries in the hosts table across the network and thus the confusion. When the hosts table is clean, mesh status normally shows an entry for the node, with both the "hostname / tactical_name" in the link's name. When you hover over it, then only the primary hostname shows.
Joe AE6XE
Thanks! That's it: "Hostname advertisements via OLSR do not expire unless the orignating node is shutdown or otherwise looses contact for an extended period of time."
As suggested, I powered my node down overnight and when I powered back up and then later checked this morning, all the other nodes had reverted to using the correct "AA7AU-example.local.mesh" label with correct underlying URL link for my node ... -and- my MeshChat service had reappeared on all those pages.
This was never a MeshChat error. I checked further before the shutdown and it was running just fine with msg updates etc. MeshChat is a fine, very helpful product, I sure hope it continues to get supported and [slightly] upgraded. My thanks to the MeshChat author!
The first issue was the change in the underlying URL link in the other nodes Mesh Status page when a Tactical sign had been used - where the "tactical.local.mesh:8080" was the ONLY URL link under the combined name label. This is why my MeshChat service disappeared from the list. (NB: I had NOT used "Don" or any other Tactical name at any other node in our mesh island; that was not a part of this problem).
The second issue was that the hostname advertisement never got updated after the tactical name was deleted, unless/until a remote node was rebooted and/or my node was taken off-line and the old ad allowed to expire and then get properly reasserted with the correct URL upon my power-up.
One of our (primary) nodes is at >9000', well above snow level now, and will have to live by itself until mid-spring next year. Until we get remote power setup/control on that mtn top, there's no easy way to take that node off-line for name expiration using power-down such as this. I suspect changing the SSID of that node remotely and then one down here in the valley to match might ultimately achieve the same effect (with many more steps), but I'd sure hate to brick that mtn top node ... it's a very tough long hard road even on the best of days.
I would suggest that the documentation be updated to show the effects of using a Tactical name. I would also suggest that the Mesh Status page be upgraded to show a split label, with both names seperated with proper underlying URL links - and - the associated service list be upgraded to handle this effect. A lone ghost Tactical label/link would have been much easier to understand and deal with, and would not have broken the ability to remotely access my node using the Mesh Status reference.
Thanks for the help!
- Don - AA7AU
Any ideas?
AA7AU reported an issue with remote nodes that need to go offline for long per periods of time for the tactical call to be forgotten through an extended disconnect cycle. Mountaintop and remote sites in general could be lost to the network for months.
See attached file.
This isn't a reprimand its advice to how to get the suggestion to be taken up the full chain to get to be considered. Many users are still not aware of the process so it is being pointed out solely to help this user and others in the future get features and fixes considered by the Dev team. The AREDN Dev team hears lots of ideas but doesn't really know what a user is just thinking aloud or truely wants to see happen. The ticket system acts as that location where users can submit items they feel strongly about and the dev team can take official action upon them and all can see the official results of the development teams decision.
"Where does one enter the required Summary field?"
It is that big field that says to enter summary text.
Note the ticket you appear to be submitted doesn't appear to match the request of modifying the Status screen and appears to more closely match the flaw noted above by Joe.
It seems that some items are inherently more important. The Dev team will always prioritize, but this one notes how a node could be isolated, possibly for months. I don't know why there is no Summary box, but it is messing me up in lending a hand. I just think we need to be more customer-service oriented.