search

freifunkh / site

Freifunk Hannover specific Gluon site configuration for Firmware building.
https://hannover.freifunk.net
5 stars 5 forks source link

vH21.12 only ships with 5 not 10 potential supernode wireguard-keys #59

Closed 1977er closed 2 years ago

1977er commented 3 years ago

In good-old fastd times we shipped cryptokeys for ten supernodes (sn01...sn10.s.ffh.zone). The current wireguard firmware only ships keys for the currently known sn01, sn05, sn09 snd sn10.

This is okay for a (closed) beta release but should be fixed for a public (beta/gamma) release.

AiyionPrime commented 3 years ago

Why is this blocked?

AiyionPrime commented 3 years ago

Furthermore, whether permanently unavailable supernodes like sn02, sn03 or sn07 should have a key could depend on the intended implementation of wgpeerselector. Maybe @CodeFetch or @lemoer can say something about how the dead keys might affect the connection establishment.

Something minor, but having only existing supernodes on the statuspage is something I find pretty satisfying and intuitive.

At very least I want to hear proper arguments, like 'in order to deploy supernodes faster without new firmware' and not something about

good-old fastd times ...

1977er commented 3 years ago

I have no problem with filtering supernode listings on the status page based on their current existence.

In the past we managed to lose supernode private keys. The more we have on a node the better. Imaging a firmware with only three keys: we would not be able to connect to that node ever again, if we lose all three.

CodeFetch commented 3 years ago

@AiyionPrime The dead keys are not a problem. The peerselector is very fast.