Wireguard command line tools for Android

Wireguard command line tools for Android

[boerner]

Hey all,

I've recently set up my private VPN with Wireguard. I am running my local server behind a DSL router with a variable public IP address, accessible via dyndns and NAT, and several mobile clients (Android, Notebooks). 
Everything is working fine so far, except of one issue that I would like discuss here: 
Roaming doesn't work reliably when a device leaves or re-enters the home LAN, nor when the public IP address is changed by my ISP. The reason seems clear to me: In these cases both peers change their IP address simultaneously whereas the Wireguard protocol relies on only one address changing at a time.

My approach would be to shut down Wireguard on the clients as long as they are connected to their home network locally and to bring up the tunnel only when they leave the home network. Besides the roaming issue it  would be desirable to use the local connection when it is available rather than to take the detour over the internet. And it  should be done automatically so users need not remember to switch on/off VPN all the time.
My idea was to use Tasker to perform something like wg-quick up|down tun1 accordingly, but the Wireguard command line tools wg and wg-quick don't seem to be available (anymore). In older forum posts I've seen that you can install them from the app settings, but in my version (v0.0.20190708) this option is not available.

Does anybody know about another solution? Or, as a question to the developers, would it be a big deal to bring back the command line feature?

Thanks, Tom




_______________________________________________
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard

Re: Wireguard command line tools for Android

[David Kerr]

