In the past two days I've renamed two different nodes. Both were where I did a swap out of the hardware, and I had pre-loaded the node with AREDN including a non-location specific node name.
In the mesh status screen on another node, I see this:
The first is the new name...the second is the node before. Do these eventually age out, or do I need to flush them at all?
In the mesh status screen on another node, I see this:
| KG9DW-QTH-P2P-W.local.mesh / KG9DW-NB-4.local.mesh | 100% | 100% |
The first is the new name...the second is the node before. Do these eventually age out, or do I need to flush them at all?
Right now the method to get this to clear up is to turn off the node (KG6DW-QTH-P2P-W) in question for around 15 minutes, that allows enough time for all the other nodes on the network to forget about the NB-4 name.
Bob
Basically the same as the power cycle as the node would be off frequency so other nodes would forget about it if enough time elapses between making the changes (boot sequence is significantly faster as of 3.15.1.0) and assuming no other nodes see it on the new channel. So yes this can work too.
If it continues check and be sure that each node has a unique WiFi address. If not, simply hit the default button on the set up screen, then reset your custom settings.
I don't know how it happened to me but it did, that two nodes had the same IP address all as a result of renaming the nodes.
Mark
The low three bytes of the IP address are set to the low three bytes of the MAC (Ethernet) address.
MAC addresses are 6 bytes: a 3-byte vendor prefix and 3 bytes set by the manufacturer to make the complete address globally unique. IP address collisions can therefore occur if the user changes the MAC address or if two factory-assigned MAC addresses have different vendor prefixes with the same suffixes.
Ubiquiti is already using at least three prefixes that I can see (24:a4:3c:, 68:72:51:, dc:9f:db:), and even if they didn't it seems unreasonable to limit the network to one hardware vendor. So IP address collisions will be inevitable as the network grows unless some new method of selecting them is used or IPv6 is implemented.
OLSR floods name/IP address mappings around the network, and they should go away eventually when a node has been down long enough. I run olsrd on some of my Linux systems, so they maintain their own name/IP address mapping tables in /run/hosts_olsr. I occasionally run a script on it to generate my own copy of the domain zone file, and I frequently see old entries disappear when a node has been down or unreachable for a while. Never timed how long, though.
IP Address Collisions because the last 3 octets of the MAC address are not unique? Apologies in advance if (as I now suspect having just learned that the first 3 octets are somehow hashed into the device's IP addresses) I haven't yet read the details of AREDN or MESH routing algorithms which makes this clear. It wouldn't seem IPv6 is required to avoid these conflicts and the difference in CPU cycles may well be in favor of sticking w/IPv4. ... again - unless there is something unique about MESH routing I haven't yet discovered. In the context of any IPv4 Class A network - wouldn't use of IPv4 RFC's (possibly with some intentional MESH specific permutations re: BGP & private address spaces) survive with equal utility? Relying on Ubiquiti radios now may be eminently sensible but I hope there is a consensus that designing MESH Architecture locked into one vendor's radios possibly not so much so. If there are specific documents I need to read now I'm looking forward to identifying them (hint <g>) expeditiously.
Thanks & 73 ...dan
Someone want to try to do the math to attempt to quantify the chance of an IP collision occurring? If this is such that we'd have to be bitten by a shark and hit by lightening on the same day, then we just had our ~1000 year hit, and there would be a lot bigger fish to fry of things we'd all want to otherwise make happen.
One of the criteria the original design was trying to meet, is that there is no central master list of assigned IP addresses
http://bloodhound.aredn.org/products/AREDN/wiki/TechRef/GUI/admin/PerlUI...
Joe AE6XE
Joe:
see msg below, didn't realize I'd saved this one and do not have access to 'delete'.
Eloquent Hashing from MAC to IP Addresses and effectively redefining 'private address space' simultaneously.
This will make it much easier to understand the Tech Reference material as well as clarify how many addresses are available at a given node for host and local interface purposes.
What impresses me most about BBHN & AREDN (other than how phenomenally valuable the effort it) is that there is sufficiently good documentation for non Network Engineer Amateurs to make it work.
You'uns do very good work.
Are 44 net addresses used at Internet Access Points (Gateways?)
73
...dan wl7coo
Every mesh node has a WAN-gateway interface set by default to DHCP and obtains whatever the foreign network address provides. I have seen people using 44.x.x.x addresses (instead of 192.168.x.x or 172.16.x.x addresses) on their home network--and potentially directly routable from the internet, but still NAT'd masq on the Mesh side 10.x.x.x .
The 44.x.x.x issue does come up now and then. While many things can be done to incorporate and integrate AREDN, 44.x.x.x., and the internet, I've not seen anyone articulate the benefit that would cause me or others on the AREDN team to go implement something to date. It's not that I'm against integrating these things, it's that I think there are bigger fish to fry, e.g. how do we stay ahead of our RF network scaling up->things like QOS, limitations with OLSR, 802.11 adhoc, etc.
Joe AE6XE
The chances of any kind of hash collision come from the so-called birthday paradox. It's not really a paradox, per se; it's just that the math gives results that are very counterintuitive to many people.
It comes from the puzzle of how big a group of people you need to have a significant chance that two or more share the same birthday (month and day).
Obviously to guarantee a match you'll need at least 366 people, or 367 if you include February 29 as a separate birthday. But you only need about 23 people to have a 50% chance of a match, and that strikes a lot of people as surprisingly small.
The reason it's so small is that you're not looking for a match to a specific person's birthday, you're looking for any match among any two people in the group -- and there are a lot of possible pairs in even a group of 23 people.
As a very rough approximation, you have a 50% chance of a match when the group size reaches the square root of the size of the space. (365 isn't a very big space. The approximation gets better as the size of the space increases.)
So how big a network will give you a 50% chance of at least one address collision when 24-bit node addresses are randomly chosen? The answer is about sqrt(224) = 212 = 4096, which is not that big a number in a successful network. And it gets a lot smaller if that 50% risk is too big for comfort.
Obviously you can avoid collisions by not picking the addresses (pseudo-)randomly, e.g., if they're taken from the low 3 bytes of a factory-assigned MAC address that you already know is globally unique. But that works for us only if everybody used the same equipment vendor and the vendor uses the same 3-byte prefix for every piece of equipment. And we know this is already not the case for Ubiquiti, which I observe to use at least 3 prefixes.
If you don't like central address management, you basically have two choices: find some automatic way to detect and resolve conflicts, some of which may appear only when two large existing networks are merged, or switch to a much larger address space that reduces the risk to a tolerably low number. The only credible way to do the latter is to switch to IPv6.
"CPU cycles" is not an argument for staying with IPv4, as most of a node's (or host's) cycles are spent processing things other than internet protocol headers. But to the extent that it matters at all, IPv6 is actually much easier to process than IPv4.
IPv6 is notable not just for its larger address space but also for the IPv4 features that were deliberately removed, most notably router fragmentation. (As an early TCP/IP implementer, I can say that router fragmentation is by far the hairiest part to do correctly.) Any fragmentation and reassembly must be performed by the sending and receiving hosts. This eliminates the following IPv4 header fields: Identification, Fragment Offset, MF (More Fragments) and DF (Don't Fragment -- every IPv6 packet has that implicitly set). IPv6 also eliminated IP header options, not that they are heavily used in IPv4 anyway; this eliminates the Header Length field.
IPv6 also eliminates the header checksum field; this results in the biggest CPU savings in practice because it no longer has to be recomputed by the router when the time-to-live (aka hop limit) field is decremented.
But these are issues only on very fast (multi-gigabit) routers; on slow networks like ours, IP header processing is down in the noise. And the avoidance of chronic headaches like private IP address space collisions and kludges like NATs and port forwarding create a very strong reason to adopt IPv6 ASAP.
Thank you for a very good explanation.
...wl7coo