I have found that if I create a service on the local node and on an attached server using the same service name for both, the UI will not allow the second instance to be saved. I believe the test for uniqueness should include the hostname and the service name. This makes sense since the node, and any attached servers, are grouped separately in the mesh status display so there is no confusion between the two services.
[moderator KG6JEI comment: Moved to Development>Possible Bugs ]
You are here
Teeny bug?
Thu, 01/14/2016 - 20:30
#1
Teeny bug?
Theme by Danetsoft and Danang Probo Sayekti inspired by Maksimer
This may actually be a restriction lower in the stack that we need to have higher up. Im not sure off hand on code stopping the save but I do know about code later on that reads the results.
There is a workaround across the mesh already that all nodes if they see the same service name advertised from the same mesh node they only display the most recent one. This is an old but still needed hack to avoid the fact that OLSR has a (low priority so far but in the ticket list) flaw that it doesn't expire service advertisements, they stay locally forever.
Once we fix that flaw we can remove the hide featurez
However it may take a mesh protocol reversion roll to remove a save restriction to prevent some nodes from not being able to see the LINK if they are running an older version then fixed.
Even then this may also possibly be part of OLSR key:value pair and that would make it more complicated I would have to read that code as well. I cant recall if was thinking of keying idd the name or the whole line value for matching.
For time being it might be safe to call this a "protocol restriction" (little bit of a stretch I'll admit but pretty darn close)