Hello, all....
I am running through a weird bug on my node.
I am running AREDN on a MikroTik Router Board hAP AC Lite with the night build: 586-6728fba
My node name is "AL0Y-RB-MAIN" and is a tunnel server for three clients. It has no RF neighbors.
The problem is my node is showing to my clients (and their neighbors) with two hostnames as:
- AL0Y-RB-MAIN.local.mesh / dtdlink.AL0Y-RB-MAIN.local.mesh
with the link actually going to dtdlink subdomain (it replies and shows the status page to both the domain, and the dtdlink subdomain)
I tried rebooting the node, changing its name completely (it was AL0Y-HOME-RB) until last night, and this problem still persists.
I included the support data and a screenshot from one of the tunnel clients.
Support File Attachment:
When you changed the name to AL0Y-RB-MAIN, that name was also associated with your node's WiFi address in your OLSR table and replicated through the mesh.
At that point the other nodes do not know what the correct name is for that IP address.
Rebooting your node will not eliminate the duplicate entry in the OLSR table on the other nodes (Current Neighbors or Remote Nodes).
There are two ways to get back to one node name for your node.
1) Reboot all the nodes on the mesh.
2) Leave your node off the mesh for about 30 mins (I am not exactly sure the exact time) so your node name is flushed from the system and then bring it back online to replicate the current node name/IP address through the mesh.
If you are seeing two names for other nodes in the Current Neighbors or Remote Nodes section of the Mesh Status on your node, you can reboot your node to eliminate the two name "problem", but that only "fixes" the problem on your node.
Lesson learned:
Try not to put you node on the mesh with a temporary name that you keep changing.
Use the Node Description field for information that changes as the role of the node changes.
ke6bxt,
I want to clarify that the two host names showing are NOT the old and the new name. Instead they are BOTH for the new name except they are:
I indeed turned off my node for some time to clear the OLSR, this still didn't solve the dtdlink hostname.
That's when I changed the name (waited enough time to flush the OLSR before rebooting back with the new name). I confirm the OLD name is no longer showing on the network at all. the NEW name is the only one showing.. however, with an additional dtdlink subdomain host name.
Again, please look at the screenshot.
Jim
AL0Y-NJ-A.local.mesh and dtdlink.AL0Y-NJ-A.local.mesh
I will have to consider this as a bug at this point?!
AL0Y, for a not yet explained reason, there are 2 network interfaces on your device with the same IP address. This is why mesh status is showing both hostnames for the node. Both the primary wifi and dtdlink interface have the same IP address -- which is a conflict and should not occur. The IP addresses are derived from the MAC address of these interfaces. So the current mystery is that the MAC addresses are correct and different, but the derived IP addresses aren't matching respectively.
Are you able to load the current nightly build, and do not "keep settings" in the process? (or if at the current nightly build, do a 'firstboot' in advanced settings.) This means you'd have to enter the basic setup information again. Are you able to reproduce the symptoms? There is a possibility we are carrying over an issue from a prior and bad nightly build to rule out.
Joe AE6XE
I guess we are getting closer now. These tunnel connection information were copied from a previous NanoStation M2 that was running a tunnel server.
I didn't want to update the tunnel information for my clients so I copied this information into the new node. including changing the tunnel network IPs.
I though this was okay since the fields are editable.
Also, My RF IP is: 10.223.113.112, and my Tunnel network IP is: 172.31.232.48 (the later IP is what I changed)
I will reset everything again and keep the default values that are driven from the MAC address, and will try with a client that I will set on one of my nodes. I will keep you posted.
Thanks a lot for your reply, Joe.
I just reset the value to the default (without re-flashing), only for the RF IP. apparently I had that changed before from 10.222.113.112 to 10.223.113.112.
Not sure how this happened or at what point. but this solved the two IPs problem and hence the dtdlink subdomain in the hostnames.
I didn't have to change the Tunnel network IP back to its default. so I am keeping them to keep the tunnel connections up.
Conclusion:
Changing the RF IP, apparently, also changes the IP for the DtDLink as well to the custom value that was set; hence ending up with 2 interfaces using the same IP, while using the default values seem to work correctly to generate the correct IPs.
Thanks a lot, Joe for pointing me into the right direction to figure out this mystery.
I would suggest making sure that changing the RF IP doesn't change the DtDLink IP, or drive the value from the new IP instead of updating both interfaces to the same IP.
A) manual change of the RF interface from "10.222.113.112" to "10.223.113.112" occurred (and this created an IP conflict with the dtdlink interface). -> there should be a check to not allow the wifi interface to be set to a duplicate IP address
B) manual change of the RF interface to a random IP address -> the dtdlink interface also ended up with this same IP address, a bug to address.
Joe AE6XE