From owner-freebsd-current@freebsd.org Thu May 19 08:38:04 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7436BB40C06 for ; Thu, 19 May 2016 08:38:04 +0000 (UTC) (envelope-from truckman@FreeBSD.org) Received: from gw.catspoiler.org (unknown [IPv6:2602:304:b010:ef20::f2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "gw.catspoiler.org", Issuer "gw.catspoiler.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 569D01DAA for ; Thu, 19 May 2016 08:38:04 +0000 (UTC) (envelope-from truckman@FreeBSD.org) Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.15.2/8.15.2) with ESMTP id u4J8bsH2082306; Thu, 19 May 2016 01:37:59 -0700 (PDT) (envelope-from truckman@FreeBSD.org) Message-Id: <201605190837.u4J8bsH2082306@gw.catspoiler.org> Date: Thu, 19 May 2016 01:37:54 -0700 (PDT) From: Don Lewis Subject: Re: r299512 breaks dhclient on some networks To: ian.freislich@capeaugusta.com cc: freebsd-current@freebsd.org In-Reply-To: MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 May 2016 08:38:04 -0000 On 18 May, Ian FREISLICH wrote: > On 05/18/16 20:19, Don Lewis wrote >> It looks to me like r299512 is changing the format of the client >> identifier by inserting the struct hardware hlen field into it. That's >> not valid if htype is non-zero the way I interpret RFC 2132. On the >> other hand, I would think that the server would interpret the client ID >> as an opaque cookie, so I wouldn't think it would make a difference >> (other than thinking this is a new client) unless your server is >> configured to look for specific client IDs. > > It's not that the server isn't working. The client is discarding the > server's offer for whatever reason. There may be some other place in the code that validates the response and that calculates the client ID the old way. When it sees the response with the new client ID, it doesn't match and the client discards the response because it thinks the response is for some other host.