HA: How to flush stale device name resolutions? (old addresses)

ESPHome
1

I have an OpenWRT router, DHCP leases are stored in RAM and won't persist a through a power outage. Once power is restored, everything - including ESPHome devices - starts afresh, and gets back to work.

Well, everything except HA. Though I can't find this behaviour documented, it seems HA (the ESPhome integration at least?) won't re-resolve the name when the old IP is active. This is a problem when everything reboots: inevitably some devices will get assigned previously used IP addresses. It seems HA simply pings the (stale) address and erroneously concludes the name resolution is still valid when it's not.

I appreciate there are a lot of broken networks out there and hence the oft-quoted advice is to just statically assign everything, but it'd be nice if HA at least cleared out the name resolution cache on boot; or better did some kind of device fingerprint to check for reallocated IP addresses. ("PRs welcome"?)

Is there some way "flush the name cache" manually? i.e. force HA to re-resolve all device names?

Aside: router reboots alone aren't a problem as the client address persists, and typically the DHCP client will request a renewal of their lease and the router/DHCP server obliges and records the lease. The issue is when the entire LAN - incl. the HA server - restarts at the same time.

A related (unresolved) thread: Why does HA depend on devices having static IP addresses?

1 Like
2

I also have a OpenWRT router (GL-XE300) and it has the option to assign static IP for DHCP leases. When i add a new device i reserve the devices IP address under static leases.

1 Like
3

Furthermore, the way DNS works is that a device will request its previous IP by default.
Up to the server to decide, ofc, but that will work upon a router reboot.

ESPHome specifically uses the mDns way. It's a kind of serverless dns, where ".local" names are used. ESPHome basically brodcast "is <my_device>.local around?", and the device itself reply with it's IP address.

No clue when ESPHome refreshes its cache, but I'm pretty sure a restart will flush it, anyways.

4

Same here; OpenWrt, etc.
This syndrome seems to be most notable with ESPHome devices - I have about 30 of them.

After a whole-house restart (e.g. after power outage) is when HA seems to get confused.

The router (DHCP server) loses its knowledge of DHCP leases (they were in /tmp), so as devices come back up they usually end up with a different IP addr.

HA then comes along and it has its memory of past addresses (in one of the files in .storage), and gets upset when the device it's expecting is not at the IP it used to have. Is worse when a completely different device is at that addr.

5

Dynamic = changeable. Not often desirable.

If your router startup sequence is asked by the same devices in the same sequence for IP Adresses, it will consistently offer them up reliably in the 'correct' sequence and you will be blissfully unaware of the behind-the-scenes operation of DHCP, which allocates the next available IP Addresses based on availability. If the IP Address you got last time via DHCP has been snaffled by another device, you get a new, DIFFERENT one this time. Cope with that how you may, often your higher level software expecting consistency can't.

Foresight and planning, knowing each and every device on your LAN, and allocating an IP Address for each of them statically so it is expected and reliably consistent, and allocated swiftly by the network seems like a prudent approach.

You don't have to rely on the added overhead of the correct functioning of Multicast DNS (mDNS) to respond to queries over the LAN for each device to identify itself.

Did I say it was faster?

Whether you preallocate fixed (Static) IP Addresses on your router for each device MAC in the DHCP configuration section, or hard code the in the ESPHome code as well, problem troubleshooting becomes easier, as you now know what IP Address to expect your device at, one less unknown in your list to cross off.

Of course leave a few addresses in your DHCP range to allow for new and unplanned devices, but for the majority of your LAN, I strongly recommend pre-allocation, and a host of issues where you are not sure if caches need to be flushed (at overhead and delays), config files need to be manually updated, and other random unknowns just aren't an issue any more.

Static IP FTW!

6

If you tell it what IP Address in the configuration of the router (see the DHCP section to pre-allocate static/fixed addresses), save that configuration (and desirably make a backup), you should find the issue is no more as it will reload your router configuration as it reboots (by design). For device addresses that are being requested, it will allocate the next available one if it hasn't been preallocated already. This may be different from last time it did this, hence the opportunity for confusion where some devices are addressed by name (mDNS) and others by their configured (or cached) IP Address.

7

This can be over-ridden by specifying the corresponding IP Address you have carefully planned for and have a slot waiting for in your router configuration, so it doesn't have the added overheads of plug-n-pray that mDNS has.

Why should you have to worry if mDNS is working on your LAN? Bypass it altogether.

8

I'm very old-school - having grown up on the Internet in the 80's - thus a firm believer in the principle behind DNS: that a host should lookup a destination's address by NAME first.

It may then choose, depending on its purpose, to cache the learned IP addr for efficiency (until it encounters an error) but should never presume the IP to be static.

Farting around having to make destination IP's static is what led to the invention of DNS over 40 years ago.

Who phones their friends by typing in the phone #?

I did statically assign IP's to most of my devices for a while, but it became tiresome.
A proper system should be able to tolerate IP addrs that change, as long as the DNS name leads to the right host.

9

A common misunderstanding: mDNS is not DNS. Both have their place, and are oh so convenient when they work.

The added overheads and issues where both mechanisms don't work as expected is one of the more common reported problems in these forums, especially by neophytes.

"Farting around" still involves getting their name to be associated with their number. Preallocation (putting it in your contacts on your phone, or your DHCP lookup table on your router) is done once and for all. My phone. My network. My decision. My control. No external unknown factors to keep me guessing, reliant on, or have to add to my burden of troubleshooting when things go wrong. I'm old school too - I absolutely, definitively, positively hate things that change and I don't know why.

