netdev - Re: UDP path MTU discovery

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

Message-Id: <20100325.202424.201654947.davem@davemloft.net>
Date:	Thu, 25 Mar 2010 20:24:24 -0700 (PDT)
From:	David Miller <davem@...emloft.net>
To:	gdt@....id.au
Cc:	netdev@...r.kernel.org
Subject: Re: UDP path MTU discovery

From: Glen Turner <gdt@....id.au>
Date: Fri, 26 Mar 2010 10:32:31 +1030

> This differs from TCP, where it is the kernel -- and not
> the application -- which organises retransmission. On
> receiving a ICMP Fragmentation Needed the kernel can
> immediately re-probe the path MTU wiht no waiting for
> an exponential timer to expire.

So the argument is, the kernel TCP does retransmission smart,
userspace UDP apps do it stupidly, so let's turn off the feature
instead of fixing userspace.

Right?

Sorry, fix this correctly in the user apps.  Putting the
blame on UDP path MTU discovery is placing it in the
wrong spot.

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html