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 <[email protected]> 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