Dynamically looking it up (doing a Google search by your friends name to call them each and every time, knowing they don't change their number often) seems like a vastly inefficient approach. This is what mDNS is doing behind the scenes, and what you appear to be advocating.

I'm polite - my network farts rarely!

10

It seems there are differences of opinion on the right way to assign addresses using DHCP. After looking at the docs for OpenWRT, it doesn't seem easy to do what you want.

In your situation I would invest in a cheap UPS for the router. That way you avoid the problem.

Or, get a router that has a different implementation of DHCP and remembers all the leases it has or has a deterministic method of assign addresses based on the MAC so they generally get the same IP address.

11

I think making the router run non-stop would be a band-aid, and does not solve the root cause.

Everything needs to be able to be restarted from time to time, and doing so should have as few side-effects as possible, if one designs their system integrations properly.

Yes, I know how to make DHCP reservations, and all that. Been there, done that.

But no one should have to do so just to satisfy a poorly-implemented lookup algorithm in one module on one app.

Nameservices are there for a very old reason, and wherever possible, systems should use them.

12

Yes, why have DHCP at all? Fix the addresses for reliability and consistency.

Saving the router configuration so it consistently loads it at startup may be a better approach.

The network device supplies its' MAC as part of the connection request to get allocated a network address. The DHCP process on the router as part of the response checks if that is in the table of preallocated MAC numbers (Static IP Address) and if so, immediately returns the corresponding IP Address to satisfy that address. If not, it grabs the next available one (the Dynamic bit), sends that back in the response, and crossed it off the pool of available ones so no other device gets that address. The requesting device then uses that address to set up sessions and communicate over the network. If it can't, IT has a problem.

You seem to hint at possible variations - I'm not aware of any other flavors of DHCP out there that may use a different algorithm. By convenience, IP allocation is done by the same router you connect to your home internet connection. It can be turned off and done by other devices on the network too.

On my network, my PiHole box performs the role of DNS lookup as well as a sinkhole for undesirable DNS Names. My router is still responsible for a mix of dynamic as well as static IP allocation, as per my requirements and carefully planned design. For guests and devices with unknown MACs, they are shunted to where they can do less harm.

13

Let me introduce you to the concept of fixed IP Addresses recently introduced to remove the need for DDNS, mDNS, DNS altogether.

It's called IPv6.

Been around since oh, about 30 years ago. The possibility to allocate an unique IP Address to nearly every atom in the known universe. Solves a lot of workarounds and cobbled together mechanisms where hope and best endeavours is the overriding criteria. Rosary beads optional. Plug-n-pray.

The arrival of Matter has finally forced people out of the NAT world to adopt it and rid themselves of this scourge that is the IPv4 world of lookups, substitutes and futzing around.

Still, we can't seem to get that to work well either - see how many problems reported here on the forums that boil down to configuration issues with IPv6 stopping Matter from communicating.

Oh well, gives us something to earn a living when we fix broken things for others, or go and read the manuals for ourselves. If only we could find a shortcut that works consistently and reliably - oh wait...

14

I know :slight_smile:

2: enp1s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP qlen 1000
    inet6 fdc4:5ed1:4fe6:c776:46a5:be09:1e5e:538b/64 scope global temporary dynamic
       valid_lft 1656sec preferred_lft 1656sec
    inet6 fdc4:5ed1:4fe6:c776:c3f7:8c8d:450:6fb1/64 scope global temporary deprecated dynamic
       valid_lft 1656sec preferred_lft 0sec
    inet6 fdc4:5ed1:4fe6:c776:6a1d:efff:fe43:334/64 scope global dynamic mngtmpaddr
       valid_lft 1656sec preferred_lft 1656sec
    inet6 fe80::6a1d:efff:fe43:334/64 scope link
       valid_lft forever preferred_lft forever

Do I need to say more :smiley:
(and that one doesn't even have an actual public IPV6)

15

30 years and they still can't get two devices across a room to communicate reliably.

My rosary beads are far worn.

A sad reflection on the industry.

16

I know, because I'm in the industry as well.
Common people have mostly no clue about this stuff, as much has I have mostly no clue how my car work :wink:

17

The point is it is a computer industry. Computers are supposed to be smart. White men in white coats in an air-conditioned room with false floors are from last century. I have more computing power in my phone than my entire county did thirty years ago.

Did your mother ever sit you down and teach you how to make a phone call? Did you read the instruction book that came with your phone on how to do it? (Hint: that section never existed)

It was intuitive. You just picked up the handset and dialled the number. When the other party answered you talked. When you finished, you just put the handset down. No codes to dial to end the call. If it didn't work, you got the phone company to fix it. No questions asked.

You didn't have to know about 48volts, superimposed tones at 1200 baud, SS7 signalling, what exchange you connected with and the such like. You just plugged it in and it worked. Yes, area codes was a challenge early on, but they fixed that by adding more numbers until the phone book (remember those?) got too fat to carry inside without a forklift.

I still can't watch a video on my Samsung phone, point it towards my Samsung TV in a determined fashion and get it to automagically show the picture there. Yes, I understand all the subsystems (intimately), but it still doesn't work reliably. The point is, it should.

You turn the key. Your car starts. If it doesn't you speak to a mechanic or the dealer. You dont know about 14.4volts DC, gear ratios, oil grades, CANBus, acceleromters, ECUs, etc. You shouldn't need to. Yes, it has four tyres, one in each corner, but do you need to know where the sump plug is to change the oil?

Networking? Laughs wickedly. Your great grandchildren will be begging for a good connection, humbly because it is still a black art. The point is, it shouldn't be.

Physician, heal thyself. Just because it can be complicated doesn't mean it should be. A pox on all your bytes!