wireguard.lists.zx2c4.com archive mirror
 help / color / mirror / Atom feed
From: Brian Candler <b.candler@pobox.com>
To: wireguard@lists.zx2c4.com
Subject: MTU on public wifi
Date: Tue, 3 Jul 2018 08:41:28 +0100	[thread overview]
Message-ID: <e42d9e5f-fbc0-e56c-314d-1a8d0309a97d@pobox.com> (raw)

I was testing wireguard via a public wifi service (Icomera on-train=20
wifi) and found that the tunnel MTU wireguard had chosen was too large:=20
TCP connections got stuck as soon as any large amount of data was sent=20
(e.g. just running "top")

The MTU of the wifi service itself is 1440:

MacBook-Pro-2:~ $ ping -s1412 -D 8.8.8.8
PING 8.8.8.8 (8.8.8.8): 1412 data bytes
1420 bytes from 8.8.8.8: icmp_seq=3D0 ttl=3D58 time=3D46.006 ms
1420 bytes from 8.8.8.8: icmp_seq=3D1 ttl=3D58 time=3D40.847 ms
^C
--- 8.8.8.8 ping statistics ---
[Interface]
2 packets transmitted, 2 packets received, 0.0% packet loss
round-trip min/avg/max/stddev =3D 40.847/43.427/46.006/2.579 ms
MacBook-Pro-2:~ $ ping -s1414 -D 8.8.8.8
PING 8.8.8.8 (8.8.8.8): 1414 data bytes
556 bytes from 10.101.2.1: frag needed and DF set (MTU 1440)
Vr HL TOS=C2=A0 Len=C2=A0=C2=A0 ID Flg=C2=A0 off TTL Pro=C2=A0 cks=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0 Src Dst
 =C2=A04=C2=A0 5=C2=A0 00 a205 33b6=C2=A0=C2=A0 0 0000=C2=A0 40=C2=A0 01 =
e44d 10.101.2.227 8.8.8.8

(Payload 1412 + 20 bytes IP header + 8 bytes ICMP header =3D 1440)

The client is macOS wireguard-tools/wireguard-go.=C2=A0 Wireguard itself =
had=20
set an MTU on utun1 of 1440.=C2=A0 With some experimentation, I found tha=
t=20
setting MTU of 1400 was fine, but 1410 was too big.

With "MTU =3D 1400" in wg0.conf it now appears to work correctly, althoug=
h=20
I'm not sure how safe that value is - does Wireguard compress data=20
before encapsulation, and therefore is there a chance that worst-case=20
encapsulated packets could still be too big?

But I did try "dd if=3D/dev/urandom bs=3D1024 count=3D100" and it did sen=
d the=20
whole random splurge without locking up the TCP connection.

I also wonder if wireguard could automatically reduce its MTU in=20
response to ICMP "frag needed" packets, at least down to a configured=20
minimum?

Regards,

Brian Candler.

                 reply	other threads:[~2018-07-03  7:35 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

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=e42d9e5f-fbc0-e56c-314d-1a8d0309a97d@pobox.com \
    --to=b.candler@pobox.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).