IP Address Conflict(s) detected

@mentalinc, both the receiver (Denon AVR-X1400H) and the TV (LG G3) has separate MACs according to the devices info in the devices list.

I noticed a copy paste error in my post above, which I corrected some minutes ago. I have the LG TV set as two static IPs for the WLAN and LAN, connections respectively.

Does the DHCP range overlap with the static IP?
If so, the Route10 is probably handing out a dynamic Ip, not knowing you have the static IP assigned.

Static reservations up to .15, and DHCP for .15 to .28. So it should’nt be that either. The TVs LAN and WLAN set for static IP on .12 and .13, respectively (chosen to be able to set a .12/31 firewall rule). Static IP is set on Route10-side.

I’m also seeing this

Note: IP Address Conflict(s) detected

This is typically caused by a DHCP pool that is too small, or misconfigured static IPs, and will cause intermittent connectivity. Only a few can be shown here, but there may be more.

192.168.11.23: REDACTED_1 REDACTED_2

Some info that may or may not be helpful:

  • I have no static IPs on that subnet
  • DHCP lease is set to the default
  • Apart from the Route 10, all network hardware is Ubiquti
  • DNS is from a PiHole
  • I’m running self-hosted Alta controller on Kubernetes running 1.1a, the Route10 is on 1.4f
  • The devices are a Garmin Edge GPS unit and some Withings/Nokia scales

@mentalinc
I experience the problem to be on wireless devices only. Phones and computers configured with DHCP. I never experienced the IP conflict on Static IP addresses so that may be different from @ebuckland81.
My DHCP Guard is disabled because there is only one DHCP server in the system.
Further the IP conflict is over the whole DHCP range.

@Alta-Jeff But now for 2 days it has gone quiet. No IP conflicts. Has there been any further testing on my system or it just had a good weekend?

I assume the 2 days quiet is due to the weekend in the US.

@mentalinc I guess it is weekend everywhere.
No I mean that the IP conflicts has stopped during the last 2 days.
I do not know why or what has been changed. We will see when there is more devices connected again during the week.

1 Like

@Alta-Jeff
I was a little too optimistic that something has resolved it self. But today when there was a few more gadgets in the house I got a new IP address conflict.

So the issue is still there and needs some investigation.

I’m also having the problem with the letsencrypt cert expiring. I’m going to post this separately too as this thread looks mostly like a separate issue.
Running manually I see

root@891cd3aaf0f1:/etc# su - alta -c 'cd /usr/share/access/be && ./uacme.sh'
uacme: version 1.7.1 starting on Fri, 04 Jul 2025 05:41:25 +0000
uacme: loading key from /var/lib/access/certs/serroqk1g7b/private/key.pem
uacme: loading key from /var/lib/access/certs/serroqk1g7b/private/serroqk1g7b.ddns.manage.alta.inc/key.pem
uacme: checking existence and expiration of /var/lib/access/certs/serroqk1g7b/serroqk1g7b.ddns.manage.alta.inc/cert.pem
uacme: /var/lib/access/certs/serroqk1g7b/serroqk1g7b.ddns.manage.alta.inc/cert.pem expires in -7 days
uacme: /var/lib/access/certs/serroqk1g7b/serroqk1g7b.ddns.manage.alta.inc/cert.pem is due for renewal
uacme: generating certificate request
uacme: fetching directory at https://acme-v02.api.letsencrypt.org/directory
uacme: retrieving account at https://acme-v02.api.letsencrypt.org/acme/new-acct
uacme: account location: https://acme-v02.api.letsencrypt.org/acme/acct/2062333427
uacme: creating new order at https://acme-v02.api.letsencrypt.org/acme/new-order
uacme: order location: https://acme-v02.api.letsencrypt.org/acme/order/2062333427/402392586291
uacme: retrieving authorization at https://acme-v02.api.letsencrypt.org/acme/authz/2062333427/546926029481
uacme: running /usr/share/access/be/uacme-hook.sh begin dns-01 serroqk1g7b.ddns.manage.alta.inc OTY64ZLEHFoiX08Imq7IYqE5bciwxXerj21rqMK5d_c S7RUhrI6c6O36tcJMZlp8JqE21MkMUa5qs5oXFaxQ6U
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100   150  100    11  100   139      5     74  0:00:02  0:00:01  0:00:01    79
"No device"uacme: starting challenge at https://acme-v02.api.letsencrypt.org/acme/chall/2062333427/546926029481/mFmJuQ
uacme: polling challenge status at https://acme-v02.api.letsencrypt.org/acme/chall/2062333427/546926029481/mFmJuQ
uacme: polling challenge status at https://acme-v02.api.letsencrypt.org/acme/chall/2062333427/546926029481/mFmJuQ
uacme: challenge https://acme-v02.api.letsencrypt.org/acme/chall/2062333427/546926029481/mFmJuQ failed with status invalid
uacme: the server reported the following error:
{
    "type": "urn:ietf:params:acme:error:unauthorized",
    "detail": "Incorrect TXT record \"Of8WyJzD40LfYFkysLduT2ixuk_oPOXZ-OK6Rum4olA\" found at _acme-challenge.serroqk1g7b.ddns.manage.alta.inc",
    "status": 403
}
uacme: running /usr/share/access/be/uacme-hook.sh failed dns-01 serroqk1g7b.ddns.manage.alta.inc OTY64ZLEHFoiX08Imq7IYqE5bciwxXerj21rqMK5d_c S7RUhrI6c6O36tcJMZlp8JqE21MkMUa5qs5oXFaxQ6U
uacme: failed to authorize order at https://acme-v02.api.letsencrypt.org/acme/order/2062333427/402392586291

The ā€œNo deviceā€ message indicates that our cloud does not recognize your controller’s ID, so we need to start there. If you can invite me to your controller, I should be able to get into it remotely and take a look at the logs for your controller’s ID. I do see an ID for your controller, but I need to look at the logs to confirm there is a match.

At one point I tried reinstalling the controller docker image, but went back to my older version. Would that explain my problem with the mismatched IDs?

Yes, the cloud assumes you’ll be using the most recently assigned ID for that specific controller license. If you need me to reset something, DM me and I can try to grab your ID and reset it.

2 Likes

Letting people know that fixed my problem. Thanks Jeff.

5 Likes