linux-kernel - Re: xfrm: is pmtu broken with ESP tunneling?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Thu, 13 Feb 2014 20:53:21 +0100
From:	Ortwin Glück <odi@....ch>
To:	linux-kernel@...r.kernel.org, netdev@...r.kernel.org
Subject: Re: xfrm: is pmtu broken with ESP tunneling?

On 02/13/2014 01:01 AM, Hannes Frederic Sowa wrote:
> Could you try either dropwatch or perf script net_dropmonitor and flood the
> network with the problematic packets. From the traces we could see where the
> packets get dropped without notification in the kernel.

Not much to see, unfortunately. The COUNT doesn't reflect the number packets 
that I am missing.

                  LOCATION                    OFFSET                     COUNT 

      ieee80211_iface_work                       208                         1

> Strange that the problem disappears if you enable no_pmtu_disc then.

It seems with PMTU the initial mtu is the one of the device (1500). So the 
original packet will have that size, but is subsequently wrapped into ESP and 
UDP, which add to that size. And the final packet is then larger than the device 
MTU... I know nothing about the ip / xfrm kernel code, so it's hard for me to 
verify if that theory is real.

Thanks,

Ortwin
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/