All of lore.kernel.org
 help / color / mirror / Atom feed
From: Simon Rozman <simon@rozman.si>
To: Daniel Lenski <dlenski@gmail.com>, David Woodhouse <dwmw2@infradead.org>
Cc: WireGuard mailing list <wireguard@lists.zx2c4.com>
Subject: RE: Allowing space for packet headers in Wintun Tx/Rx
Date: Mon, 12 Apr 2021 11:38:30 +0000	[thread overview]
Message-ID: <9940aef2c1064fc785b51ac860020a18@rozman.si> (raw)
In-Reply-To: <CAOw_LSGV8V9aLg-UdN4SE5s5o7NFfeyH+Q+mWMrvrBYp06aT=w@mail.gmail.com>

Hi,

> > Looks good to me; thanks. Just need to work out how to cross-build it
> > (I can muster up a Windows VM for testing, but *building* on it is
> > beyond my tolerance of Windows for now).
> 
> +1 to all that.

Don't worry. Once Jason is back, reviews and (hopefully) approves the changes, we shall prepare an official release for you.

> > We'll also need to be able to WintunAllocateSendPacket() of the full
> > possible MTU, then receive and decrypt into that, and send only the
> > actual size of the packet we received.

How about this: https://git.zx2c4.com/wintun/commit/?id=03b6cd410c8963d1888966edf31fdc35a4c8b523

Should be backward compatible. Tested with the existing stable wireguard-windows release 0.3.10.

> There are two cases worth considering where the packet size could
> actually *expand*:
> 
> 1) Some VPN protocols support compression of the tunneled packets. It
> would be bad behavior to use this to stuff a packet of >(advertised
> MTU) bytes in <(advertised MTU) bytes, but it wouldn't surprise me if it
> exists in the wild. We now deal with receipt of larger-than-expected-MTU
> packets in OpenConnect in a relatively uniform way: allocate MAX(mtu,
> 16384) bytes for packets coming from the VPN (if using TLS transport) or
> MAX(mtu, 2048) if using DTLS.
> 2) Some VPN protocols concatenate multiple packets into a single
> aggregate on the wire. On Linux we can decrypt, truncate, and send to
> the tunnel interface without further copying.
> 
> Case (1) can be handled with overallocate-and-shrink. Case (2) is pretty
> rare among the protocols that OpenConnect supports, so fallback to
> memcpy seems fine.

Phew! Thanks. :)

Regards,
Simon

  reply	other threads:[~2021-04-12 11:38 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-04-07 11:49 Allowing space for packet headers in Wintun Tx/Rx David Woodhouse
2021-04-07 23:15 ` Daniel Lenski
2021-04-08 14:37   ` David Woodhouse
2021-04-08 16:42     ` Daniel Lenski
2021-04-08 17:10       ` David Woodhouse
2021-04-08 17:37         ` Daniel Lenski
2021-04-10 13:38         ` Simon Rozman
2021-04-10 14:35           ` David Woodhouse
2021-04-10 18:32             ` Daniel Lenski
2021-04-12 11:38               ` Simon Rozman [this message]
2021-04-12 13:00                 ` David Woodhouse
2021-04-12 17:03                   ` Jason A. Donenfeld
2021-04-13 22:09                     ` Jason A. Donenfeld

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=9940aef2c1064fc785b51ac860020a18@rozman.si \
    --to=simon@rozman.si \
    --cc=dlenski@gmail.com \
    --cc=dwmw2@infradead.org \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.