App Not Resolving IP on Wifi but does on VPN

The Situation:

Home Assistant Companion app does not resolve the IP when on home wifi, even though from the same phone HA is accessible via the Chrome app and the Edge app.

If I turn off wifi and connect to my home VPN the app resolves the ip and connects fine.

The Setup:

HA is running in docker behind Traefik with a Lets Encrypt SSL Cert.
PfSense DNS resolver holds the DNS records. pihole is the DNS server used by the phone and is using PfSense as the upstream DNS server

What I have tried:

  1. Remove pihole and use PfSense as the DNS directly (didnā€™t work)
  2. Disable ā€œPrivate DNSā€ in Android Settings (didnā€™t work)
  3. Install HA Companion app on another phone to test (works)

Device Info

Primary Phone:

Pixel 7 Pro
Android Version: 14 (Build AP1A.240305.019.A1)
Installed app from Google Play Store
Version: 2024.1.5-full

Test Phone

Pixel 5
Android Version: 13 (Build TP1A.221105.002)
Installed app from FDroid
Version: 2024.1.5-minimal

Logs

This log (domains replaced with example.com) is from my primary phone after connecting to the VPN to setup the app, then trying to open it again after connecting to the wifi and turning the VPN off.

I think this is the pertinent log line

03-23 20:25:44.856 16954 16954 E WebviewActivity: onReceivedError: errorCode: -2 url:https://ha.example.com/?external_auth=1
03-23 20:25:44.805 16954 17005 D SensorWorker: Updating all Sensors in foreground.
03-23 20:25:44.805 16954 16954 D ServerConnectionInfo: localUrl is: false, usesInternalSsid is: false, usesWifi is: true
03-23 20:25:44.805 16954 16954 D IntegrationRepository: isAppLocked(): false. (LockEnabled: false, appActive: false, expireMillis: 0, currentMillis: 1711239944805)
03-23 20:25:44.805 16954 17005 D ServerConnectionInfo: localUrl is: false, usesInternalSsid is: false, usesWifi is: true
03-23 20:25:44.816 16954 16954 I WM-SystemFgDispatcher: Started foreground service Intent { act=ACTION_START_FOREGROUND cmp=io.homeassistant.companion.android/androidx.work.impl.foreground.SystemForegroundService (has extras) }
03-23 20:25:44.820 16954 16954 D ServerConnectionInfo: localUrl is: false, usesInternalSsid is: false, usesWifi is: true
03-23 20:25:44.820 16954 16954 D ServerConnectionInfo: Using external URL
03-23 20:25:44.820 16954 16954 D ServerConnectionInfo: localUrl is: false, usesInternalSsid is: false, usesWifi is: true
03-23 20:25:44.820 16954 16954 D ServerConnectionInfo: Using external URL
03-23 20:25:44.836 16954 16954 I cr_A11yState: Enabled accessibility services list updated.
03-23 20:25:44.838 16954 16954 I cr_A11yState: Informing listeners of changes.
03-23 20:25:44.838 16954 16954 I cr_A11yState: New AccessibilityState: State{isScreenReaderEnabled=true, isTouchExplorationEnabled=false, isPerformGesturesEnabled=true, isAnyAccessibilityServiceEnabled=true, isAccessibilityToolPresent=false, isSpokenFeedbackServicePresent=false, isTextShowPasswordEnabled=true, isOnlyPasswordManagersEnabled=false}
03-23 20:25:44.856 16954 16954 E WebviewActivity: onReceivedError: errorCode: -2 url:https://ha.example.com/?external_auth=1
03-23 20:25:44.858 16954 16954 D ServerConnectionInfo: localUrl is: false, usesInternalSsid is: false, usesWifi is: true
03-23 20:25:44.860 16954 16954 D CompatibilityChangeReporter: Compat change id reported: 232195501; UID 10294; state: DISABLED
03-23 20:25:44.872 16954 17005 D ServerConnectionInfo: localUrl is: false, usesInternalSsid is: false, usesWifi is: true
03-23 20:25:44.874 16954 17005 D ServerConnectionInfo: localUrl is: false, usesInternalSsid is: false, usesWifi is: true
03-23 20:25:44.878 16954 17005 E SensorReceiver: Error while getting core config to sync sensor status
03-23 20:25:44.890 16954 16954 D CompatibilityChangeReporter: Compat change id reported: 280005585; UID 10294; state: DISABLED
03-23 20:25:44.921 16954 17005 D SensorReceiver: Nothing to update for server 1 (Home)
03-23 20:25:44.921 16954 17005 I SensorReceiver: Sensor updates and sync completed
03-23 20:25:44.921 16954 17007 I WM-WorkerWrapper: Worker result SUCCESS for Work [ id=fd2f6ec9-f3e8-473c-a2fd-02b567a4c25a, tags={ io.homeassistant.companion.android.sensors.SensorWorker } ]
03-23 20:25:44.947 16954 16954 I WM-SystemFgDispatcher: Stopping foreground service
03-23 20:25:45.507 16954 17212 D ProfileInstaller: Installing profile for io.homeassistant.companion.android
03-23 20:25:46.914 16954 16954 W WindowOnBackDispatcher: sendCancelIfRunning: isInProgress=falsecallback=android.app.Dialog$$ExternalSyntheticLambda2@8d186c3
03-23 20:25:46.917 16954 17069 D HWUI : endAllActiveAnimators on 0xb400006f03094e50 (RippleDrawable) with handle 0xb400006f5307cf70
03-23 20:25:46.922 16954 16954 D IntegrationRepository: setAppActive(): false
03-23 20:25:46.923 16954 16954 D IntegrationRepository: set

