You are here

Duplicate IP Addresses

21 posts / 0 new
Last post
AF6FB
AF6FB's picture
Duplicate IP Addresses
Hello,
I have two nodes that have the same LAN address. One is a Ubiquity NanoStation Loco and the other is a Mikrotik hAP.

I have flushed browser history, DNS, powered down each device and only had one connected at a time. How can I give one of them a different address? I see that I can change the WiFi IP address, I'm a little afraid to as it might conflict with someone else. The LAN addresses I can't change.

I need some direction. Here are some screen shots...

https://photos.app.goo.gl/EEPikTFV5oNDv6vF7

BTW, I have a third device, a NanoStation M2 that came up with it's own address. All stations work fine individually.

Thanks in advance,

Michael AF6FB
949-298-0529
 
K6AH
K6AH's picture
Change MAC addresses
Ask someone with a broken device what the mac address was.  Replace your device's mac address with the broken one.  I don't personally recall how that's done, but it is possible.

Andre, K6AH
 
k1ky
k1ky's picture
Duplicate IP Addresses

You can change the Host configuration to 1-Host, 13-Host or 29-Host and that will change the base Network IP addy of the node - thus eliminating the duplication. And you may need to pick another IP addy for the Wi-Fi as well, which I believe you can edit manually.

AE6XE
AE6XE's picture
AF6FB, can you attach a
AF6FB, can you attach a support download for both these nodes?   The MAC address is already being manipulated on some Mikrotik devices so when deriving the IP addresses, everything works.  I'd like to review in case there is an option to adjust this algorithm and reduce the change of collision.   Maybe we can reduce the occurrence from only being hit by lighting to also being bit by a shark on the same day :) .
NM7B
Duplicate mesh IP addresses between two Rocket M3's

I just installed a new node based on a Rocket M3, and after several hours of debugging, realized that the anomalous behavior I was seeing was caused by two nodes, both Rocket M3's, being assigned the same mesh IP address.  And of course the two nodes were directly within RF range of each other, so they created interesting multiple names and multiple links on the mesh status, including a "dtd." reference.

I manually moved one Rocket M3 node to a unique IP address, so things are up and running (great, I must add).  However I wonder if this is just bad luck and I should hurry out to get a lottery ticket, or this is a valid concern worth looking at to determine why conflicting mesh IP addresses were assigned.  

Let me know if anyone on the firmware team is interested to determine what happened.

Thank you, and 73's,
Collier

AE6XE
AE6XE's picture
Yes, can you attach a support
Yes, can you attach a support download, link at the bottom of the Administration page, from both nodes?   Since both devices are the same manufacture, the probability that there is an IP address collision is zero or nearly zero.    There is actually a bug that needs to get entered when there is a true collision.  While the wireless IP address has a manual over-ride to correct, there is no way in the UI to over-ride the dtdlink IP address of the node.    If you have everything working, then something else must be going on or you're not dependent using the dtdlink path to other co-located nodes.

Joe AE6XE
k1ky
k1ky's picture
Changing Network IP Addy
Please see my note above - you can change the Network IP addy of a node by switching the number of Host assignments. At least this is a "work around" for the time being.
AE6XE
AE6XE's picture
There are 3 network
There are 3 network interfaces and derived IP addresses from the MAC address:

1) Wifi Mesh RF address  <- static IP address can be manually designated in basic setup
2) DtDlink address   <- no place to change in UI
3) LAN addresses  <-  IP addresses are different based on # of hosts selected.

This thread original had the LAN #3 conflict and changing the # of hosts as noted should do the trick.  This new conflict is #1 mesh RF, so should also have a conflict with #2 DtDlink.

Collier, if you can upload support data downloads from both nodes, this would be helpful.  I suspect what is happening is that Ubiquiti has multiple MAC address ranges assigned.   The right most #s of the MAC address are the same, but left most numbers of the vendor code are different.  This would be the first known hit of a collision and you'd be the lotto winner. 

Joe AE6XE

 
NM7B
Should I file a new issue in the GitHub forum?

I have the support data files downloaded from the nodes, but want to confirm: where should I upload these diagnostic files to?  Should I open a new issue on the Github page linked under the Code menu on this forum page?

Also: no lottery ticket for me.  The MAC addresses of the two conflicting nodes both start with 68:72:51 as do all of the other nodes I currently have on the air.

Thank you and 73's,
Collier
NM7B
 

AE6XE
AE6XE's picture
You can upload the support
You can upload the support file attachments here -- see at bottom near save button, uploading the .tgz file.     Let me triage, then escalate to a github issue as necessary.
NM7B
Thank you--I'm glad I asked and confirmed

Support files have been attached.

AE6XE
AE6XE's picture
NM7B,
NM7B,

