<div dir="ltr">Hi Mathias,<div><br></div><div>Did you had thought about the support of wireguard-go for android?</div><div>I'll be happy to rebase the work I did before on wireguard-go to get that a new go.</div><div dir="ltr"><div><br></div><div>Aurélien</div><div><br></div></div><div class="gmail_quote"><div dir="ltr">On Thu, Nov 9, 2017 at 8:50 AM Aurélien Chabot <<a href="mailto:aurelien@chabot.fr" target="_blank">aurelien@chabot.fr</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><p dir="ltr">The GetUDPConn is used to forward the socket id to the Java layer. The android API allow to protect the socket from being route to the VPN, making the job of using the VPN as default route easy.</p>
<p dir="ltr">About the close, good to know I am not missing something. I might spit the patch then, so the bug fix doesn't get stuck with the rest.</p>
<p dir="ltr">Aurélien</p>
<br><div class="gmail_quote"><div dir="ltr">On Thu, Nov 9, 2017, 04:48 Mathias Hall-Andersen <<a href="mailto:mathias@hall-andersen.dk" target="_blank">mathias@hall-andersen.dk</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Aurélien<br>
<br>
Thanks for contributing to the wireguard-go project.<br>
<br>
I never anticipated for the implementation to be used as a library.<br>
This means that I either have to:<br>
<br>
1. Settle for an API and reconsider what is exported and not.<br>
2. Give no guarantees about API stability<br>
<br>
Providing the functionality as a library might be the cleanest solution<br>
in this case.<br>
One option is to have an internal package and a small exported API.<br>
<br>
Is the GetUDPConn only used to wait for the device to bind?<br>
<br>
The missing device.tun.device.Close() is indeed a bug.<br>
<br>
I will look more at your patches during the weekend,<br>
Thanks once again.<br>
<br>
Mathias<br>
</blockquote></div></blockquote></div></div>