I see! Please ignore :)
For reference, I was working on this and forgot about that it is not a snapshot
yet: https://github.com/openwrt/packages/pull/4341
> On 10 May 2017, at 10:15, Jason A. Donenfeld wrote:
>
> Ubuntu team: please ignore Dan's email.
>
> Dan: the per-peer preshared key has
Hi folks,
can anyone from the PPA team trigger a rebuild? Last build was two weeks ago
and I would love to test the new per-peer preshared key option. I use Ubuntu
peers for testing interoperability with LEDE and the PPA module.
Cheers!
Dan
___
WireG
Hi everyone,
I am very excited that we have this discussion, as I am one of those
IPv6-first/IPv6-only guys who like poking the topic.
I try to keep it short:
- Scalability: I agree with what George said. Broadcast does not scale nicely,
and IPv6 multicast is intended to help scaling things by
Hi Sina,
Maybe this article can help you kickstart WireGuard on RaspberryPi. I hope it
is net yet outdated.
--> https://www.danrl.com/2016/08/30/travel-wifi.html
Cheers,
Dan
> On 25 Feb 2017, at 15:16, Sina Siadat wrote:
>
> Firstly, thank you so much for creating this amazing tool! :)
>
>
Hi Frederik,
this is a very generous offer and I think I speak for all of us: Thank you for
participating.
I sent you a private mail regarding test keys.
Cheers,
Dan
> On 25 Feb 2017, at 14:28, Fredrik Strömberg wrote:
>
> Hi all,
>
> I'm one of the co-founders of Mullvad, as well as a lo
ve: every 25 seconds
>
>
> Peer 2 :
>
> interface: wg0
> public key: dOXT9AvlEt9KSl3ricE12GuVa+U4XB0s1c92s8W+9VA=
> private key: (hidden)
> listening port: 6081
>
> peer: q5ypTBI7bN0vPGzvlGYyF6pCqYgrDsEjO827duAwjX4=
> endpoint: 77.156.x.x:58943
> all
Nicolas: Could you provide the configuration files? Because from your little
graphic or schema I can not even derive what you are configuring. I guess there
is something overlapping prefixes maybe?
Jason: I think we are approaching the point in time when there will be a -dev
and a -users ML :)
Hi Nicolas,
> On 17 Feb 2017, at 15:03, nicolas prochazka
> wrote:
> I hope not to have misunderstood ip management with wireguard,
> in a "server mode operation" , as many peers -> one peer ( server ) ,
> private ip configuration must be coherent.
There is no need for private (assuming you m
Hello Nicolas,
been there, asked that. The answer was negative.
I know, it is no fun to parse.
See here how I worked around it:
->
https://github.com/danrl/lede-luci/blob/58833aa2df97ba93a9512f3b0c428cf558fa2235/applications/luci-app-wireguard/luasrc/view/wireguard.htm
JSON output would have sav
>
> On 27 Jan 2017, at 18:07, Jason A. Donenfeld wrote:
>
> This is controlled by an env var, which is auto by default. Grep the wg man
> page for COLOR.
For the record, this does the trick:
watch --color WG_COLOR_MODE=always wg show
Cheers,
Dan
_
Hi Jason,
here is what I observed when combining `wg` with `watch` regarding colored
output. Not sure if this is a wg-issue at all.
# wg show
[colored output] expected
# watch wg show
[no colored output] expected, but not cool :)
# watch --color wg show
[no colored output] expected, but not c
I don't see a bug here. And no patches. And still no code. Only plenty of
tl;dr. I think the only thing we can do is to agree to disagree.
> On 18 Jan 2017, at 12:21, Peter Dolding wrote:
>
>> On Wed, Jan 18, 2017 at 4:11 PM, Dan Lüdtke wrote:
>> Two things
Two things I have not seen so far:
- government regulations that enforce NAT
- ISPs (let alone carriers) "upgrading" their networks to ipv6 nat (i myself
have run both, isp + carrier networks, and i call BS on your future outlook
regarding nat ipv6)
- code from you in this thread
> On 18 Jan 2
Hi,
> On 8 Jan 2017, at 23:49, Jason A. Donenfeld wrote:
>
> (send an encrypted out of band non-IP packet
> directly to a peer, for things like autoconfig) could play a nice role
> in this.
This is highly interesting! I should undust my gcc probably.
> One thing that comes to mind is how to
Hi Peter,
I followed this thread and like to express some concerns. Although I see the
problem and ran into it myself, I would like to see a solution outside the
wireguard code. Like the one Jason proposed or even a new approach. I am afraid
that network layers problems (legacy IP and especiall
> I assume youre not shipping the bash completion stuff either, right? Since
> openwrt doesn't use bash.
We are not shipping it.
FYI: The topic is discussed right now in this PR:
https://github.com/openwrt/packages/pull/3816
___
WireGuard mailing list
> On 4 Jan 2017, at 19:50, Jason A. Donenfeld wrote:
>
> OpenWRT should _not_ ship this.
Agreed.
Everything else looks good to me. Just had a brief look at it.
Let's see what buildbot says. Should all run smoothly!
___
WireGuard mailing list
WireG
[Caution: Unfiltered thoughts and ideas, untested from mind to mail. WoT ahead.]
Hi Toke,
I am on the road so can't test right now. Can you elaborate on babel a bit?
Would you be able to use non-link-local multicast addresses? Let's call it
"routed multicast" for now.
Maybe related/similar cas
> On 20 Dec 2016, at 14:33, Jason A. Donenfeld wrote:
> On Tue, Dec 20, 2016 at 11:15 AM, Dan Lüdtke wrote:
>> New environment, build from latest sources this morning. Can't reproduce. I
>> can't see duplicate routes. Static routes were added via LuCI to represent a
> On 20 Dec 2016, at 09:52, Dan Lüdtke wrote:
>
> Regarding the initial preciseness issue, have you tested that on LEDE? I
> can't manage to get duplicate routes. However, outdated testing environment.
> Will rebuild and test again. I can't quite understand what
Regarding the initial preciseness issue, have you tested that on LEDE? I can't
manage to get duplicate routes. However, outdated testing environment. Will
rebuild and test again. I can't quite understand what the initial issue was.
Wouldn't you get a "rtnetlink: file exists" when you try to add
Hi,
that would mean multiple calls to `wg` to get the desired structure filled, one
for each [CATEGORY]. I can live with that, but was looking for a more efficient
solution.
Cheers,
Dan
Nice bandwidth, though :)
> On 14 Dec 2016, at 22:09, Jason A. Donenfeld wrote:
>
> Hi Dan,
>
> This a
Hi Jason, everyone,
I'd like to discuss the topic of structured output. I am working on
luci-app-wireguard* which aims to provide status information via the
user-friendly LUCI interface in LEDE. While writing code to parse the output I
realized that I may not be the only one who needs to struct
> Not sure why the dependency is
> hard coded like this; it shouldn't be.
Even if it wasn't hardcoded, it would be introduced by +kmod-udptunnel6 anyway.
Remove both manually if you really need to throw away IP and want to compile
legacyIP only. It should work with both, @IP6 and kmod-udptunnel
> On 8 Dec 2016, at 05:34, Daniel Kahn Gillmor wrote:
>
> On Wed 2016-12-07 19:30:34 -0500, Hannes Frederic Sowa wrote:
>> Your custom protocol should be designed in a way you get an aligned ip
>> header. Most protocols of the IETF follow this mantra and it is always
>> possible to e.g. pad opti
> The config value has to be the same to correlate them. In that case,
> you should show an example with multiple peers, so that it's clear
> what's happening.
It says "Peer configurations are managed via one or more wireguard_
sections." to introduce the example. However, won't hurt to add anot
> On 16 Nov 2016, at 17:56, Jason A. Donenfeld wrote:
>
> config wireguard_foo
>
> -->
>
> config wireguard_peer1
Unfortunately, not. All peers for iface 'foo' will be named wireguard_foo. UCI
sections are iterable if they have the same name.
wireguard_peer1 could belong to any wg interface
> If somebody has time, it would be good to include one or two examples at
> the end of the page (otherwise I'll do it at some point).
This one OK?
https://wiki.lede-project.org/docs/user-guide/tunneling_interface_protocols#static_addressing_of_a_gre_tunnel
_
Hi,
I noticed that you maintain a PPA for WireGuard. You may be interested in
joining this discussion thread on the WireGuard mailing list.
https://lists.zx2c4.com/pipermail/wireguard/2016-November/000583.html
Cheers,
Dan
___
WireGuard mailing list
W
Thanks Jason!
No hurry, though.
Is the script open source as well? Maybe I can tinker with it, so you don't
waste your precious development time on supporting infrastructure.
> On 16 Nov 2016, at 15:49, Jason A. Donenfeld wrote:
>
> Hey Dan,
>
> On Wed, Nov 16, 2016 at
PS: This is not urgent or anything. Just wanted to know what your plans are
and/or to get an idea how to setup a demo server myself.
I think there are more important things to do right now.
> On 16 Nov 2016, at 15:38, Dan Lüdtke wrote:
>
> Hi Jason,
>
>> I guess I
ng how to accept *any*
public key in the [Peer] config.
Cheers,
Dan
> Jason
>
> On Wed, Nov 16, 2016 at 12:39 PM, Dan Lüdtke wrote:
>> Jason,
>>
>> do you plan on adding IPv6 compatibility to the demo server? If not, do you
>> mind if I set one up? How dif
Jason,
do you plan on adding IPv6 compatibility to the demo server? If not, do you
mind if I set one up? How difficult is it to run the demo server. It just
accepts every key, right?
Cheers,
Dan
___
WireGuard mailing list
WireGuard@lists.zx2c4.com
ht
> But I never received / send a email to you.
You are right. I was talking to other PPA maintainers as well.
Nevertheless, I user your repo on my servers since it was the one that worked
the best.
___
WireGuard mailing list
WireGuard@lists.zx2c4.com
Hi Kalin,
yes, this looks fine. Thanks for reporting.
I created an issue and submitted a fixing pull request. As soon as it is merged
the builds should be fine again.
I will set up a new build machine that builds from scratch to avoid similar
mistakes in the future.
Cheers,
Dan
> On 16 Nov
Hi,
thanks for the various feedback, guys! Here is the next round:
https://github.com/openwrt/packages/pull/3514
and
https://github.com/openwrt/luci/pull/852
Cheers,
Dan
> On 13 Nov 2016, at 23:52, Dan Lüdtke wrote:
>
> Hi again,
>
> here is the pull request for LuCi:
>
at 23:35, Dan Lüdtke wrote:
>
> Hi all,
>
> first step of OpenWRT/LEDE integration is making sure the helper script for
> configuring the interface is installed. The corresponding pull request can be
> found here:
> https://github.com/openwrt/packages/pull/3512
>
> Pl
Hi all,
first step of OpenWRT/LEDE integration is making sure the helper script for
configuring the interface is installed. The corresponding pull request can be
found here:
https://github.com/openwrt/packages/pull/3512
Please support this pull request.
Once it is accepted, the GUI (luci) will
Done!
> - if ! ip link show dev "${iface}" >/dev/null 2>&1; then
> - ip link add dev "${iface}" type wireguard
> - else
> - ip address flush dev "${iface}"
> - ip route flush dev "${iface}"
> - fi
> + ip link del dev "${iface}" 2>/dev/null
> + ip link add dev "${iface}" type wireguard
Thanks for the fast reply!
Changes applied. See diff here:
-->
https://github.com/danrl/luci-proto-wireguard/commit/6f90ff4ecc21f39721b3da357962c0ebe0d20750
Screenshots updated.
> On 1 Nov 2016, at 21:09, Jason A. Donenfeld wrote:
>
> 3. "addresses.placeholder = "fd00:13:37::1/64"" -- migh
Hi everyone,
I created a LuCi integration for Wireguard. Feedback and beta testing
appreciated.
--> https://github.com/danrl/luci-proto-wireguard
Thanks,
Dan
___
WireGuard mailing list
WireGuard@lists.zx2c4.com
http://lists.zx2c4.com/mailman/listinfo
Any news on the AllowedIPs bikeshedding? What have you decided, Jason?
--> https://www.mail-archive.com/wireguard@lists.zx2c4.com/msg00068.html
Asking because I am working on an ansible module Would like to use the most
recent name for the parameter name.
- Dan
PS: Good to see so much progress
42 matches
Mail list logo
