Brainstorming on new setup_priority::VPN

[droscy]

In order to have mqtt working through wireguard tunnel we have to change the available setup priorities. This may affect any other component that uses AFTER_WIFI.

The patch suggested by @bgamari here bgamari@ec905b6 is wonderful but I don't think it can be introduced in ESPHome through wireguard because it is "core" and not directly related to wireguard.

I suggest creating a PR to official ESPHome repo with the following changes:

1. add VPN and CONNECTION (as done in the commit)
2. reduce priority of AFTER_WIFI (as done in the commit, rising float value)
3. change to CONNECTION the priority of any component that establishes a remote connection and that currently has priority set to AFTER_WIFI (mqtt is one, but can be others)

So we have the scaffold for wireguard, where can_proceed() can return true only after having reached the remote peer (as described here esphome#4256 (comment)).

What do you think? @lhoracek, @bgamari, @thomas0bernard

Backref:

• Wireguard component esphome/esphome#4256 (comment)
• WireGuard Support for ESP32 esphome/feature-requests#1444

[lhoracek]

I would definitely leave this for later development

[droscy]

But simply setting wireguard priority to BEFORE_CONNECTION would allow MQTT to works correctly?

It should because WiFi component blocks the setup step until the connection is esablished so during BEFORE_CONNECTION the WiFi is ready. In this way the MQTT client (that has AFTER_WIFI, that is after BEFORE_CONNECTION) should find wireguard already ready.

Do you agree? @bgamari, @thomas0bernard

[thomas0bernard]

But simply setting wireguard priority to BEFORE_CONNECTION would allow MQTT to works correctly?

It wouldn't, because the SNTP component is set to AFTER_WIFI too. I'm not quite sure why, but the MQTT component blocks the setup until it's connected (contrary to this WG component, and not blocking seems much better). SNTP and MQTT have the same setup priority but are still setup sequentially, in my case it seems like MQTT goes first because it would block the entire setup process before the trace for the SNTP setup would show up.

And since we need time sync for WG, the whole thing doesn't work.

[droscy]

It wouldn't, because the SNTP component is set to AFTER_WIFI too.

Yes, you are right.

I have coded a sort of workaround that requires, however, the change of SNTP priority, but if you like this solution I can send the PR for SNTP.

This is the workaround: the priority of wireguard has been increased to BEFORE_CONNECTION and the new boolean parameter require_connection_to_proceed has been added. If you set that parameter to true the setup step will freeze after wireguard until remote peer is connected.

Could you test it from ft/wg/priority branch?

external_components:
  - source:
      type: git
      url: https://github.com/droscy/esphome
      ref: ft/wg/priority
    components:
      - wireguard

wireguard:
  address: 172.16.34.100
  netmask: 255.255.255.0
  [...]
  peer_allowed_ips:
    - 172.16.34.0/24
  require_connection_to_proceed: true

mqtt:
  broker: 172.16.34.5
  [...]

Of course you have to manually change the priority of SNTP (line 25 of file esphome/components/sntp/sntp_component.h

[thomas0bernard]

Could you test it from ft/wg/priority branch?

It works, with the SNTP priority set to BEFORE_CONNECTION, either with or without require_connection_to_proceed.

But, I like the addition of this parameter, since it prevents from trying to resolve the MQTT broker's address before WG is connected. My use case resolves that with a local DNS that is only available after WG is connected, so I appreciate that!

[droscy]

@thomas0bernard could you test again? I've merged the defer commit 3ad58c5, just to be sure it works.

[thomas0bernard]

Everything works for me!

[droscy]

The change to sntp has been merged and I merged the new parameter to wireguard/dev, could you test please?

external_components:
  - source:
      type: git
      url: https://github.com/droscy/esphome
      ref: wireguard/dev
    components:
      - wireguard
      - wireguard_status
      - wireguard_handshake
      - sntp  # don't forget sntp here!

[thomas0bernard]

Tested arduino and idf again, all good for me.

[droscy]

Code merged to official PR, I'll this issue.

Thanks @thomas0bernard for your tests.