Compatibility with esp_modem? about esp_wireguard HOT 5 OPEN

a very interesting configuration. i'm not an expert of lwip, but my understanding is that lwip does not support a routing table as you normally expect on U*nix machines. haven't looked at esp_modem code yet, but i guess you would need some modifications in esp_modem first?

esp-idf version 5.x introduced more abstractions into esp-netif. i'm thinking about porting esp_wireguard to esp-netif so that the library does not depend on the underling TCP/IP layer. however, that is a major change.

from esp_wireguard.

Hi,

i did some more reading on this issue in the context of lwip.
there's 3 takeaways i'll investigate the next time (the esp32 is in a remote location, will be there in ~3 weeks again for some days).

1. lwip allows to set a default interface - i think the wireguard-tunnel-if should be the default one.
2. there's some sort of priority number for each interface, but i guess this will be overrided by the default interface setting from pervious point
3. lwip will always look if there's a interface having an ip in the destination-network and use this interface (like in most other ip stacks, but that's not routing, and lwip has no routing)
4. this could be the key to get the wg-tunnel-data that should take the default-route via the lte/gsm_modem connection: lwip seems to allow to bin a outgoing socket to a interface.

So my theory is: set wg-tunnel-if as default (or use the priority). Packets that have a destination ip that is unknown should go into the tunnel. (aka "default route", but we have no routing here...)
And the tunnel-packets should be sent through the lte/gsm_modem interface, and that might be solveable by binding the wireguard-outgoing socket(s?) to the lte/gsm_modem interface.

But this is all theory so far - i don't have a esp32 with simxxxx here, only on the remote location, so this will take a while.
but i can update this issue with my findings, and in case the idea i have works, this might end in modifying the wireguard code here as well to add a begin/initializer that allows binding the outgoing tunnel-sockets to another netif.

regarding your last paragraph (porting esp_wireguard to esp_netif) - but even in that case, there's no routing in lwip and in my scenario the wg-tunnel must be forced to go the gsm_modem "route" somehow while having the "default route" on the wg-tunnel, so everything like mqtt,... that is used goes into the tunnel.

from esp_wireguard.

@smartinick great findings. as Issue #33 is not fixed, try esp-idf v4.x if you want to go further. v5.x will not work.

from esp_wireguard.