Comments (20)
trombik
commented on May 29, 2024
1
The fix has been merged intomain, which will be released later. Thank you all who contributed to fix the issue.
from esp_wireguard.
limpens
commented on May 29, 2024
I have got a use case, in which the power of the esp32 can (and will) be
cut by external means and the esp32 is not able to properly close the
wireguard connection.
Due to this, it might take up to 180 seconds for the esp32 to be able to
setup a wireguard connection. This is -as far as the documentation of the
wireguard I read explains- normal behavior.
Perhaps you should have more patience and wait for several minutes for the
connection to complete.
https://www.wireguard.com/papers/wireguard.pdf
Paragraph 6.1
Regards, Eric
…On Sat, Jul 9, 2022, 15:01 Simone Rossetto ***@***.***> wrote:
Hello trombik, I'm facing this odd behavior: if the esp device looses its
main network for whatever reason (reboot, link error, wifi change, etc), it
cannot reconnect to the wireguard server. In the dmesg I see "Invalid
handshake initiation from ww.ww.ww.ww:kkkkk"
(either if the source IP is the same or not).
In order to have the device connected again I need to remove the peer from
server with wg set wg0 peer AAAABBBB....FFFF= remove and re-add it.
It looks like a server-side bug but I don't have such behavior with other
peers (all Linux peers).
When the esp device looses the main connection I see the following in
dmesg of the server:
wireguard: wg0: Retrying handshake with peer 97 (xx.xx.xx.xx:yyyyy) because we stopped hearing back after 15 seconds
wireguard: wg0: Sending handshake initiation to peer 97 (xx.xx.xx.xx:yyyyy)
wireguard: wg0: Handshake for peer 97 (xx.xx.xx.xx:yyyyy) did not complete after 5 seconds, retrying (try 2)
wireguard: wg0: Sending handshake initiation to peer 97 (xx.xx.xx.xx:yyyyy)
wireguard: wg0: Handshake for peer 97 (xx.xx.xx.xx:yyyyy) did not complete after 5 seconds, retrying (try 3)
wireguard: wg0: Sending handshake initiation to peer 97 (xx.xx.xx.xx:yyyyy)
wireguard: wg0: Handshake for peer 97 (xx.xx.xx.xx:yyyyy) did not complete after 5 seconds, retrying (try 4)
[...]
When the esp device is online again and starts the handshake I see:
wireguard: wg0: Retrying handshake with peer 97 (xx.xx.xx.xx:yyyyy) because we stopped hearing back after 15 seconds
wireguard: wg0: Handshake for peer 97 (xx.xx.xx.xx:yyyyy) did not complete after 5 seconds, retrying (try 2)
wireguard: wg0: Sending handshake initiation to peer 97 (xx.xx.xx.xx:yyyyy)
wireguard: wg0: Handshake for peer 97 (xx.xx.xx.xx:yyyyy) did not complete after 5 seconds, retrying (try 4)
wireguard: wg0: Invalid handshake initiation from ww.ww.ww.ww:kkkkk
wireguard: wg0: Handshake for peer 97 (xx.xx.xx.xx:yyyyy) did not complete after 5 seconds, retrying (try 5)
wireguard: wg0: Sending handshake initiation to peer 97 (xx.xx.xx.xx:yyyyy)
wireguard: wg0: Retrying handshake with peer 97 (xx.xx.xx.xx:yyyyy) because we stopped hearing back after 15 seconds
wireguard: wg0: Invalid handshake initiation from ww.ww.ww.ww:kkkkk
wireguard: wg0: Handshake for peer 97 (xx.xx.xx.xx:yyyyy) did not complete after 5 seconds, retrying (try 2)
wireguard: wg0: Sending handshake initiation to peer 97 (xx.xx.xx.xx:yyyyy)
wireguard: wg0: Invalid handshake initiation from ww.ww.ww.ww:kkkkk
[...]
ad so on, being xx.xx.xx.xx and ww.ww.ww.ww the same IP or not.
If you need more information or tests feel free to ask, I'll do my best to
support you.
—
Reply to this email directly, view it on GitHub
<#29>, or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ALNYC75SMHF6H74N3COOF43VTFZYZANCNFSM53DLFKDA>
.
You are receiving this because you are subscribed to this thread.Message
ID: ***@***.***>
from esp_wireguard.
trombik
commented on May 29, 2024
i cannot reproduce the issue. after reset, the device connects to the peer in less than 30 sec including boot sequence. definitely not 180 sec.
I (635) wifi:wifi certification version: v7.0
I (635) wifi:config NVS flash: enabled
I (635) wifi:config nano formating: disabled
I (635) wifi:Init data frame dynamic rx buffer num: 32
I (645) wifi:Init management frame dynamic rx buffer num: 32
I (645) wifi:Init management short buffer num: 32
I (655) wifi:Init dynamic tx buffer num: 32
I (655) wifi:Init static rx buffer size: 1600
I (655) wifi:Init static rx buffer num: 10
I (665) wifi:Init dynamic rx buffer num: 32
I (665) wifi_init: rx ba win: 6
I (665) wifi_init: tcpip mbox: 32
I (675) wifi_init: udp mbox: 6
device reports readiness to read but returned no data (device disconnected or multiple access on port?)
I (675) wifi_init: tcp mbox: 6
I (685) wifi_init: tcp tx win: 5744
I (685) wifi_init: tcp rx win: 5744
I (685) wifi_init: tcp mss: 1440
I (695) wifi_init: WiFi IRAM OP enabled
I (695) wifi_init: WiFi RX IRAM OP enabled
I (705) phy_init: phy_version 4670,719f9f6,Feb 18 2021,17:07:07
I (815) wifi:mode : sta (78:21:8Waiting for the device to reconnect
65) wifi:connected with makers, aid = 7, channel 9, BW20, bssid = 50:c4:dd:47:2a:37
I (1565) wifi:security: WPA2-PSK, phy: bgn, rssi: -65
I (1575) wifi:pm start, type: 1
W 85) wifi:<ba-add>idx:0 (ifx:0, 50:c4:dd:47:2a:37), tid:0, ssn:3, winSize:64
ifi:AP's beacon interval = 102400 us, DTIM period = 1
I (2595) esp_netif_handlers: sta ip: 192.168.99.13, mask: 255.255.255.0, gw: 192.168.99.254
I (2595) demo: got ip:192.168.99.13
I (2595) demo: Connected to ap SSID:makers
I (2605) sync_time: Initializing SNTP
I (2605) sync_time: Waiting for system time to be set... (1/20)
I (4315) sync_time: Time synced
I (4615) demo: The current date/time in New York is: Sun Jul 10 02:31:37 2022
I (4615) demo: Initializing WireGuard.
I (4615) demo: Connecting to the peer.
I (4615) esp_wireguard: allowed_ip: 192.168.4.58
I (4675) esp_wireguard: Peer: 192.168.99.56 (192.168.99.56:12912)
I (4725) esp_wireguard: Connecting to 192.168.99.56:12912
I (5725) demo: Peer is down
I (6725) demo: Peer is down
I (7725) demo: Peer is up
I (7725) demo: Initializing ping...
I (7725) demo: ICMP echo target: 192.168.4.254
I (7745) demo: 64 bytes from 192.168.4.254 icmp_seq=1 ttl=255 time=18 ms
I (8725) demo: 64 bytes from 192.168.4.254 icmp_seq=2 ttl=255 time=4 ms
I (9725) demo: 64 bytes from 192.168.4.254 icmp_seq=3 ttl=255 time=3 ms
I (10735) demo: 64 bytes from 192.168.4.254 icmp_seq=4 ttl=255 time=7 ms
I (11735) demo: 64 bytes from 192.168.4.254 icmp_seq=5 ttl=255 time=7 ms
I (12735) demo: 64 bytes from 192.168.4.254 icmp_seq=6 ttl=255 time=7 ms
I (13745) demo: 64 bytes from 192.168.4.254 icmp_seq=7 ttl=255 time=18 ms
ets Jul 29 2019 12:21:46
rst:0x1 (POWERON_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:2
load:0x3fff0030,len:6608
load:0x40078000,len:14788
ho 0 tail 12 room 4
load:0x40080400,len:3792
0x40080400: _init at ??:?
entry 0x40080694
I (29) boot: ESP-IDF v4.4.1 2nd stage bootloader
I (29) boot: compile time 13:10:55
I (29) boot: chip revision: 3
I (32) boot_comm: chip revision: 3, min. bootloader chip revision: 0
I (39) boot.esp32: SPI Speed : 40MHz
I (44) boot.esp32: SPI Mode : DIO
I (48) boot.esp32: SPI Flash Size : 2MB
I (53) boot: Enabling RNG early entropy source...
I (58) boot: Partition Table:
I (62) boot: ## Label Usage Type ST Offset Length
I (69) boot: 0 nvs WiFi data 01 02 00009000 00006000
I (76) boot: 1 phy_init RF data 01 01 0000f000 00001000
I (84) boot: 2 factory factory app 00 00 00010000 00100000
I (91) boot: End of partition table
I (96) boot_comm: chip revision: 3, min. application chip revision: 0
I (103) esp_image: segment 0: paddr=00010020 vaddr=3f400020 size=14968h ( 84328) map
I (142) esp_image: segment 1: paddr=00024990 vaddr=3ffb0000 size=03838h ( 14392) load
I (148) esp_image: segment 2: paddr=000281d0 vaddr=40080000 size=07e48h ( 32328) load
I (161) esp_image: segment 3: paddr=00030020 vaddr=400d0020 size=78460h (492640) map
I (340) esp_image: segment 4: paddr=000a8488 vaddr=40087e48 size=0c74ch ( 51020) load
I (361) esp_image: segment 5: paddr=000b4bdc vaddr=50000000 size=00010h ( 16) load
I (371) boot: Loaded app from partition at offset 0x10000
I (371) boot: Disabling RNG early entropy source...
I (383) cpu_start: Pro cpu up.
I (384) cpu_start: Starting app cpu, entry point is 0x400811a8
0x400811a8: call_start_cpu1 at /usr/home/trombik/github/trombik/esp-idf/components/esp_system/port/cpu_start.c:160
I (0) cpu_start: App cpu up.
I (398) cpu_start: Pro cpu start user code
I (398) cpu_start: cpu freq: 160000000
I (398) cpu_start: Application information:
I (402) cpu_start: Project name: demo
I (407) cpu_start: App version: 5e591f5
I (412) cpu_start: Compile time: Jul 10 2022 13:19:33
I (418) cpu_start: ELF file SHA256: f8831f0d6d2c2f35...
I (424) cpu_start: ESP-IDF: v4.4.1
I (429) heap_init: Initializing. RAM available for dynamic allocation:
I (436) heap_init: At 3FFAE6E0 len 00001920 (6 KiB): DRAM
I (442) heap_init: At 3FFB79D8 len 00028628 (161 KiB): DRAM
I (448) heap_init: At 3FFE0440 len 00003AE0 (14 KiB): D/IRAM
I (455) heap_init: At 3FFE4350 len 0001BCB0 (111 KiB): D/IRAM
I (461) heap_init: At 40094594 len 0000BA6C (46 KiB): IRAM
I (469) spi_flash: detected chip: generic
I (472) spi_flash: flash io: dio
W (476) spi_flash: Detected size(8192k) larger than the size in the binary image header(2048k). Using the size in the binary image header.
I (490) cpu_start: Starting scheduler on PRO CPU.
I (0) cpu_start: Starting scheduler on APP CPU.
I (605) wifi:wifi driver task: 3ffc0388, prio:23, stack:6656, core=0
I (605) system_api: Base MAC address is not set
I (605) system_api: read default base MAC address from EFUSE
I (635) wifi:wifi firmware version: 63017e0
I (635) wifi:wifi certification version: v7.0
I (635) wifi:config NVS flash: enabled
I (635) wifi:config nano formating: disabled
I (635) wifi:Init data frame dynamic rx buffer num: 32
I (645) wifi:Init management frame dynamic rx buffer num: 32
I (645) wifi:Init management short buffer num: 32
I (655) wifi:Init dynamic tx buffer num: 32
I (655) wifi:Init static rx buffer size: 1600
I (655) wifi:Init static rx buffer num: 10
I (665) wifi:Init dynamic rx buffer num: 32
I (665) wifi_init: rx ba win: 6
I (665) wifi_init: tcpip mbox: 32
I (675) wifi_init: udp mbox: 6
I (675) wifi_init: tcp mbox: 6
I (685) wifi_init: tcp tx win: 5744
I (685) wifi_init: tcp rx win: 5744
I (685) wifi_init: tcp mss: 1440
I (695) wifi_init: WiFi IRAM OP enabled
I (695) wifi_init: WiFi RX IRAM OP enabled
I (705) phy_init: phy_version 4670,719f9f6,Feb 18 2021,17:07:07
I (815) wifi:mode : sta (78:21:84:4a:ce:a0)
I (815) wifi:enable tsf
I (825) wifi:new:<9,0>, old:<1,0>, ap:<255,255>, sta:<9,0>, prof:1
I (825) wifi:state: init -> auth (b0)
I (835) wifi:state: auth -> assoc (0)
I (835) wifi:state: assoc -> run (10)
I (955) wifi:connected with makers, aid = 7, channel 9, BW20, bssid = 50:c4:dd:47:2a:37
I (955) wifi:security: WPA2-PSK, phy: bgn, rssi: -66
I (965) wifi:pm start, type: 1
W (975) wifi:<ba-add>idx:0 (ifx:0, 50:c4:dd:47:2a:37), tid:0, ssn:3, winSize:64
I (975) wifi:AP's beacon interval = 102400 us, DTIM period = 1
I (1595) esp_netif_handlers: sta ip: 192.168.99.13, mask: 255.255.255.0, gw: 192.168.99.254
I (1595) demo: got ip:192.168.99.13
I (1595) demo: Connected to ap SSID:makers
I (1605) sync_time: Initializing SNTP
I (1605) sync_time: Waiting for system time to be set... (1/20)
I (1955) sync_time: Time synced
I (3615) demo: The current date/time in New York is: Sun Jul 10 02:31:51 2022
I (3615) demo: Initializing WireGuard.
I (3615) demo: Connecting to the peer.
I (3615) esp_wireguard: allowed_ip: 192.168.4.58
I (3675) esp_wireguard: Peer: 192.168.99.56 (192.168.99.56:12912)
I (3725) esp_wireguard: Connecting to 192.168.99.56:12912
I (4725) demo: Peer is down
I (5725) demo: Peer is down
I (6725) demo: Peer is down
I (7725) demo: Peer is down
I (8725) demo: Peer is down
I (9725) demo: Peer is down
I (10725) demo: Peer is down
I (11725) demo: Peer is down
I (12725) demo: Peer is down
I (13725) demo: Peer is down
I (14725) demo: Peer is up
I (14725) demo: Initializing ping...
I (14725) demo: ICMP echo target: 192.168.4.254
I (14755) demo: 64 bytes from 192.168.4.254 icmp_seq=1 ttl=255 time=30 ms
I (15935) demo: 64 bytes from 192.168.4.254 icmp_seq=2 ttl=255 time=210 ms
I (16735) demo: 64 bytes from 192.168.4.254 icmp_seq=3 ttl=255 time=9 ms
I (17725) demo: 64 bytes from 192.168.4.254 icmp_seq=4 ttl=255 time=3 ms
I (18725) demo: 64 bytes from 192.168.4.254 icmp_seq=5 ttl=255 time=3 ms
I (19755) demo: 64 bytes from 192.168.4.254 icmp_seq=6 ttl=255 time=27 ms
I (20735) demo: 64 bytes from 192.168.4.254 icmp_seq=7 ttl=255 time=7 ms
from esp_wireguard.
trombik
commented on May 29, 2024
commit 2f40564 introduced a Vagrantfile. you need virtualbox and vagrant. to reproduce the issue, vagrant up the box, build the example, and reset the device before the device disconnects from the server.
from esp_wireguard.
droscy
commented on May 29, 2024
Hi all, I tried to wait 180 seconds and more but nothing changed.
I tried the following logic but nothing changed (supposing that it makes sense):
- connect and wait for peer up
- when peer is down, save timestamp
- after 5 minutes of peer down
esp_wireguard_disconnect(), sleep,esp_wireguard_connect()
Even I power off the esp and switch it on again I still need to remove and re-add the peer server side to have the esp connected again.
Glad to see you, trombik, replicated the issue in a test environment. Many thanks.
from esp_wireguard.
limpens
commented on May 29, 2024
Hi all,
I've tested the issue using the vagrant vm, everything is working as expected. After a few seconds the esp is able to connect and resetting the esp during either the connected or disconnected fase does not make much of a difference, after restarting the esp, the connection is set up and available after a few seconds (< 30).
The same results, when I use my phone (connected to wifi) as a hotspot and the esp connecting to this hotspot. (This is an Android device so it is using hostapd and probably iptables to do the wifi / nat stuff.) On the receiving end (my own server, no longer with the vagrant VM) I notice the incoming packets with a source address as configured in the code (11010). This wifi network is not connected to the server, traffic to this server is routed over the public internet but no carrier-grade nat is used, just the nat on the phone and normal Cisco firewall hardware in my network connection to the internet.
However, when the phone is connected to the mobile network, the source port of the incoming packets is changed (probably due to CGNAT of my provider) and it is hit-and-miss to get a connection. I initially thought a reset server-side would fix things, cleaning up stale information, but this doesn't make a difference. (I assume the original source port is replaced by the hardware of my mobile provider when traversing back to the phone/esp. I was not able to run tcpdump on the phone to confirm this.)
I am not able to create a reproducible path using the mobile provider to achieve a working and not-working situation. Restarting server side, restarting the esp, restarting the hotspot on the mobile phone in every possible order does not yield a reproduction path. And to make things more complicated, when I use a different mobile provider, the connection is always established after about 180 seconds.
What does not make sense to me; when I setup a wireguard connection on the android device to this server, everything always works as expected, either using wifi or mobile, but this is out of scope for this issue.
from esp_wireguard.
trombik
commented on May 29, 2024
@limpens thanks for the feedback. as for the issue you are facing, the best course of action is to read other implementation. honestly, I do not fully understand the protocol. as there are many reports that wireguard works with CGNAT (they are using wireguard to bypass CGNAT), wireguard should work. doing tcpdump and enable debug on the server side is another option, but debug log is often sparse (for a good reason). it might be a specific behavior of the NAT box in use, but not sure.
from esp_wireguard.
limpens
commented on May 29, 2024
Hi @trombik , I might look into an alternative implementation of wireguard for the esp, but as it is working for my use case, I might just keep it this way. Thanks for your efforts !
from esp_wireguard.
trombik
commented on May 29, 2024
another wireguard for esp32 is using the same implementation. I'm following their commit log, but few differences only (it works with Ethernet, mine doesn't). (un)successful reports with CGNAT is very welcome.
from esp_wireguard.
ChSotiriou
commented on May 29, 2024
I have the same issue. What fixes it is pinging the device (if the esp is 10.8.0.6) from the server (10.8.0.1), ping 10.8.0.6 and it magically works. I had the exact same issue with a raspberry pi and to this day I have no idea what the issue is.
from esp_wireguard.
trombik
commented on May 29, 2024
is 10.8.0.6 allowed_ip?
from esp_wireguard.
ChSotiriou
commented on May 29, 2024
Yes. On the ESP32 wg_config.allowed_ip = "10.8.0.6";
Server Config
[Peer]
PublicKey = <pubkey>
AllowedIPs = 10.8.0.6/32, fd5f:3831:abf1::6/128
PersistentKeepalive = 0
from esp_wireguard.
ChSotiriou
commented on May 29, 2024
Might be related but the endpoint port does not equal the CONFIG_WG_LOCAL_PORT I set. I had it set to 37173.
peer: <pubkey>
endpoint: <ip>:1366
allowed ips: 10.8.0.6/32, fd5f:3831:abf1::6/128
latest handshake: 35 seconds ago
transfer: 14.00 MiB received, 13.59 KiB sent
Edit: I think this is the issue. Every time I upload new code to the MCU that port changes and breaks everything. Not sure how this happens or why (or if this is a wireshark thing and not this project).
from esp_wireguard.
droscy
commented on May 29, 2024
What fixes it is pinging the device (if the esp is 10.8.0.6) from the server (10.8.0.1), ping 10.8.0.6 and it magically works.
Pinging the device from server does not work for me, still invalid handshake :-(
Might be related but the endpoint port does not equal the CONFIG_WG_LOCAL_PORT I set. I had it set to 37173.
I thinks wg_config.listen_port = CONFIG_WG_LOCAL_PORT; is used when accepting connection not when starting the connection, that port is probably chosen randomly.
However I suspected something related to the peer port too because the server remembers the last port used and continuously tries to reach that port instead of the new one. But that is the same behavior of every other client that doesn't suffer of invalid handshake. I have no other clues, I can only perform tests.
from esp_wireguard.
trombik
commented on May 29, 2024
I have the same issue. What fixes it is pinging the device (if the esp is 10.8.0.6) from the server (10.8.0.1), ping 10.8.0.6 and it magically works
I guess both of them can talk to each other, i.e. no NAT is involved.
I never tried, but the wireguard is p2p, not server-client. if pinging from "server" works, that probably means that the "server" initiates the connection. this won't work in NAT.
if this assumption is true, the issue is not the same one.
from esp_wireguard.
trombik
commented on May 29, 2024
i'm not really sure it it works for you, but the recent two commits include minor fixes in wireguard layer from the upstream.
from esp_wireguard.
limpens
commented on May 29, 2024
I've tested my setup between this release and 21d5915 and did not see an improvement.
Restarting wireguard server-side shows a instantaneous connection (with either release), but if the client switches its IP address between different providers, it takes a couple (~ 10) seconds before the wireguard connection has been setup correctly.
This is not a show stopper but still does not compare to the experience with the android wg client.
from esp_wireguard.
Pecius
commented on May 29, 2024
I've made a pull request which should fix issues related to reconnecting after power loss/reset (#37).
To make it work you must either synchronize time from an external RTC device or via SNTP (as described here).
from esp_wireguard.
trombik
commented on May 29, 2024
@Pecius thanks. i'll merge it when confirmed by someone who have been facing the issue.
from esp_wireguard.
nikp123
commented on May 29, 2024
Can verify that Pecius's pull request fixes the problem. The wireguard connection is established MUCH faster.
from esp_wireguard.
Related Issues (16)
- persistent keepalives should be off by default
- the driver does not support changes in DNS records
- esp_netif_get_netif_impl_name does not exist in 4.1.x
- remove -Wno-error=stringop-overread from build flags HOT 2
- Cannot complete handshake if pre-shared key is in use HOT 4
- building the example for esp8266 master fails in CI, not on my machine
- crash wtih esp-idf 5.x, or master HOT 12
- Not able to install lib. HOT 1
- Crash on ESP8266-RTOS-SDK HOT 2
- Compatibility with esp_modem? HOT 3
- Question regarding AP+STA mode HOT 2
- can i use a esp8266 as vpn SERVER HOT 1
- IPV6 endpoint configured but peer is not connecting
- esp_wireguard.c does not support IPv6 HOT 1
- Crash on esp32s3
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from esp_wireguard.