@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.
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.
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?
@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.
@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.
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.