The issue is on the node "K7CPU-Hillsboro-Ronler-Acres-4".    If you take a look inside the file "/etc/local/uci/hsmmmesh"  you will find the derived IP addresses of that node (with out the leading "10.").    Somehow, the /etc/config/network file on this node was edited to have the same IP addresses as the other node to create the conflict.    You may be able to resolve this by doing a "save" in basic setup to get the correct IP address (do a "reset values" first!)  This "save" process reads the /etc/local/uci/hsmmmesh" information to create the /etc/config/network file, which is the configuration used after booting.

If for some odd reason this doesn't work, then resetting the node back to first boot should also do the trick, then go back through the setup again and note what default IP address it is using.

The IP address derived from the MAC address on this node for the mesh RF or wlan0 interface should be "10.138.72.203".  and the dtdlink interface should be "10.139.72.203". 

Joe AE6XE
  
NM7B
I see... and thank you for reviewing this

Hi, Joe,

Thank you for reviewing the support data.  I see what you mean about the difference between the hsmmmesh and network files.  I'm not sure how the network file content got changed.

I won't have access to the LAN cable to the node until next week.  I did try doing the "reset value" then "save" steps, but that didn't load in the correct mesh IP address.  I also tried that on the other node where I previously manually overrode the mesh IP address and it also did not load the auto-generated IP addresses.  Would "Default Values" be the correct button to click instead, to bring over the values seen in hsmmmesh?

In the meantime, I have manually configured what is supposed to be the correct IP addresses as listed in the hsmmmesh file, so there are no mesh IP address conflicts at this time.  However I would like to have the nodes auto-generate these to ensure that someone else without the tribal knowledge won't have to do this all over again.

73's,
Collier
NM7B

NM7B
dtd. is gone after mesh IP address change

Thank you for the responses!   I will download the support info on Monday for the two nodes that conflicted.  I'll keep the tactic of changing the number of host assignments as an ace up the sleeve.  I did read that suggestion while debugging this issue, but didn't get a chance to try this method.

The dtd. instance disappeared once I resolved the mesh IP address conflict so I suspect it was a product of the mesh IP conflict. 

Collier

VA2RLM
Duplicate IP again

Hi,

Don’t like to do the “me too” thing but just finished installing a TP-LINK CPE-610 with the same WiFi IP address as a Ubiquiti NanoStation M5 previously installed on our network.

The WiFi IP address was changed on one of the nodes as suggested in this thread. But since the TP-LINK is also collocated with a Ubiquiti NanoBridge 2.4, I’m noticing the DtDlink isn’t working. I suspect this may be caused by the duplicate dtdlink IP address mentioned in this thread. 

I've included the support data from both nodes, if that helps.
 
Any suggestions would be appreciated.

Thanks,

….Luc

AE6XE
AE6XE's picture
Luc,  I suspect a browser has
Luc,  I suspect a browser has saved an IP address and applied it across nodes.   These 2 devices have different MAC addresses and the algorithm doesn't appear that both should have ended up with the same IP address.  

Do a quick test... in Basic Setup, click on 'default values', but don't 'save'.  What IP address shows on both nodes?

Joe AE6XE

 
VA2RLM
As you expected

Joe, as you expected, the IP addresses are different than what was configured. 

I wasn’t around when these nodes were initially configured but believe you are right about the browser’s involvement. Regardless, they are no longer conflicting and the DtDlink is at 100% between the collocated nodes.

Thank you,

…luc​
VA2RLM 

k1ky
k1ky's picture
Duplicate IP

If the above suggestions don't yield a different result and the nodes really are on the same IP addy, you can change the LAN Mode Host settings in setup to something different, 1-host, 5-host, 13-host - this will put the node in a whole different range.
 

VA2RLM
Will keep this in my bag of tricks


Tom, I didn’t need to try this but will keep it in mind, for the next time. smiley

Thanks

…luc
VA2RLM

kj6dzb
kj6dzb's picture
AE6XE I see that you can edit
AE6XE I see that you can edit /etc/local/uci/hsmmmesh to modifiy the mac for the wlan interface. Were dose 

config eth0
option macaddr 'xx:xx:xx:xx:xx:xx'

get placed to change the eth0 mac adress?
AE6XE
AE6XE's picture
That nvram code is very old
That nvram code is very old from linksys days. I've not looked at this code in a few years, so I'm not sure if it is in use on the newer hardware. Also, it may only be relevant on firstboot to derive IP address, then ignored as the IP can be manually set. The only place to set eth0 is in the /etc/config/network file. To make permanent, would be wiped out when saving settings, the change is made in /etc/config.mesh/ files. But not preserved with a firmware sysupgrade.

Theme by Danetsoft and Danang Probo Sayekti inspired by Maksimer