On Mon, Aug 13, 2018 at 4:41 PM Jason A. Donenfeld wrote:
>
> WireGuard's socket.c calls udp_tunnel_xmit with the DF bit set to 0,
> which means if the underlying endpoint's path has an MTU that is too
> small, the UDP packet will simply be fragmented, not dropped.
Hi Jason,
Thank you for your a
WireGuard's socket.c calls udp_tunnel_xmit with the DF bit set to 0,
which means if the underlying endpoint's path has an MTU that is too
small, the UDP packet will simply be fragmented, not dropped.
___
WireGuard mailing list
WireGuard@lists.zx2c4.com
ht
On Mon, Aug 13, 2018 at 5:06 AM Roman Mamedov wrote:
>
> On Mon, 13 Aug 2018 02:53:44 +1000
> StarBrilliant wrote:
>
> > I know Wireguard can already do IP layer fragmentation. (Just set
> > tunnel MTU >= 1441 then fragmentation will be turned on)
>
> Is that really expected to work? I tried sett
On Mon, 13 Aug 2018 02:53:44 +1000
StarBrilliant wrote:
> I know Wireguard can already do IP layer fragmentation. (Just set
> tunnel MTU >= 1441 then fragmentation will be turned on)
Is that really expected to work? I tried setting MTU 9000 on both ends of a WG
tunnel, but large packets still do
Hello Wireguard developers and uesrs,
Thank you for having built up this software!
Recently I found some problems transmitting large UDP packets at
certain network environments.
My network architecture consists of 2 layers (Wireguard + VXLAN) to
enable mesh routing based on BGP and Babel routing
Hey Andrejs,
Thanks a lot for this patch and for the nice write-up. I'm still not
sure, though, that I totally understand the checksumming semantics
properly. I see that this basic pattern is used in tap.c and in a few
other random drivers, but different places seem to do it differently
from that
