Request: Optional "Comment" [Peer] entry

Request: Optional "Comment" [Peer] entry

[Michael Keuter]

Hi Jason,

I would also like to have the optional "Comment" field.
And since its optional, people who like it, could use this, others not =
=E2=80=A6
But it would be nice, if it would be shown in the "wg" output, if its =
not empty.

Michael

http://www.mksolutions.info

Re: Request: Optional "Comment" [Peer] entry

[Antonio Quartulli]

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



On 17/11/17 17:20, Jason A. Donenfeld wrote:
> Hi Lonnie,
> 
> Quite a few people have requested this, and I've implemented it, but
> never had the motivation to merge it. I keep hesitating between
> thinking that it's a reasonable thing to want, and thinking that it's
> not appropriate to have in a low level tool, and that whatever
> configuration management apparatus you're using should handle it
> instead. Usually I just defer thinking about it until later, but given
> it's come up again, I probably should revisit the issue. There is some
> precedent for this kind of thing: net devices have ifalias and
> iptables has the comment target. However, routes in the routing table
> don't have comments, and neither do IP address assignments on
> interfaces (unless you're counting rDNS). So, hm. I'll think about it.

Just an idea from another kernel module:

in batman-adv (a Layer2 routing protocol implemented in kernelspace)
there was a similar problem: people wanted to give names to peers rather
than using their (almost impossible to remember) MAC-addresses.

Given that batman-adv also comes with its own userspace tools, namely
batctl, the latter has been extended with a name-conversion functionality.
It basically relies on a file called /etc/bat-hosts the same way as most
linux commands rely on /etc/hosts when printing an hostnames/IPs to screen.

The difference is that bat-hosts contains a MAC-addresses instead of IPs
- being batman-adv a L2 protocol.

How it works: whenever batctl has to print a peer ID to screen, it will
first search the bat-hosts file for a matching entry and then, if one is
found, the related name is printed. The MAC-address is printed otherwise.

Couldn't wg do something similar? Maybe using some kind of
*/etc/wg-name* file containing a mapping from peer-key to
peer-name/comment? Or even by re-using the original configuration file
(with a new Comment/Name field).

This way the logic would all reside in the userspace tool without
touching the kernel module at all.

The same name conversion applies also for 'input' commands. I.e. you
could tell batctl to "ping" a name and it would first convert it to a
MAC address and then pass it down to the kernel module. Not sure if this
can happen to wg as well.


just my 2 cents.

Cheers,


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

-- 
Antonio Quartulli


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

Re: Request: Optional "Comment" [Peer] entry

[Jason A. Donenfeld]

Hi Lonnie,

Quite a few people have requested this, and I've implemented it, but
never had the motivation to merge it. I keep hesitating between
thinking that it's a reasonable thing to want, and thinking that it's
not appropriate to have in a low level tool, and that whatever
configuration management apparatus you're using should handle it
instead. Usually I just defer thinking about it until later, but given
it's come up again, I probably should revisit the issue. There is some
precedent for this kind of thing: net devices have ifalias and
iptables has the comment target. However, routes in the routing table
don't have comments, and neither do IP address assignments on
interfaces (unless you're counting rDNS). So, hm. I'll think about it.

Jason

Re: Request: Optional "Comment" [Peer] entry

[Matthias Urlichs]

On 17.11.2017 09:20, Manuel Schölling wrote:
> You could also use it for naming peers, i.e. using "Peer-(?P<name>[A-Za-z0-9\-]+)".

The usual way is to use a space as separator, i.e.

[Peer uplink]

This solves the naming issue. Nevertheless, a Comment= entry would also
be a good idea.

Also, after adding names we should use them as primary peer identifiers,
instead of their pubkeys.

-- 
-- Matthias Urlichs

Re: Request: Optional "Comment" [Peer] entry

[Manuel Schölling]

I like the idea of comments!

And while we're at it: having multiple [Peer] section in incompatible
with most other config parsing tools (e.g. python std library's
configparser [1]).
Maybe we could allow the peer section names to be of the form "Peer[A-
Za-z0-9\-]*" or something?
You could also use it for naming peers, i.e. using "Peer-(?P<name>[A-
Za-z0-9\-]+)".

Bye,

Manuel

[1] https://docs.python.org/3.5/library/configparser.html

On Thu, 2017-11-16 at 14:31 -0600, Lonnie Abelbeck wrote:
> I have a suggestion, feature request ...
> 
> With several peers, the output of "wg show" is difficult to visually
> identify the peers at a quick glance.
> 
> How about an optional "Comment = " entry for the [Peer] section.
> 
> For Example:
> --
> [Peer]
> PublicKey = UMJMPFVTzjmzr7SJMQ7k+Z+3Pr1aq4w+5chtUny6Akg=
> Endpoint = [fda6:66b2:b74a:50::3]:51820
> AllowedIPs = 10.4.0.2/32
> Comment = pbx3 - Jetway NF9HG-2930
> --
> 
> For each peer in "wg show" with a "Comment = " defined ...
> --
> peer: HIgo9xNzJMWLKASShiTqIybxZ0U3wGLiUeJ1PKf8ykw=
>   endpoint: [fda6:662b:b74a:50::3]:51820
>   allowed ips: 10.4.0.2/32
>   latest handshake: 3 seconds ago
>   transfer: 376 B received, 680 B sent
>   comment: pbx3 - Jetway NF9HG-2930
> --
> 
> If others like this idea, should the comment be displayed first,
> last, etc. ?
> 
> Truncating the comment string to 64 characters would be fine.  Or
> even 32 chars.
> 
> Thoughts ?
> 
> Lonnie
> 
> _______________________________________________
> WireGuard mailing list
> WireGuard@lists.zx2c4.com
> https://lists.zx2c4.com/mailman/listinfo/wireguard

Request: Optional "Comment" [Peer] entry

[Lonnie Abelbeck]

I have a suggestion, feature request ...

With several peers, the output of "wg show" is difficult to visually =
identify the peers at a quick glance.

How about an optional "Comment =3D " entry for the [Peer] section.

For Example:
--
[Peer]
PublicKey =3D UMJMPFVTzjmzr7SJMQ7k+Z+3Pr1aq4w+5chtUny6Akg=3D
Endpoint =3D [fda6:66b2:b74a:50::3]:51820
AllowedIPs =3D 10.4.0.2/32
Comment =3D pbx3 - Jetway NF9HG-2930
--

For each peer in "wg show" with a "Comment =3D " defined ...
--
peer: HIgo9xNzJMWLKASShiTqIybxZ0U3wGLiUeJ1PKf8ykw=3D
  endpoint: [fda6:662b:b74a:50::3]:51820
  allowed ips: 10.4.0.2/32
  latest handshake: 3 seconds ago
  transfer: 376 B received, 680 B sent
  comment: pbx3 - Jetway NF9HG-2930
--

If others like this idea, should the comment be displayed first, last, =
etc. ?

Truncating the comment string to 64 characters would be fine.  Or even =
32 chars.

Thoughts ?

Lonnie