Development discussion of WireGuard
 help / color / mirror / Atom feed
* Is default MTU correct?
@ 2020-10-11 14:27 igo95862
  0 siblings, 0 replies; 2+ messages in thread
From: igo95862 @ 2020-10-11 14:27 UTC (permalink / raw)
  To: wireguard

Was thinking why my wireguards connection had MTU of 1420.

The default MTU is calculated here:
https://github.com/torvalds/linux/blob/master/drivers/net/wireguard/device.c#L255

Which results in MTU of 1420 for wg-quick and systemd-networkd.

The first issue at glance is that it does not account for extension 
headers. (as well as if client is behind MTU lower than 1500)

However, I decided to test what happends if I increase or decrease MTU 
and see what happends to packets with Wireshark. Wireshark can display 
the payload length of Wireguard.

These are the maximum packet (the outer IP packet) and payload (the IP 
packet inside Wireguard) sizes I saw. My endpoint MTU is 1500. (end 
point is not under my administration)

Default MTU of 1420:
  Incoming packet: length 1494, datalen 1420
  Outgoing packet: length 1494, datalen 1420

  As you can see there are 6 bytes missing from maximum MTU.


MTU of 3000:
  Incoming packet: length 1494, datalen 1420
  Outgoing packet: length 1498, datalen 1424

  I thought the connection would break or start fragmenting but it 
seems like there was
  somekind of Path MTU Discovery which determined the MTU to be 1498, 
much closer to the
  actual MTU of 1500. I guess the missing two bytes are because of some 
allignment.

MTU of 1350:
  Incoming packet: length 1434, datalen 1360 (two packets of 1494/1420)
  Outgoing packet: length 1424, datalen 1350

  The outgoing packet had the exact datalen of 1350, howver, the 
incoming packets added
  extra 10 bytes somehow.


As you can see there is a Path MTU Discovery that seems to be working.
The question is should the default even be set 1420?
If the kernel can determine the correct MTU of 1424 (not sure why 2 
bytes are missing)
why not set MTU to something really high and make kernel find the 
actual MTU?

Idealy kernel should find the MTU during initialization of Wireguard 
device.




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

* Is default MTU correct?
@ 2020-10-12 10:37 igo95862
  0 siblings, 0 replies; 2+ messages in thread
From: igo95862 @ 2020-10-12 10:37 UTC (permalink / raw)
  To: wireguard

Was thinking why my wireguards connection had MTU of 1420.

The default MTU is calculated here:
https://github.com/torvalds/linux/blob/master/drivers/net/wireguard/device.c#L255

Which results in MTU of 1420 for wg-quick and systemd-networkd.

The first issue at glance is that it does not account for extension 
headers. (as well as if client is behind MTU lower than 1500)

However, I decided to test what happends if I increase or decrease MTU 
and see what happends to packets with Wireshark. Wireshark can display 
the payload length of Wireguard.

These are the maximum packet (the outer IP packet) and payload (the IP 
packet inside Wireguard) sizes I saw. My endpoint MTU is 1500. (end 
point is not under my administration)

Default MTU of 1420:
 Incoming packet: length 1494, datalen 1420
 Outgoing packet: length 1494, datalen 1420

 As you can see there are 6 bytes missing from maximum MTU.


MTU of 3000:
 Incoming packet: length 1494, datalen 1420
 Outgoing packet: length 1498, datalen 1424

 I thought the connection would break or start fragmenting but it seems 
like there was
 somekind of Path MTU Discovery which determined the MTU to be 1498, 
much closer to the
 actual MTU of 1500. I guess the missing two bytes are because of some 
allignment.

MTU of 1350:
 Incoming packet: length 1434, datalen 1360 (two packets of 1494/1420)
 Outgoing packet: length 1424, datalen 1350

 The outgoing packet had the exact datalen of 1350, howver, the 
incoming packets added
 extra 10 bytes somehow.


As you can see there is a Path MTU Discovery that seems to be working.
The question is should the default even be set 1420?
If the kernel can determine the correct MTU of 1424 (not sure why 2 
bytes are missing)
why not set MTU to something really high and make kernel find the 
actual MTU?

Idealy kernel should find the MTU during initialization of Wireguard 
device.




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

end of thread, other threads:[~2020-10-16 13:17 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-10-11 14:27 Is default MTU correct? igo95862
2020-10-12 10:37 igo95862

Development discussion of WireGuard

This inbox may be cloned and mirrored by anyone:

	git clone --mirror http://inbox.vuxu.org/wireguard

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V1 wireguard wireguard/ http://inbox.vuxu.org/wireguard \
		wireguard@lists.zx2c4.com
	public-inbox-index wireguard

Example config snippet for mirrors.
Newsgroup available over NNTP:
	nntp://inbox.vuxu.org/vuxu.archive.wireguard


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git