From owner-freebsd-stable@freebsd.org Fri May 18 16:03:18 2018 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0EE14EACEC6 for ; Fri, 18 May 2018 16:03:18 +0000 (UTC) (envelope-from lists@pingle.org) Received: from luna.pingle.org (luna.pingle.org [68.76.213.30]) by mx1.freebsd.org (Postfix) with ESMTP id B0F017C9C3 for ; Fri, 18 May 2018 16:03:17 +0000 (UTC) (envelope-from lists@pingle.org) Received: from luna.pingle.org (unknown [127.0.0.1]) by luna.pingle.org (Postfix) with ESMTP id 33F7CDDA8E6 for ; Fri, 18 May 2018 11:54:15 -0400 (EDT) X-Virus-Scanned: amavisd-new at pingle.org Received: from luna.pingle.org ([127.0.0.1]) by luna.pingle.org (luna.pingle.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sUK6ABWtYYfe for ; Fri, 18 May 2018 11:54:14 -0400 (EDT) Received: from [172.21.32.34] (hpcw.hpcisp.com [68.76.213.13]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: jim) by luna.pingle.org (Postfix) with ESMTPSA id 3601DDDA8CD for ; Fri, 18 May 2018 11:54:14 -0400 (EDT) To: FreeBSD From: Jim Pingle Subject: 11.2 dhclient MTU behavior is broken Message-ID: Date: Fri, 18 May 2018 11:54:13 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 May 2018 16:03:18 -0000 The DHCP client, dhclient, in 11.2 was changed to support server-side MTU ( https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=206721 ), but this MTU feature being enabled by default causes an unexpected change in behavior on upgrade, which to me is a POLA violation. My ISP sends a bogus MTU of 576, and I've seen reports of others that do the same. Previously this was ignored since the client didn't support processing the MTU, but now it's respected and breaks connectivity since the MTU should really be 1500. There doesn't appear to be any way to override the client behavior either. Using a request line that doesn't include interface-mtu doesn't help since if the server always sends it, it is still read and respected. Any supersede value in dhclient.conf appears to be ignored in favor of the server-supplied value. The link bounces when the MTU is set as well, at least on e1000. I see dhclient was changed to help cope with that but it also affects other things that key off link up/down events and can lead to a loop depending on what those scripts do. Can this feature be changed so that it's optional and disabled by default? Either a command-line option or a dhclient.conf directive would work. As-is, it's making the stock dhclient unusable here without patching out that feature. I can see people wanting to use that, but it shouldn't be on for everyone out of the box. Jim P.