Hello,
I have a host which is on PPPoE and has 1492 as underlying MTU.
When WireGuard starts by default, it sets MTU of its interface to 1420. All
TCP connections trying to send a stream of data over the WG interface to that
host, hang up (I test with iperf3).
My first idea was to override the M
Hi Roman,
When WireGuard starts by default, it sets MTU of its interface to 1420. All
TCP connections trying to send a stream of data over the WG interface to that
host, hang up (I test with iperf3).
If you only care about TCP connections you could set a different TCP-MSS
with an iptables rul
On Fri, Mar 16, 2018 at 10:25 AM, Roman Mamedov wrote:
> Hello,
>
> I have a host which is on PPPoE and has 1492 as underlying MTU.
>
> When WireGuard starts by default, it sets MTU of its interface to 1420. All
> TCP connections trying to send a stream of data over the WG interface to that
> host
On Fri, 16 Mar 2018 10:35:18 +0100
Matthias Ordner wrote:
> If you only care about TCP connections you could set a different TCP-MSS
> with an iptables rule.
On Fri, 16 Mar 2018 11:01:51 +0100
Kalin KOZHUHAROV wrote:
> You may need to pre-shape the packets for the "offenders", e.g.
>
> ip6ta
On Fri, 16 Mar 2018 15:53:43 +0500
Roman Mamedov wrote:
> But guess what, turns out that didn't work either. Tried both OUTPUT and
> POSTROUTING chains on the "mangle" table, and set-mss all the way down to
> 1220, no matter what, the iperf3 output looked the same as before.
Actually the iptable
On Fri, 16 Mar 2018 14:25:47 +0500
Roman Mamedov wrote:
> What helps, is only reducing MTU of the entire wg0 interface to 1412.
> Then everything works fine. But it doesn't feel optimal to reduce MTU
> of the entire network just because of 1 or 2 hosts. I would rather
> use a couple of those mtu-
Hi Roman,
I think that your idea of setting a route-based MTU _should_ work, and
it seems like a bug if it isn't working. There are two places in
WireGuard which directly touch the MTU:
1) When we split GSO superpackets up into normal sized packets. This
code is supposed to be aware of the per-ro
On Sat, Apr 14, 2018 at 03:38:46AM +0200, Jason A. Donenfeld wrote:
> 2) When we pad the packet payload. In this case, we pad it to the
> nearest multiple of 16, but we don't let it exceed the device MTU.
> This is skb_padding in send.c. This behavior seems like the bug in
> your particular case, s
Hi Roman,
This commit should fix it. It now has a unit test too so that we don't
hit this issue again. Thanks for reporting it in such detail.
https://git.zx2c4.com/WireGuard/commit/?id=a88a067d5477f877003d3703bb3b95cb4e94bc46
Let me know if that fixes it on your end.
Jason
On Sat, 14 Apr 2018 15:16:56 +0200
"Jason A. Donenfeld" wrote:
> Hi Roman,
>
> This commit should fix it. It now has a unit test too so that we don't
> hit this issue again. Thanks for reporting it in such detail.
>
> https://git.zx2c4.com/WireGuard/commit/?id=a88a067d5477f877003d3703bb3b95cb4e
Hi Roman,
I answered this in my first email to you, which perhaps got lost in
the mix of emails, so I'll quote the relevant part:
> 2) When we pad the packet payload. In this case, we pad it to the
> nearest multiple of 16, but we don't let it exceed the device MTU.
> This is skb_padding in send.
On Sat, 14 Apr 2018 16:15:07 +0200
"Jason A. Donenfeld" wrote:
> Hi Roman,
>
> I answered this in my first email to you, which perhaps got lost in
> the mix of emails, so I'll quote the relevant part:
>
> > 2) When we pad the packet payload. In this case, we pad it to the
> > nearest multiple o
Hi Roman,
That's strange; I'm unable to reproduce what you've described:
[+] NS1: ip link set wg0 mtu 1412
[+] NS2: ip link set wg0 mtu 1412
[+] NS1: wg set wg0 peer QXloTaPOwUTzqFElVLSD0vBc4sxjyoKtPBSaTkZHokY=
endpoint 127.0.0.1:2
[+] NS2: wg set wg0 peer X0p7+UWc4wjaAmT73xAEuXLY80I6Gv8vTg6KwFHC
On Sat, 14 Apr 2018 16:45:32 +0200
"Jason A. Donenfeld" wrote:
> In this case, WireGuard seems to be doing the right thing. Think you
> could come up with some minimal test that exhibits the behavior you're
> seeing?
I now remember in more detail what was the problem. It was not with MTU 1412
on
Hey Roman,
I've just tried a few ways of replicating your setup, and I can't seem
to reproduce the bug, either with the new code or old. The results you
mention are surprising too, since WireGuard or not, TCP is supposed to
negotiate the lowest common MSS. I wonder if some strange iptables
rules a
15 matches
Mail list logo
