Development discussion of WireGuard
 help / color / mirror / Atom feed
From: Baptiste Jonglez <baptiste@bitsofnetworks.org>
To: "Jason A. Donenfeld" <Jason@zx2c4.com>
Cc: WireGuard mailing list <wireguard@lists.zx2c4.com>
Subject: Re: Memleak with 0.0.20171221-5 on Debian stretch
Date: Mon, 12 Feb 2018 08:42:55 +0100	[thread overview]
Message-ID: <20180212074255.GB5305@tuxmachine.localdomain> (raw)
In-Reply-To: <20180212073501.GA5305@tuxmachine.localdomain>

[-- Attachment #1: Type: text/plain, Size: 1725 bytes --]

On 12-02-18, Baptiste Jonglez wrote:
> Hi Jason,
> 
> On 12-02-18, Jason A. Donenfeld wrote:
> > Secondly, I'm wondering if you tend to do, "anything strange". For
> > example -- are you setting up and taking down the device often in an
> > automated way? Or reconfiguring the interface (via wg(8), for example)
> > often in an automated way? Or is the sustained day-in-day-out workload
> > that leads to this graph simply forwarding and encrypting/decrypting
> > packets as usual? If it's the latter, does this device tend to encrypt
> > or decrypt more, or both equally?
> 
> It's the latter "day-in-day-out" option: the system has a single wireguard
> interface, which is configured once at boot-time, and then used
> extensively to forward traffic.  It tends to encrypt more than it
> decrypts.

Actually, now that I talk about it, it's not 100% true: on this system,
there is a second wireguard interface that is not currently used (it's
provisionned to connect a future router that is not yet deployed).

The interesting part: this interface has a single peer which has no
endpoint but a persistent keepalive.  It looks like this:

    interface: wg-router2
      public key: XXXXXXXXXXXXXXXXXX
      private key: (hidden)
      listening port: 56008

    peer: YYYYYYYYYYY
      allowed ips: 0.0.0.0/0, ::/0
      persistent keepalive: every 25 seconds

Maybe wireguard allocates something to send the persistent keepalive, then
bails out because we don't know the endpoint of the peer?

I have taken this second interface down, but it has not released any
memory.  I am now leaving it up without the persistent keepalive, just in
case something interesting happens.

Baptiste

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

  reply	other threads:[~2018-02-12  7:36 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-02-11 13:48 Baptiste Jonglez
2018-02-11 18:20 ` Daniel Kahn Gillmor
2018-02-11 18:43   ` Baptiste Jonglez
2018-02-12  0:23     ` Jason A. Donenfeld
2018-02-12  7:35       ` Baptiste Jonglez
2018-02-12  7:42         ` Baptiste Jonglez [this message]
2018-02-12 11:04           ` Jason A. Donenfeld
2018-02-13 13:17             ` Baptiste Jonglez
2018-02-18 20:39               ` Jason A. Donenfeld
2018-02-22  7:45                 ` Baptiste Jonglez
2018-02-12  3:34     ` Daniel Kahn Gillmor

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20180212074255.GB5305@tuxmachine.localdomain \
    --to=baptiste@bitsofnetworks.org \
    --cc=Jason@zx2c4.com \
    --cc=wireguard@lists.zx2c4.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).