Re: RFC: wg syncpeers wg0 wireguard.conf
Hi Jason, There are a few projects on github that show up under “Wireguard dynamic” and most have to do with the functionality I believe you guys are discussing here (please correct me if I’m wrong) which is how to update the peers on the wg interface (both add and remove) from the configuration. There is one called Wireguard-dynamic that has to do with configuring a mesh by using a key-value DHT or a shared kv store. https://github.com/segator/wireguard-dynamic/issues/2#issuecomment-502478520 There is also P2P-Wireguard in Rust that uses a STUN server to support nodes behind NAT. And wg-broker (another project) that is closer to what I’m looking for. The official wg-dynamic I think has to do with DHCP like functionality (from what I managed to read so far) so I understand its completely separate but the confusion around what “dynamic” is refers to is unfortunate (naming is always a tricky issue) Btw, may I suggest having two mailing lists: one for users like myself and another for contributors and core developers? In Tensorflow and other OSS we have such separation between the platform Developers and the users. On Fri, Jun 14, 2019 at 11:02 AM Jason A. Donenfeld wrote: > On Fri, Jun 14, 2019 at 8:01 PM Marc Fawzi wrote: > > p.s. does this overlap with similar planned in wg-dynamic? > > No, the topics have no similarities. > ___ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard
Re: RFC: wg syncpeers wg0 wireguard.conf
<< I'm very much in favour of this (updating `setconf` to use this new syncronisation approach), if anything it feels more logical and is how I initially (wrongly) assumed `setconf` behaved when starting out with WireGuard a while back. >> +1 ... it's better to keep the same command if its definition can be expanded (fewer things to remember and less mental clutter) p.s. does this overlap with similar planned in wg-dynamic? On Tue, Jun 11, 2019 at 5:23 PM Steven Honson wrote: > On Wed, 12 Jun 2019, at 3:56 AM, Jason A. Donenfeld wrote: > > The other thing I was wondering is: aside from performance and races > > as described above, why not just make this the functionality of > > `setconf`? Then there's be no need to introduce a new subcommand. In > > otherwords, the idea would be to make `setconf` not destroy existing > > peers if we're going to be re-adding them again. > > I'm very much in favour of this (updating `setconf` to use this new > syncronisation approach), if anything it feels more logical and is how I > initially (wrongly) assumed `setconf` behaved when starting out with > WireGuard a while back. > ___ > WireGuard mailing list > WireGuard@lists.zx2c4.com > https://lists.zx2c4.com/mailman/listinfo/wireguard > ___ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard
