From owner-freebsd-net@freebsd.org Tue May 22 15:29:08 2018 Return-Path: Delivered-To: freebsd-net@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 E2A1DEF9C3E for ; Tue, 22 May 2018 15:29:07 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 77BFF7AFC5 for ; Tue, 22 May 2018 15:29:07 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id 3BAF1EF9C3B; Tue, 22 May 2018 15:29:07 +0000 (UTC) Delivered-To: net@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 2915AEF9C3A for ; Tue, 22 May 2018 15:29:07 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.ysv.freebsd.org (mxrelay.ysv.freebsd.org [IPv6:2001:1900:2254:206a::19:3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mxrelay.ysv.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B9A377AFBE for ; Tue, 22 May 2018 15:29:06 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.ysv.freebsd.org (Postfix) with ESMTPS id 022AD12369 for ; Tue, 22 May 2018 15:29:06 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id w4MFT5Zd071947 for ; Tue, 22 May 2018 15:29:05 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id w4MFT5GO071946 for net@FreeBSD.org; Tue, 22 May 2018 15:29:05 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: net@FreeBSD.org Subject: [Bug 206721] FreeBSDs DHCP client(dhclient) does not support the interface-mtu option(option 26). Date: Tue, 22 May 2018 15:29:05 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: bin X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: feature X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: jimp@pfsense.org X-Bugzilla-Status: In Progress X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: cem@freebsd.org X-Bugzilla-Flags: mfc-stable10? mfc-stable11+ X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 May 2018 15:29:08 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D206721 --- Comment #21 from jimp@pfsense.org --- (In reply to Roman Bogorodskiy from comment #20) I see it less as "a workaround for misconfigured DHCP servers" and more as preserving current expected behavior. I didn't even know my ISP DHCP server= was sending broken information until this change was active by default. I'm not sure how many others are in the same boat, but having them find out after t= he fact during an upgrade seems troublesome. Ultimately, this is a new feature and not a bug fix. This new feature could potentially break current installations in unexpected ways (it certainly astonished me to find it broken). Preserving the existing and expected beha= vior is safe. If someone needs the new feature, IMO, they should have to make the change to activate it. It's a bit awkward that it has to be superseded to disable the change instead of going out of your way to enable it, but we're limited by what the dhclient configuration supports. If it were entirely up to me, I would leave it out of the default request l= ist and supersede it to 0, and if someone wants to use the DHCP MTU they can ad= d it to the request list and remove the supersede value. Since it is not up to m= e, having an entry in the release notes would be OK as an alternative as long = as it's prominent. It may even warrant a HEADS UP to lists to call attention t= o it for wider testing before 11.2-RELEASE. --=20 You are receiving this mail because: You are on the CC list for the bug.=