Development discussion of WireGuard
 help / color / mirror / Atom feed
* Behaviour on MTU problem
@ 2021-08-30 18:43 M. Dietrich
  2021-08-30 19:55 ` Art Botterell
  0 siblings, 1 reply; 3+ messages in thread
From: M. Dietrich @ 2021-08-30 18:43 UTC (permalink / raw)
  To: wireguard

Hi friends of Wireguard,

i am neither a network guru nor a kernel hacker and after all 
i had no time to fully investigate the case. so please read 
with a grain of salt.

i had my notebook in a wifi network lately that seemed to have 
some MTU size problems. download worked fine while uploads 
blocked for bigger packages. when i set the MTU down to 1200 
on the wg interface the same upload worked fine.

this was obviously a problem of that very wifi network and is
not related to wg at all, the dhcp answer did not even contain 
any MTU hints, so 1500 was assumed.

anyway the kernel locked up. commands like `ip` or `wg-quick 
down ...` get stuck and ^C oder even a `kill -9 ...` did not 
end the processes. any access to the wg interface blocked.

my question is if that scenario (misconfigured MTU size in the 
"outer network") is tested and works fine. i know that MTU 
size problem lead to lockups (that's why i immediatly came to 
that conclusion) but never saw such a hard lockup related to 
commands like `ip`.

if my assumption is just stupid let me know. if not i would 
further investigate the case, setup a test scenario and burn 
some time. what do you think?

best regards, michael

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

* Re: Behaviour on MTU problem
  2021-08-30 18:43 Behaviour on MTU problem M. Dietrich
@ 2021-08-30 19:55 ` Art Botterell
  2021-10-04  5:30   ` M. Dietrich
  0 siblings, 1 reply; 3+ messages in thread
From: Art Botterell @ 2021-08-30 19:55 UTC (permalink / raw)
  To: wireguard

Hi Michael,

One reads about fragmentation-induced failures and about various MTU values that did or didn't work in a particular situation.  We can infer a certain amount from the stories, but I haven’t seen any sort of systematic characterization of the phenomenon.  Seems like it might be a good research project for somebody.

Please note, however, that I’m glad to be schooled if there’s a resource on the topic that I’ve overlooked.

Personally I’d be very interested in understanding what we could look out for in order automatically to detect MTU issues and adapt to the particular demands of a remote installation on complex host networks that may have fragmentation-inducing devices (or protocols, e.g., PPPoS) on the route to the Internet that we don’t control or even know about.  My inference from what I’ve read is that for any particular network route there is some maximum MTU value that will work without fragmentation.  (I think there may be some practical lower limit on the MTU setting, down around 1200 somewhere, but I’m not sure what that is or what it stems from.)  My experience has been that the maximum MTU value looking toward the WG host can vary from host-network to host-network and even from time to time (e.g., one organization made some network changes related to COVID that incidentally reduced the critical MTU and knocked me off the air.)

Is there some sort of a ‘fragtest’ network utility out there?

An inelegant approach might be to have each client iterate downward over a range of MTU values and test the connection to the server each time.  But I hope a deeper understanding may reveal a more efficient approach for deployment.

Regards,

Art

> On Aug 30, 2021, at 11:43, M. Dietrich <mdt@emdete.de> wrote:
> 
> Hi friends of Wireguard,
> 
> i am neither a network guru nor a kernel hacker and after all 
> i had no time to fully investigate the case. so please read 
> with a grain of salt.
> 
> i had my notebook in a wifi network lately that seemed to have 
> some MTU size problems. download worked fine while uploads 
> blocked for bigger packages. when i set the MTU down to 1200 
> on the wg interface the same upload worked fine.
> 
> this was obviously a problem of that very wifi network and is
> not related to wg at all, the dhcp answer did not even contain 
> any MTU hints, so 1500 was assumed.
> 
> anyway the kernel locked up. commands like `ip` or `wg-quick 
> down ...` get stuck and ^C oder even a `kill -9 ...` did not 
> end the processes. any access to the wg interface blocked.
> 
> my question is if that scenario (misconfigured MTU size in the 
> "outer network") is tested and works fine. i know that MTU 
> size problem lead to lockups (that's why i immediatly came to 
> that conclusion) but never saw such a hard lockup related to 
> commands like `ip`.
> 
> if my assumption is just stupid let me know. if not i would 
> further investigate the case, setup a test scenario and burn 
> some time. what do you think?
> 
> best regards, michael


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

* Re: Behaviour on MTU problem
  2021-08-30 19:55 ` Art Botterell
@ 2021-10-04  5:30   ` M. Dietrich
  0 siblings, 0 replies; 3+ messages in thread
From: M. Dietrich @ 2021-10-04  5:30 UTC (permalink / raw)
  To: Art Botterell, wireguard

Quotation from Art Botterell at August 30, 2021 21:55:
> One reads about fragmentation-induced failures and about 
> various MTU values that did or didn't work in a particular 
> situation.  [...]  what we could look out for in order 
> automatically to detect MTU issues [...] Is there some sort 
> of a ‘fragtest’ network utility out there?

My request was neither about anekdotic problems with different 
MTU sizes nor any automatic detection of a correct size and 
test utilities.

i was asking why the kernel module is completly locking up if 
a MTU size problem is present.

best regards, Michael

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

end of thread, other threads:[~2021-10-04  5:33 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-08-30 18:43 Behaviour on MTU problem M. Dietrich
2021-08-30 19:55 ` Art Botterell
2021-10-04  5:30   ` M. Dietrich

Development discussion of WireGuard

This inbox may be cloned and mirrored by anyone:

	git clone --mirror https://inbox.vuxu.org/wireguard/0 wireguard/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 wireguard wireguard/ https://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