Development discussion of WireGuard
 help / color / mirror / Atom feed
* Better Output
@ 2022-04-17  8:22 Hendrik Friedel
  2022-04-17 19:05 ` Aaron Jones
  0 siblings, 1 reply; 3+ messages in thread
From: Hendrik Friedel @ 2022-04-17  8:22 UTC (permalink / raw)
  To: wireguard

Hello,

when using wireguard - both Android and Windows - clients, I in the past 
often thought that the connection is fine but in fact, I had a wrong 
Key.
The Windows-Client showed a green Checkmark under Status. The Android 
Client showed the "key" symbol and it showed also the "switch" on the 
right hand side (=activ) and blue.
Obviously, the connection was not working, but I would have hoped that 
Wireguard would have told me, that the connection was not ok.
In fact, I was only able to determine whether the connection was working 
by trying to access some Service (e.g. google) or by observing the 
"Received/bytes" counter which remained at 0.

I would suggest an improvement here:
1) If no Server responds on the particular domain/IP, wireguard should 
show a message
     Could not connect to [my.domain.com] under IP 
[2a00:1234:1234:c700:ba27:ebff:fe3e:2342] or 1.4.4.1.
2) If a wireguard server responds, but the key is not valid it should 
show a message
     Connection failed. Host responded, but key was invalid
3) If the connection fails, the Windows Client should show a RED symbol 
under status.
4) If the connection fails, the "key" symbol should not be shown under 
Android and the toggle-switch should move from right&blue (active) back 
to left&grey.

Would that be possible?

Greetings,
Hendrik


^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: Better Output
  2022-04-17  8:22 Better Output Hendrik Friedel
@ 2022-04-17 19:05 ` Aaron Jones
  2022-04-18  8:40   ` Re[2]: " Hendrik Friedel
  0 siblings, 1 reply; 3+ messages in thread
From: Aaron Jones @ 2022-04-17 19:05 UTC (permalink / raw)
  To: wireguard; +Cc: Hendrik Friedel


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

On 17/04/2022 08:22, Hendrik Friedel wrote:
 > I would suggest an improvement here:
 >
 > 1) If no Server responds on the particular domain/IP,
 >    wireguard should show a message

This would be technically achievable, but note that WireGuard
uses UDP, which has no concept of "connections". See also
below.

 > 2) If a wireguard server responds, but the key is not valid

WireGuard does not respond if the keys are not valid. See
section 5.1 ("Silence is a Virtue") in the WireGuard
whitepaper [1].

 > 3) If the connection fails, the Windows Client should show
 >    a RED symbol under status.

This could only be determined by a previously-in-use session
having had no packets received for greater than the maximum
rekey interval (2 minutes).

However, WireGuard itself will not send any data if it has no
data to send (same section of the whitepaper), and so if you
are not using the tunnel for 2 minutes, this would be
indistinguishable from a failed tunnel.

An exception is if you enable keepalives; they are 0-length
data packets.

[1] https://www.wireguard.com/papers/wireguard.pdf

Regards,
Aaron Jones


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re[2]: Better Output
  2022-04-17 19:05 ` Aaron Jones
@ 2022-04-18  8:40   ` Hendrik Friedel
  0 siblings, 0 replies; 3+ messages in thread
From: Hendrik Friedel @ 2022-04-18  8:40 UTC (permalink / raw)
  To: Aaron Jones, wireguard

Hello Aaron,

thanks for your reply.

>This would be technically achievable, but note that WireGuard
>uses UDP, which has no concept of "connections". See also
>below.
That is understood. But one can distinguish between a situation where a 
(not sure about an alternative word) "connection" was established and 
where not.

By the way: What does the Green Symbol today in the windows-client tell 
me? Currently, I find it totally mis-leading. I think today it only 
shows that:
1) the domain could be resolved to an IP
2) data was sent to it
That seems not very useful.

> > 2) If a wireguard server responds, but the key is not valid
>
>WireGuard does not respond if the keys are not valid. See
>section 5.1 ("Silence is a Virtue") in the WireGuard
>whitepaper [1].
Then, Silence is also a sign of a failed connection, no? --> red symbol. 
But ok, it cannot show the reason "key invalid".

> > 3) If the connection fails, the Windows Client should show
> >    a RED symbol under status.
>
>This could only be determined by a previously-in-use session
>having had no packets received for greater than the maximum
>rekey interval (2 minutes).
Why? If a connection is established, data is received, in my experience 
--> green Symbol. If no data is received --> red.
Sorry, but having to check the "bytes received" and ignoring the green 
symbol is hardly intuitive (a bit geeky, if I may say that). The 99% 
user does not know the backgrounds and/or the whitepaper.

>However, WireGuard itself will not send any data if it has no
>data to send (same section of the whitepaper), and so if you
>are not using the tunnel for 2 minutes, this would be
>indistinguishable from a failed tunnel.
Well, I was only thinking about the esablishing of a connection, not the 
situation while a tunnel is up (but not used).
So, I understand that an icon that was turned green once may have to 
stay green (as one cannot distinguish between no data *intended* to be 
transmitted and no data transmitted *unintendedly*/failed connection.
Unless:

>An exception is if you enable keepalives; they are 0-length
>data packets.
In that case, the Icon would always be able to reflect the real status.

Now, would that not be something for the ToDo List?

Best regards,
Hendrik

>
>
>[1] https://www.wireguard.com/papers/wireguard.pdf
>
>Regards,
>Aaron Jones
>


^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2022-04-18  8:40 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-04-17  8:22 Better Output Hendrik Friedel
2022-04-17 19:05 ` Aaron Jones
2022-04-18  8:40   ` Re[2]: " Hendrik Friedel

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).