Open mcginty opened 1 year ago
I think @goodhoko might have had a similar issue. Though for him "long uptime" was just minutes, so not sure if the same cause.
My problem may be just me not using innernet correctly. IDK why (I think someone told me it's fine to) but I used to ctrl+c the innernet up
command before it established connection with all peers and ran to completion. This leaves the network stopped (even if it was previously running).
It adds to this confusion that the network works fine while innernet up
is trying to establish connections. I tend to jump between terminal tabs a lot and I often started using innernet before innernet up
finished in another tab. Thinking it's all set up I jumped back and killed innernet up
stopping the network again.
Unrelated to this issue, but maybe we could either make innernet up
handle SIGINT more gracefully in the phase of establishing connections with peers, or just print something like Received ctrl+c. Stopping XXX network.
so that it's clear what's happening. Shall I create an issue for that?
I'm on mac with wireguard-go.
My problem may be just me not using innernet correctly. IDK why (I think someone told me it's fine to) but I used to ctrl+c the
innernet up
command before it established connection with all peers and ran to completion. This leaves the network stopped (even if it was previously running).
It definitely behaves differently for me: I can Ctrl+C it right after
strohel@thicky ~/work/portal $ innernet up
[*] fetching state for tonari from server...
[*] peer dev-pablo-portal (9Wj1oUXCWW...) was modified.
[*] Endpoint: 81.34.16.254:35626 => 2.138.197.161:49285
[*] peer jen (gUwOAMVBQW...) was modified.
[*] Endpoint: 192.168.1.1:52495 => 37.143.115.174:53063
[*] peer taj (5iuERx/Z7v...) was modified.
[*] Endpoint: 111.216.113.76:58107 => 133.201.82.64:32789
[*] updated interface tonari
[*] reporting 2 interface addresses as NAT traversal candidates
and the network stays up, most/all peers connected (just probably misses some NAT traversal oportunities, but that's a corner-case).
Linux, kernel-space wireguard here.
@goodhoko that happens to me too, I think like you said we just need to handle SIGINT more intelligently. I'll open a separate issue for that, because this is a whole different beast...
Unfortunately I haven't found the root cause yet, but occasionally innernet on macOS will get into a state where peers are no longer accessible, and
innernet up
doesn't fix the problem if you don't doinnernet down
before hand to reset all the states/tunnels.The test innernet subnet is
fd00:1337::/48
.I just hit this condition, so dumping some debug output here for later investigation.
tldr: at first glance, the routes and interfaces look normal, but I can't even ping my local wireguard IP via the loopback interface (
lo0
). Something is weird.netstat -rn
output:WireGuard information