esp_wireguard icon indicating copy to clipboard operation
esp_wireguard copied to clipboard

Compatibility with esp_modem?

Open smartinick opened this issue 2 years ago • 5 comments

Sorry that i'm missusing an Issued to ask a question!

I've been trying to get wireguard running over via sim800/sim7000 GSM/LTE Modems and to run mqtt (not via http bit via native protocol) over the wireguard tunnel.

My old solution uses arduino-libs, e.g. tinygsm and pubsubclient which both do not work with wireguard. (Pubsubclient needs a client object in it's initializer which could be wifi client or gsmclient, but not (arduino-)wireguard, and the arduino-wireguard tunnel will not run over tinygsm links).

As this (and the Arduino "version" of wireguard) uses lwip, bit tinygsm client does not I guess the trick is to switch to espidf and libs that use lwip.

So I came to the idea that using esp_modem for the PPP link and this wireguard lib here I should have a basis to use an lwip aware mqtt client.

But I've no idea about lwip interfaces, routes,.... IMHO my guess would be that wireguard registers a lwip interface (https://github.com/trombik/esp_wireguard/blob/a441e52b5a117f3dc3caa01376726d9dc9331192/src/esp_wireguard.c#L185) and somehow the default-route is applied to it. But on the other hand the esp_modem would like to do the same, but there's no netif_add in it's code (https://github.com/espressif/esp-protocols/tree/master/components/esp_modem) and there's no hint about adding routes?

So both interfaces would need to be daisy-chained from a routing point - wireguard if should be default gateway, but it should have a route that forwards everything to the PPP interface.

But how could this be accomplished? I'm thankful for any hint as I'm stuck.

Thanks and Best Regards, Martin.

smartinick avatar Jan 05 '23 10:01 smartinick

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.

trombik avatar Jan 10 '23 23:01 trombik

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.

smartinick avatar Jan 15 '23 10:01 smartinick

@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.

trombik avatar Jan 18 '23 09:01 trombik

Hi, I succefully run esp_wireguard with v5.2.2 and esp_modem (sim700g) to do that you need to:

  • enable LWIP_PPP_SUPPORT as suggested by https://github.com/trombik/esp_wireguard/issues/33#issuecomment-1568503651
  • change wifi hardcoded ifkey "WIFI_STA_DEF" to "PPP_DEF" at this line: https://github.com/trombik/esp_wireguard/blob/5f9d5a0ec7431fcac362ed67576c3fa32d3bcc34/src/wireguardif.c#L914

ceccocats avatar Jun 06 '24 19:06 ceccocats

That's a great find. I'm still in a difficult situation. If you have a patch, it would be more than welcome.

trombik avatar Jun 07 '24 14:06 trombik