Here is a screenshot of the app when it is not working
You can see the ERR_NAME_NOT_RESOLVED error in the background.

Seems similar to this thread but was no solution posted

Any thoughts/suggestions would be appreciated I have been banging my head against this for a couple of weeks.

Have you tried?:

You have two DNS servers? Why?

1 Like

All problems are name resolution problems until proven otherwise.

This issue is screaming that one of these resolver infrastructures is not configured correctly. But Iā€™m with Max split DNS is hard enough as is. Donā€™t complicate it further. Pick one.

Looking at the log you need to configure your internal SSID name so the Companion App knows when to use the local connection settings.

@MaxK I have done those troubleshooting steps a couple of times and just did them again for good measure. No change.

Couple of reasons pihole is not used by all the users on my network mainly so that if I am working/playing with the servers I do not take the network down for the rest of the family. Also I use domain names to get to all the admin interfaces for the servers and if pihole is down then would not be able to make use of those urls (would have to resort to IPs)

Given the above my first troubleshooting step was to point my phone to PfSense directly and that does not make a difference.

I guess after thinking about this some more my question would be:
How is the App resolving DNS different than chrome on the same phone?
Accessing HA from the browser on my phone works fine. Just not the app.

@NathanCu Hope the above clarifies why I have it setup the way it is.

Martin,
I am using a FQDN internally with valid Lets Encrypt SSL cert. So from what I can tell there is no reason to use the internal connections settings as the URL will always be the same regardless of how I am connecting to the instance.

The setup works fine on my other phone.

Under settings > companion app > servers and devices (name of your server) > connection info.

Does the internal connection url and home assistant url look right?

Ok so I figured it out.
I had noticed before a fe80 IPv6 address in the DNS server list on the phone and thought nothing of it as I have IPv6 disabled in PfSense. So used to seeing link local IPv6 IPā€™s in other places didnā€™t really think it was strange.

Turns out an OpenWrt device I have in client mode was advertising DNS.
Turned that off and now all is well.

Guess I should have uploaded a screenshot of the network info and you all would have probably caught it.

Hopefully this helps someone in the future.

All that said, is it a bug that if the first DNS server does not give a positive response it tries another? or I guess it is responding just saying I donā€™t have an IP associated with that domain.

Thanks for the help. ā€œItā€™s always DNSā€ just not always easy to find lol

1 Like

It should try all DNS servers in its name resolver list in order until a positive result (either positive hereā€™s your host or a ā€˜positiveā€™ Iā€™ve already looked that up and it doesnā€™t exist until TTL-hh:mm) or an exhausted list of responders.

This is exactly why all of your DNS resolvers must always agree on the destination in any given network and multiple DNS resolvers starts getting dicey.

Glad you found it and yes a dump of the network would have caught it right off.

1 Like