Originally assigned to: @oschwartz10612 on GitHub.
Hey lads, well after spending way to long I was able to find the issue, thanks to Astra in the discord.
There is currently an issue with how Pangolin keeps track of the public keys that belong to Gerbil. This issue can manifest when for example the path for Gerbil is incorrect, or if the key is deleted. What this causes is if the rest of the details specifically it seems like the host field(so http://gerbil:(port) on docker), it will log both keys as diffrent enteries.
The problem with this is it will only ever return the first entry from the database, so even though it might have a bunch of enteries it will only give the oldest, but this one might(and probally isn't) used anymore by Gerbil. This means it will report this outdated wireguard key to the Newt client, which means it will forever be stuck on the handshake step.
This can be seen because while the network itself will work, and the wireguard test packets can be seen using "tcpdump udp port 51820", specificially of size 148, this will only be going from Newt Server --> Gerbil, and as such Wireguard will never be able to connect.
Reproduce:
Setup Pangolin and Gerbil as you usually would
Change the path that Gerbil uses for it's key to a non-persistant place(This could be done by a user by accident).
Restart Gerbil
Attempt to connect a newt client, it will fail to connect with no seemingly usable error, the only thing it gives is an i/o timeout error this is because the wireguard interface never finishes it's initialization.
Check the database, this can be done with "select * from exitNodes;" using the sqlite3 CLI program. You will see alot of entries, and you will see that the key newt is getting is the one equal to the lowest ID, even though this might not be the key that's being used anymore this can be checked by adding the wireguard-tools package to the container.
Fix
The problem right now is that it doesn't update the key for the same instance and instead adds it to the database as another entry, while still returning the old key from the database as the public key that Newt should use to connect to Gerbil. The easiest fix for this would be that if you get a client that has the same reachable address, you either delete the old entry and make a new one, or you update the previous entry.
Another solution would be to instead of grabbing the first from the index to grab the last one, because this is the one that was most recently added, but you would have a bunch of dead entries within the database so this solution isn't super useful.
Originally created by @Stetsed on GitHub (Jul 1, 2025).
Original GitHub issue: https://github.com/fosrl/pangolin/issues/997
Originally assigned to: @oschwartz10612 on GitHub.
Hey lads, well after spending way to long I was able to find the issue, thanks to Astra in the discord.
There is currently an issue with how Pangolin keeps track of the public keys that belong to Gerbil. This issue can manifest when for example the path for Gerbil is incorrect, or if the key is deleted. What this causes is if the rest of the details specifically it seems like the host field(so http://gerbil:(port) on docker), it will log both keys as diffrent enteries.
The problem with this is it will only ever return the first entry from the database, so even though it might have a bunch of enteries it will only give the oldest, but this one might(and probally isn't) used anymore by Gerbil. This means it will report this outdated wireguard key to the Newt client, which means it will forever be stuck on the handshake step.
This can be seen because while the network itself will work, and the wireguard test packets can be seen using "tcpdump udp port 51820", specificially of size 148, this will only be going from Newt Server --> Gerbil, and as such Wireguard will never be able to connect.
## Reproduce:
1. Setup Pangolin and Gerbil as you usually would
2. Change the path that Gerbil uses for it's key to a non-persistant place(This could be done by a user by accident).
3. Restart Gerbil
4. Attempt to connect a newt client, it will fail to connect with no seemingly usable error, the only thing it gives is an i/o timeout error this is because the wireguard interface never finishes it's initialization.
5. Check the database, this can be done with "select * from exitNodes;" using the sqlite3 CLI program. You will see alot of entries, and you will see that the key newt is getting is the one equal to the lowest ID, even though this might not be the key that's being used anymore this can be checked by adding the wireguard-tools package to the container.
## Fix
The problem right now is that it doesn't update the key for the same instance and instead adds it to the database as another entry, while still returning the old key from the database as the public key that Newt should use to connect to Gerbil. The easiest fix for this would be that if you get a client that has the same reachable address, you either delete the old entry and make a new one, or you update the previous entry.
Another solution would be to instead of grabbing the first from the index to grab the last one, because this is the one that was most recently added, but you would have a bunch of dead entries within the database so this solution isn't super useful.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Originally created by @Stetsed on GitHub (Jul 1, 2025).
Original GitHub issue: https://github.com/fosrl/pangolin/issues/997
Originally assigned to: @oschwartz10612 on GitHub.
Hey lads, well after spending way to long I was able to find the issue, thanks to Astra in the discord.
There is currently an issue with how Pangolin keeps track of the public keys that belong to Gerbil. This issue can manifest when for example the path for Gerbil is incorrect, or if the key is deleted. What this causes is if the rest of the details specifically it seems like the host field(so http://gerbil:(port) on docker), it will log both keys as diffrent enteries.
The problem with this is it will only ever return the first entry from the database, so even though it might have a bunch of enteries it will only give the oldest, but this one might(and probally isn't) used anymore by Gerbil. This means it will report this outdated wireguard key to the Newt client, which means it will forever be stuck on the handshake step.
This can be seen because while the network itself will work, and the wireguard test packets can be seen using "tcpdump udp port 51820", specificially of size 148, this will only be going from Newt Server --> Gerbil, and as such Wireguard will never be able to connect.
Reproduce:
Fix
The problem right now is that it doesn't update the key for the same instance and instead adds it to the database as another entry, while still returning the old key from the database as the public key that Newt should use to connect to Gerbil. The easiest fix for this would be that if you get a client that has the same reachable address, you either delete the old entry and make a new one, or you update the previous entry.
Another solution would be to instead of grabbing the first from the index to grab the last one, because this is the one that was most recently added, but you would have a bunch of dead entries within the database so this solution isn't super useful.
@oschwartz10612 commented on GitHub (Jul 3, 2025):
Yep this is very true. Will work on a fix ASAP.
@oschwartz10612 commented on GitHub (Sep 28, 2025):
I think this was fixed in 1.9.0