linux-kernel - PMTU discovery mechanism on closed UDP socket, no entry added

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>] [day] [month] [year] [list]

Message-ID: <CAEVoMY0_sjOuC9Pa1L=_ShsH2iywksnOzSsOrcY7GajZHOVGrw@mail.gmail.com>
Date:   Tue, 13 Mar 2018 16:07:26 +0100
From:   Oskar Jagodziński <oskar.jagodzinski@...egro.pl>
To:     linux-kernel@...r.kernel.org
Subject: PMTU discovery mechanism on closed UDP socket, no entry added

Hi,

When I send UDP packet (too big for whole path) and close socket right
after, ICMP Fragmentation Needed packet is ignored (?) and no entry
regarding path MTU is created. When process waits before closing
socket (about 1s in my case) entry about path MTU is added to routing
table.
The result is that when I send single big (bigger than minimal MTU in
path) UDP packet very rarely none of them reaches destination. When
there is continuous stream of packets and there is always open socket
for this destination IP everything (regarding path MTU discovery
mechanism) works as expected.

Is there any way to change this behaviour? Or is this some kind of
DDoS protection mechanism? I am aware of timeout of table MTU entries
but "very rarely" in my case means more often than timeout value.

Environment:
- Ubuntu 14.04.5 LTS, kernel 4.4.0-104-generic #127~14.04.1-Ubuntu
- Intel(R) 2P X520/2P I350 rNDC | Intel Corporation 82599ES
10-Gigabit, driver=ixgbe driverversion=4.2.1-k, 18.3.6 (firmware
driver from Dell)

Code used for testing and my network architecture:
- https://pastebin.com/raw/ECY3Xxtg
- https://i.imgur.com/T7SpDyP.png

-- 
Oskar Jagodzinski