Connection Error after changing DNS

[oerix]

When I changed the DNS servers on the router from the default ISP dns to 1.1.1.1 and 8.8.8.8, the integration no longer works. The credentials are correct and have not been changed despite what the log says. I've tried reboot HA/removing and re-adding the integration, but it hangs on 'Checking credentials' screen.

It throws the following connection error in the logs:

Logger: homeassistant.config_entries
Source: config_entries.py:749
First occurred: 13:46:19 (1 occurrence)
Last logged: 13:46:19

Error setting up entry Linksys Velop Mesh for linksys_velop: init_connection_error
Traceback (most recent call last):
  File "/config/custom_components/linksys_velop/__init__.py", line 132, in async_setup_entry
    valid_auth: bool = await mesh.async_test_credentials()
                       ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.13/site-packages/pyvelop/mesh.py", line 1478, in async_test_credentials
    await self._async_make_request(action=api.Actions.CHECK_PASSWORD)
  File "/usr/local/lib/python3.13/site-packages/pyvelop/mesh.py", line 277, in _async_make_request
    raise err from None
  File "/usr/local/lib/python3.13/site-packages/pyvelop/mesh.py", line 275, in _async_make_request
    req_resp = await req.execute(timeout=self._mesh_details.request_timeout)
               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.13/site-packages/pyvelop/jnap.py", line 198, in execute
    raise MeshConnectionError from None
pyvelop.exceptions.MeshConnectionError: Connection Error

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "/usr/src/homeassistant/homeassistant/config_entries.py", line 749, in __async_setup_with_context
    result = await component.async_setup_entry(hass, self)
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/config/custom_components/linksys_velop/__init__.py", line 147, in async_setup_entry
    raise ConfigEntryError(
    ...<6 lines>...
    ) from exc
homeassistant.exceptions.ConfigEntryError: init_connection_error

[uvjim]

Does it work again if you change the DNS addresses back?

The error message isn't saying that your creds are incorrect. It's attempting to test your credentials and will send you down the reconfigure route if they aren't. However, it's getting a connection error when trying to test the credentials. In this case it's getting a connection error when trying to use the API.

How did you set the integration up? I assume it's using the IP for the primary node.

[oerix]

Does it work again if you change the DNS addresses back?

Yes, it works when reverting back to the ISP DNS.

How did you set the integration up? I assume it's using the IP for the primary node.

Correct, Primary node IP + password, with default settings.

[uvjim]

I know you've used the CLI for pyvelop before. Could you try using that and see if it sheds any further light? I'm not expecting it to. I'm not sure that there's anything I can do to fix it mind you because the integration doesn't rely on the DNS servers from the Velop for anything (well apart from normal networking stuff, but it doesn't rely on any name resolution if you're using IP addresses for everything).

[uvjim]

I should also add that I'm assuming you're setting the DNS servers as part of the DHCP settings. That may not be working the way you intend... IIRC all DHCP clients still receive the IP of the primary node for DNS purposes. All those addresses change is which servers are used by the Velop to look up addresses.

That is to say, if you were expecting each of your clients to have 1.1.1.1 and 8.8.8.8 list as DNS servers, they wouldn't.

That's why I'm having a hard time trying to work out why the connection wouldn't be resolvable with custom addresses set.

[oerix]

I know you've used the CLI for pyvelop before. Could you try using that and see if it sheds any further light?

mesh details -vvvv:

DEBUG:pyvelop.cli:Setting up logging
DEBUG:pyvelop.mesh:__init__ --> entered
DEBUG:pyvelop.mesh:__init__ --> Session was passed in: No
DEBUG:pyvelop.mesh.verbose:__create_session --> entered
DEBUG:pyvelop.mesh.verbose:__create_session --> exited
DEBUG:pyvelop.mesh:__init__ --> pyvelop version: 2024.9.1
DEBUG:pyvelop.mesh:__init__ --> Initialised mesh for 192.168.1.1
DEBUG:pyvelop.mesh:__init__ --> exited
DEBUG:pyvelop.mesh:async_test_credentials --> entered
DEBUG:pyvelop.mesh:_async_make_request --> entered
DEBUG:pyvelop.jnap:Request.execute --> entered
DEBUG:pyvelop.jnap:Request.execute --> URL: http://192.168.1.1/JNAP/, Headers: {'X-JNAP-Authorization': '**REDACTED**', 'Content-Type': 'application/json; charset=UTF-8', 'X-JNAP-Action': 'http://linksys.com/jnap/core/CheckAdminPassword'}, Payload: [], Timeout: 30
ERROR:pyvelop.mesh:local variable 'err' referenced before assignment
DEBUG:pyvelop.mesh:async_close --> entered
DEBUG:pyvelop.mesh:async_close --> exited

I should also add that I'm assuming you're setting the DNS servers as part of the DHCP settings. That may not be working the way you intend... IIRC all DHCP clients still receive the IP of the primary node for DNS purposes. All those addresses change is which servers are used by the Velop to look up addresses.

That is to say, if you were expecting each of your clients to have 1.1.1.1 and 8.8.8.8 list as DNS servers, they wouldn't.

That's why I'm having a hard time trying to work out why the connection wouldn't be resolvable with custom addresses set.

Yeh, so the DNS servers are basically proxied. It's okay, if you're not able find the root cause, these Velop routers have been nothing but problematic, will be ditching this trash in the near future, thanks regardless.

[uvjim]

The local variable issue is clearly an issue of mine rather than the Velop - I'll have to track that down and fix it once I get the stuff I've been working on finished.

I see quite a lot of bad reviews about the Velop. Personally I've not had any real issues with them. The setup was really flakey when I bought the first set of nodes, but that has gotten much better since then.

It has quirks. DHCP/DNS is one of them. However, I've offloaded that to Pi-hole (I had major issues with that when they did their latest major release, oh and this morning when it corrupted the DHCP leases).

All in all mine are all stable. Not sure I'll be upgrading them mind you - the constant chasing of faster WiFi speeds is currently lost on me because most of the services that are important are wired.

Now, if I could find a way (without running yet more wires) of getting past the dead spot that at the far front of the house (gas/electric meters are there) then that'd be great.

[uvjim]

I'll try and recreate this when I can find a suitable time to mess around with the DHCP server on the router - you can only change the DNS servers from the UI with the DHCP server enabled.