[-- Attachment #1.1: Type: text/plain, Size: 2992 bytes --]

I assume you have set the client configs to connect to something like "
vpn.example.com:<port>" . How does DNS resolve this when inside your local
LAN?  Does it resolve to the same public IP address that your DSL router is
connected to, or does it resolve to an internal address like 192.168.1.1?

The way I have this working is to ensure that my VPN URL always resolves to
the external IP address, even when I am inside my home network.  To do that
I had to update my DNS server configuration to make sure that my VPN URL is
always resolved by an external DNS provider... I have my own custom network
gateway/router and set dnsmasq.static to include the line...

server=/vpn.example.com/8.8.8.8

Now this works for me because my wireguard server is running on my custom
gateway/router... no NAT forwarding to an internal host running wireguard.
If you are running wireguard on an internal server then you also need to
make sure that your firewall rules don't block connections to your external
interface from your local LAN and do the right NATing -- which is probably
not permitted by default.  I forget how to do this, but I'm sure google
will find some instructions.

David





On Mon, Aug 5, 2019 at 2:57 PM <boerner@t-online.de> wrote:

> Hey all,
>
> I've recently set up my private VPN with Wireguard. I am running my local
> server behind a DSL router with a variable public IP address, accessible
> via dyndns and NAT, and several mobile clients (Android, Notebooks).
> Everything is working fine so far, except of one issue that I would like
> discuss here:
> Roaming doesn't work reliably when a device leaves or re-enters the home
> LAN, nor when the public IP address is changed by my ISP. The reason seems
> clear to me: In these cases both peers change their IP address
> simultaneously whereas the Wireguard protocol relies on only one address
> changing at a time.
>
> My approach would be to shut down Wireguard on the clients as long as they
> are connected to their home network locally and to bring up the tunnel only
> when they leave the home network. Besides the roaming issue it  would be
> desirable to use the local connection when it is available rather than to
> take the detour over the internet. And it  should be done automatically so
> users need not remember to switch on/off VPN all the time.
> My idea was to use Tasker to perform something like wg-quick up|down tun1
> accordingly, but the Wireguard command line tools wg and wg-quick don't
> seem to be available (anymore). In older forum posts I've seen that you can
> install them from the app settings, but in my version (v0.0.20190708) this
> option is not available.
>
> Does anybody know about another solution? Or, as a question to the
> developers, would it be a big deal to bring back the command line feature?
>
> Thanks, Tom
>
>
>
>
> _______________________________________________
> WireGuard mailing list
> WireGuard@lists.zx2c4.com
> https://lists.zx2c4.com/mailman/listinfo/wireguard
>

[-- Attachment #1.2: Type: text/html, Size: 4555 bytes --]

[-- Attachment #2: Type: text/plain, Size: 148 bytes --]

_______________________________________________
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard

Re: Wireguard command line tools for Android

[boerner]

[-- Attachment #1.1: Type: text/plain, Size: 4482 bytes --]

Hi David,
Thanks for your elaborate answer!

Yes, your assumption is right - my clients connect to a URL that resolves to an internal address when inside my local LAN. The idea was to keep traffic internal whenever possible. 
I have now followed your suggestion and have my VPN URL always resolved to the external IP address so the address won't change when leaving/entering  the local network.
For me, this solves a part of my issue but not all of it. 
My router is assigned a new external address (both IPv4 and IPv6) every 24 h, and obviously this invalidates the public IP adresses known by the server and the client simultaneously, as they are identical for the clients connected to the local network. That makes the handshake fail, and "wg" on the server shows that it is still looking for its endpoints at the old address. The same is true for the clients.
Disconnecting/reconnecting the clients fixes the tunnel until the next address change, because then Wireguard looks for the DNS record instead of using its stored address information. I think it would be a good feature if Wireguard could refresh its endpoint addresses automatically when an endpoint is not reachable anymore.

How does it work on your side? Have you a constant external IP address?

Thomas


Am Montag, 5. August 2019, 23:28:41 CEST schrieb David Kerr:


I assume you have set the client configs to connect to something like "vpn.example.com[1]:<port>" . How does DNS resolve this when inside your local LAN?  Does it resolve to the same public IP address that your DSL router is connected to, or does it resolve to an internal address like 192.168.1.1?


The way I have this working is to ensure that my VPN URL always resolves to the external IP address, even when I am inside my home network.  To do that I had to update my DNS server configuration to make sure that my VPN URL is always resolved by an external DNS provider... I have my own custom network gateway/router and set dnsmasq.static to include the line...


server=/vpn.example.com/8.8.8.8[2]



Now this works for me because my wireguard server is running on my custom gateway/router... no NAT forwarding to an internal host running wireguard.  If you are running wireguard on an internal server then you also need to make sure that your firewall rules don't block connections to your external interface from your local LAN and do the right NATing -- which is probably not permitted by default.  I forget how to do this, but I'm sure google will find some instructions.


David









On Mon, Aug 5, 2019 at 2:57 PM <boerner@t-online.de[3]> wrote:


Hey all,

I've recently set up my private VPN with Wireguard. I am running my local server behind a DSL router with a variable public IP address, accessible via dyndns and NAT, and several mobile clients (Android, Notebooks). Everything is working fine so far, except of one issue that I would like discuss here: Roaming doesn't work reliably when a device leaves or re-enters the home LAN, nor when the public IP address is changed by my ISP. The reason seems clear to me: In these cases both peers change their IP address simultaneously whereas the Wireguard protocol relies on only one address changing at a time.

My approach would be to shut down Wireguard on the clients as long as they are connected to their home network locally and to bring up the tunnel only when they leave the home network. Besides the roaming issue it  would be desirable to use the local connection when it is available rather than to take the detour over the internet. And it  should be done automatically so users need not remember to switch on/off VPN all the time.My idea was to use Tasker to perform something like wg-quick up|down tun1 accordingly, but the Wireguard command line tools wg and wg-quick don't seem to be available (anymore). In older forum posts I've seen that you can install them from the app settings, but in my version (v0.0.20190708) this option is not available.

Does anybody know about another solution? Or, as a question to the developers, would it be a big deal to bring back the command line feature?

Thanks, Tom




_______________________________________________WireGuard mailing list

WireGuard@lists.zx2c4.com[4]
https://lists.zx2c4.com/mailman/listinfo/wireguard[5]




--------
[1] http://vpn.example.com
[2] http://vpn.example.com/8.8.8.8
[3] mailto:boerner@t-online.de
[4] mailto:WireGuard@lists.zx2c4.com
[5] https://lists.zx2c4.com/mailman/listinfo/wireguard

[-- Attachment #1.2: Type: text/html, Size: 10738 bytes --]

[-- Attachment #2: Type: text/plain, Size: 148 bytes --]

_______________________________________________
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard

Re: Wireguard command line tools for Android

[David Kerr]

[-- Attachment #1.1: Type: text/plain, Size: 5144 bytes --]

Hi Tom,
  Yes I have a stable IP external address.  Under normal circumstances it
only changes if I change device (the MAC address) that requests the dhcp
lease.  Thus I only have to deal with roaming (changing IPs) on my client
device(s) not the server.  I have never heard of a ISP that changes an
assigned IP address every 24 hours, its pretty unfriendly practice.
Normally client devices request renewal of the specific IP address it was
previously assigned, so your ISP is explicitly refusing to renew that and
causing the client to request a new IP.  I would be seeking a new ISP in
your situation.

David

On Tue, Aug 6, 2019 at 3:17 AM <boerner@t-online.de> wrote:

> Hi David,
>
> Thanks for your elaborate answer!
>
>
>
> Yes, your assumption is right - my clients connect to a URL that resolves
> to an internal address when inside my local LAN. The idea was to keep
> traffic internal whenever possible.
>
> I have now followed your suggestion and have my VPN URL always resolved to
> the external IP address so the address won't change when leaving/entering
> the local network.
>
> For me, this solves a part of my issue but not all of it.
>
> My router is assigned a new external address (both IPv4 and IPv6) every 24
> h, and obviously this invalidates the public IP adresses known by the
> server and the client simultaneously, as they are identical for the clients
> connected to the local network. That makes the handshake fail, and "wg" on
> the server shows that it is still looking for its endpoints at the old
> address. The same is true for the clients.
>
> Disconnecting/reconnecting the clients fixes the tunnel until the next
> address change, because then Wireguard looks for the DNS record instead of
> using its stored address information. I think it would be a good feature if
> Wireguard could refresh its endpoint addresses automatically when an
> endpoint is not reachable anymore.
>
>
>
> How does it work on your side? Have you a constant external IP address?
>
>
>
> Thomas
>
>
>
>
>
> Am Montag, 5. August 2019, 23:28:41 CEST schrieb David Kerr:
>
> I assume you have set the client configs to connect to something like "
> vpn.example.com:<port>" . How does DNS resolve this when inside your
> local LAN?  Does it resolve to the same public IP address that your DSL
> router is connected to, or does it resolve to an internal address like
> 192.168.1.1?
>
>
> The way I have this working is to ensure that my VPN URL always resolves
> to the external IP address, even when I am inside my home network.  To do
> that I had to update my DNS server configuration to make sure that my VPN
> URL is always resolved by an external DNS provider... I have my own custom
> network gateway/router and set dnsmasq.static to include the line...
>
>
> server=/vpn.example.com/8.8.8.8
>
>
> Now this works for me because my wireguard server is running on my custom
> gateway/router... no NAT forwarding to an internal host running wireguard.
> If you are running wireguard on an internal server then you also need to
> make sure that your firewall rules don't block connections to your external
> interface from your local LAN and do the right NATing -- which is probably
> not permitted by default.  I forget how to do this, but I'm sure google
> will find some instructions.
>
>
> David
>
>
>
>
>
>
> On Mon, Aug 5, 2019 at 2:57 PM <boerner@t-online.de> wrote:
>
> Hey all,
>
> I've recently set up my private VPN with Wireguard. I am running my local
> server behind a DSL router with a variable public IP address, accessible
> via dyndns and NAT, and several mobile clients (Android, Notebooks).
> Everything is working fine so far, except of one issue that I would like
> discuss here:
> Roaming doesn't work reliably when a device leaves or re-enters the home
> LAN, nor when the public IP address is changed by my ISP. The reason seems
> clear to me: In these cases both peers change their IP address
> simultaneously whereas the Wireguard protocol relies on only one address
> changing at a time.
>
> My approach would be to shut down Wireguard on the clients as long as they
> are connected to their home network locally and to bring up the tunnel only
> when they leave the home network. Besides the roaming issue it  would be
> desirable to use the local connection when it is available rather than to
> take the detour over the internet. And it  should be done automatically so
> users need not remember to switch on/off VPN all the time.
> My idea was to use Tasker to perform something like wg-quick up|down tun1
> accordingly, but the Wireguard command line tools wg and wg-quick don't
> seem to be available (anymore). In older forum posts I've seen that you can
> install them from the app settings, but in my version (v0.0.20190708) this
> option is not available.
>
> Does anybody know about another solution? Or, as a question to the
> developers, would it be a big deal to bring back the command line feature?
>
> Thanks, Tom
>
>
>
>
> _______________________________________________
> WireGuard mailing list
> WireGuard@lists.zx2c4.com
> https://lists.zx2c4.com/mailman/listinfo/wireguard
>
>
>
>

[-- Attachment #1.2: Type: text/html, Size: 8941 bytes --]

[-- Attachment #2: Type: text/plain, Size: 148 bytes --]

_______________________________________________
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard

Re: Wireguard command line tools for Android

[boerner]

[-- Attachment #1.1: Type: text/plain, Size: 5707 bytes --]

Hi David,

No luck - changing IP addresses are common practice here in Europe. For "privacy reasons" they say, but I think it's just inherited from the former dial-in connections. Even the IPv6 prefix changes every day, in my case the last two bytes of the prefix. Stable addresses are available for enterprise contracts, and you pay extra for that.
But now I understand why nobody has this issue in mind on the other side of the pond. I will post a feature request.

Tom

Am Dienstag, 6. August 2019, 14:33:44 CEST schrieb David Kerr:


Hi Tom,
  Yes I have a stable IP external address.  Under normal circumstances it only changes if I change device (the MAC address) that requests the dhcp lease.  Thus I only have to deal with roaming (changing IPs) on my client device(s) not the server.  I have never heard of a ISP that changes an assigned IP address every 24 hours, its pretty unfriendly practice.  Normally client devices request renewal of the specific IP address it was previously assigned, so your ISP is explicitly refusing to renew that and causing the client to request a new IP.  I would be seeking a new ISP in your situation.


David


On Tue, Aug 6, 2019 at 3:17 AM <boerner@t-online.de[1]> wrote:


Hi David,
Thanks for your elaborate answer!
 
Yes, your assumption is right - my clients connect to a URL that resolves to an internal address when inside my local LAN. The idea was to keep traffic internal whenever possible. 
I have now followed your suggestion and have my VPN URL always resolved to the external IP address so the address won't change when leaving/entering the local network.
For me, this solves a part of my issue but not all of it. 
My router is assigned a new external address (both IPv4 and IPv6) every 24 h, and obviously this invalidates the public IP adresses known by the server and the client simultaneously, as they are identical for the clients connected to the local network. That makes the handshake fail, and "wg" on the server shows that it is still looking for its endpoints at the old address. The same is true for the clients.
Disconnecting/reconnecting the clients fixes the tunnel until the next address change, because then Wireguard looks for the DNS record instead of using its stored address information. I think it would be a good feature if Wireguard could refresh its endpoint addresses automatically when an endpoint is not reachable anymore.
 
How does it work on your side? Have you a constant external IP address?
 
Thomas
 
 
Am Montag, 5. August 2019, 23:28:41 CEST schrieb David Kerr:


I assume you have set the client configs to connect to something like "vpn.example.com[2]:<port>" . How does DNS resolve this when inside your local LAN?  Does it resolve to the same public IP address that your DSL router is connected to, or does it resolve to an internal address like 192.168.1.1?


The way I have this working is to ensure that my VPN URL always resolves to the external IP address, even when I am inside my home network.  To do that I had to update my DNS server configuration to make sure that my VPN URL is always resolved by an external DNS provider... I have my own custom network gateway/router and set dnsmasq.static to include the line...


server=/vpn.example.com/8.8.8.8[3]



Now this works for me because my wireguard server is running on my custom gateway/router... no NAT forwarding to an internal host running wireguard.  If you are running wireguard on an internal server then you also need to make sure that your firewall rules don't block connections to your external interface from your local LAN and do the right NATing -- which is probably not permitted by default.  I forget how to do this, but I'm sure google will find some instructions.


David









On Mon, Aug 5, 2019 at 2:57 PM <boerner@t-online.de[1]> wrote:


Hey all,

I've recently set up my private VPN with Wireguard. I am running my local server behind a DSL router with a variable public IP address, accessible via dyndns and NAT, and several mobile clients (Android, Notebooks). Everything is working fine so far, except of one issue that I would like discuss here: Roaming doesn't work reliably when a device leaves or re-enters the home LAN, nor when the public IP address is changed by my ISP. The reason seems clear to me: In these cases both peers change their IP address simultaneously whereas the Wireguard protocol relies on only one address changing at a time.

My approach would be to shut down Wireguard on the clients as long as they are connected to their home network locally and to bring up the tunnel only when they leave the home network. Besides the roaming issue it  would be desirable to use the local connection when it is available rather than to take the detour over the internet. And it  should be done automatically so users need not remember to switch on/off VPN all the time.My idea was to use Tasker to perform something like wg-quick up|down tun1 accordingly, but the Wireguard command line tools wg and wg-quick don't seem to be available (anymore). In older forum posts I've seen that you can install them from the app settings, but in my version (v0.0.20190708) this option is not available.

Does anybody know about another solution? Or, as a question to the developers, would it be a big deal to bring back the command line feature?

Thanks, Tom




_______________________________________________WireGuard mailing list

WireGuard@lists.zx2c4.com[4]
https://lists.zx2c4.com/mailman/listinfo/wireguard[5]






--------
[1] mailto:boerner@t-online.de
[2] http://vpn.example.com
[3] http://vpn.example.com/8.8.8.8
[4] mailto:WireGuard@lists.zx2c4.com
[5] https://lists.zx2c4.com/mailman/listinfo/wireguard

[-- Attachment #1.2: Type: text/html, Size: 14465 bytes --]

[-- Attachment #2: Type: text/plain, Size: 148 bytes --]

_______________________________________________
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard

RE: Wireguard command line tools for Android

[Joachim Lindenberg]

[-- Attachment #1.1: Type: text/plain, Size: 5775 bytes --]

Unfortunately changing IP-Addresses on subscriber lines is very common in Germany, unless you pay extra money for a “static” IP. I definitely support Thomas´ request to renew the binding via DNS when the tunnel is broken.

Thanks, Joachim

 

From: WireGuard <wireguard-bounces@lists.zx2c4.com> On Behalf Of David Kerr
Sent: Dienstag, 6. August 2019 14:34
To: boerner@t-online.de
Cc: wireguard@lists.zx2c4.com
Subject: Re: Wireguard command line tools for Android

 

Hi Tom,

  Yes I have a stable IP external address.  Under normal circumstances it only changes if I change device (the MAC address) that requests the dhcp lease.  Thus I only have to deal with roaming (changing IPs) on my client device(s) not the server.  I have never heard of a ISP that changes an assigned IP address every 24 hours, its pretty unfriendly practice.  Normally client devices request renewal of the specific IP address it was previously assigned, so your ISP is explicitly refusing to renew that and causing the client to request a new IP.  I would be seeking a new ISP in your situation.

 

David

 

On Tue, Aug 6, 2019 at 3:17 AM <boerner@t-online.de <mailto:boerner@t-online.de> > wrote:

Hi David,

Thanks for your elaborate answer!

 

Yes, your assumption is right - my clients connect to a URL that resolves to an internal address when inside my local LAN. The idea was to keep traffic internal whenever possible. 

I have now followed your suggestion and have my VPN URL always resolved to the external IP address so the address won't change when leaving/entering the local network.

For me, this solves a part of my issue but not all of it. 

My router is assigned a new external address (both IPv4 and IPv6) every 24 h, and obviously this invalidates the public IP adresses known by the server and the client simultaneously, as they are identical for the clients connected to the local network. That makes the handshake fail, and "wg" on the server shows that it is still looking for its endpoints at the old address. The same is true for the clients.

Disconnecting/reconnecting the clients fixes the tunnel until the next address change, because then Wireguard looks for the DNS record instead of using its stored address information. I think it would be a good feature if Wireguard could refresh its endpoint addresses automatically when an endpoint is not reachable anymore.

 

How does it work on your side? Have you a constant external IP address?

 

Thomas

 

 

Am Montag, 5. August 2019, 23:28:41 CEST schrieb David Kerr:

I assume you have set the client configs to connect to something like " <http://vpn.example.com> vpn.example.com:<port>" . How does DNS resolve this when inside your local LAN?  Does it resolve to the same public IP address that your DSL router is connected to, or does it resolve to an internal address like 192.168.1.1?

 

The way I have this working is to ensure that my VPN URL always resolves to the external IP address, even when I am inside my home network.  To do that I had to update my DNS server configuration to make sure that my VPN URL is always resolved by an external DNS provider... I have my own custom network gateway/router and set dnsmasq.static to include the line...

 

server=/ <http://vpn.example.com/8.8.8.8> vpn.example.com/8.8.8.8

 

Now this works for me because my wireguard server is running on my custom gateway/router... no NAT forwarding to an internal host running wireguard.  If you are running wireguard on an internal server then you also need to make sure that your firewall rules don't block connections to your external interface from your local LAN and do the right NATing -- which is probably not permitted by default.  I forget how to do this, but I'm sure google will find some instructions.

 

David

 

 

 

 

On Mon, Aug 5, 2019 at 2:57 PM < <mailto:boerner@t-online.de> boerner@t-online.de> wrote:

Hey all,

I've recently set up my private VPN with Wireguard. I am running my local server behind a DSL router with a variable public IP address, accessible via dyndns and NAT, and several mobile clients (Android, Notebooks). 
Everything is working fine so far, except of one issue that I would like discuss here: 
Roaming doesn't work reliably when a device leaves or re-enters the home LAN, nor when the public IP address is changed by my ISP. The reason seems clear to me: In these cases both peers change their IP address simultaneously whereas the Wireguard protocol relies on only one address changing at a time.

My approach would be to shut down Wireguard on the clients as long as they are connected to their home network locally and to bring up the tunnel only when they leave the home network. Besides the roaming issue it  would be desirable to use the local connection when it is available rather than to take the detour over the internet. And it  should be done automatically so users need not remember to switch on/off VPN all the time.
My idea was to use Tasker to perform something like wg-quick up|down tun1 accordingly, but the Wireguard command line tools wg and wg-quick don't seem to be available (anymore). In older forum posts I've seen that you can install them from the app settings, but in my version (v0.0.20190708) this option is not available.

Does anybody know about another solution? Or, as a question to the developers, would it be a big deal to bring back the command line feature?

Thanks, Tom




_______________________________________________
WireGuard mailing list
 <mailto:WireGuard@lists.zx2c4.com> WireGuard@lists.zx2c4.com
 <https://lists.zx2c4.com/mailman/listinfo/wireguard> https://lists.zx2c4.com/mailman/listinfo/wireguard

 


[-- Attachment #1.2: Type: text/html, Size: 15026 bytes --]

[-- Attachment #2: Type: text/plain, Size: 148 bytes --]

_______________________________________________
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard

Re: Wireguard command line tools for Android

[Yağmur Oymak]

On Sat, 2019-07-27 at 18:01 +0200, boerner@t-online.de wrote:
> My idea was to use Tasker to perform something like wg-quick up|down
> tun1 accordingly, but the Wireguard command line tools wg and wg-
> quick don't seem to be available (anymore). In older forum posts I've
> seen that you can install them from the app settings, but in my
> version (v0.0.20190708) this option is not available.
> 
> Does anybody know about another solution? Or, as a question to the
> developers, would it be a big deal to bring back the command line
> feature?

Hey,

The command line tools were not removed. If you are using the Go
userspace backend (the app will indicate this in settings, together
with the version information) they will not be available. The tools
control the kernel backend and require root access. Thus they are only
available if you are running a custom kernel with WireGuard support and
have root access.

--
Yagmur Oymak

_______________________________________________
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard

Re: Wireguard command line tools for Android

[Thomas Börner]

[-- Attachment #1.1: Type: text/plain, Size: 1370 bytes --]

Thanks for the clarification!
But this also means that a Tasker workaround would not be feasible for a common user.
Thus,  renewing the binding via DNS when the tunnel is broken would be most desirable, as I already proposed.


Am 7. August 2019 12:52:19 MESZ schrieb "Yağmur Oymak" <yagmur.oymak@gmail.com>:
>On Sat, 2019-07-27 at 18:01 +0200, boerner@t-online.de wrote:
>> My idea was to use Tasker to perform something like wg-quick up|down
>> tun1 accordingly, but the Wireguard command line tools wg and wg-
>> quick don't seem to be available (anymore). In older forum posts I've
>> seen that you can install them from the app settings, but in my
>> version (v0.0.20190708) this option is not available.
>> 
>> Does anybody know about another solution? Or, as a question to the
>> developers, would it be a big deal to bring back the command line
>> feature?
>
>Hey,
>
>The command line tools were not removed. If you are using the Go
>userspace backend (the app will indicate this in settings, together
>with the version information) they will not be available. The tools
>control the kernel backend and require root access. Thus they are only
>available if you are running a custom kernel with WireGuard support and
>have root access.
>
>--
>Yagmur Oymak

-- 
Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.

[-- Attachment #1.2: Type: text/html, Size: 1771 bytes --]

[-- Attachment #2: Type: text/plain, Size: 148 bytes --]

_______________________________________________
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard

Re: Wireguard command line tools for Android

[Thomas Börner]

[-- Attachment #1.1: Type: text/plain, Size: 1368 bytes --]

Thanks for the clarification!
But this also means that a Tasker workaround would not be feasible for a common user.
Thus,  renewing the binding via DNS when the tunnel is broken would be most desirable, as I already proposed.

Am 7. August 2019 12:52:19 MESZ schrieb "Yağmur Oymak" <yagmur.oymak@gmail.com>:
>On Sat, 2019-07-27 at 18:01 +0200, boerner@t-online.de wrote:
>> My idea was to use Tasker to perform something like wg-quick up|down
>> tun1 accordingly, but the Wireguard command line tools wg and wg-
>> quick don't seem to be available (anymore). In older forum posts I've
>> seen that you can install them from the app settings, but in my
>> version (v0.0.20190708) this option is not available.
>> 
>> Does anybody know about another solution? Or, as a question to the
>> developers, would it be a big deal to bring back the command line
>> feature?
>
>Hey,
>
>The command line tools were not removed. If you are using the Go
>userspace backend (the app will indicate this in settings, together
>with the version information) they will not be available. The tools
>control the kernel backend and require root access. Thus they are only
>available if you are running a custom kernel with WireGuard support and
>have root access.
>
>--
>Yagmur Oymak

-- 
Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.

[-- Attachment #1.2: Type: text/html, Size: 1767 bytes --]

[-- Attachment #2: Type: text/plain, Size: 148 bytes --]

_______________________________________________
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard