MIME-Version: 1.0 In-Reply-To: X-Mailer: MIME-tools 5.505 (Entity 5.505) Content-Disposition: inline X-RT-Interface: Web References: Content-Type: text/plain; charset="utf-8" Message-ID: Content-Transfer-Encoding: binary X-RT-Original-Encoding: utf-8 RT-Send-CC: X-RT-Encrypt: 0 X-RT-Sign: 0 Content-Length: 2976 Hello Darren: Thank you for reporting this issue. We have looked into enough to reproduce it and agree that at the very least, the server is not providing the documented behavior. The correction should be part of our 4.4.0 release, due out sometime this year, the date is TBD. At a point in time that we have a patch we can make it available to you. Thank you for your interest our software and for taking the time to report the issue to us. Sincerely, Thomas Markwalder ISC Software Engineering On Tue Jan 03 14:25:39 2017, dankney@network1.net wrote: > Bug Report from www.isc.org: > > Name: Darren Ankney > Email: dankney@network1.net > Software Version: Internet Systems Consortium DHCP Server 4.3.3 > OS: generic Linux 3.19.0 > Subject:on commit {} in DHCPv6 has client option content instead of > server option content > > > Bug Detail > =========== > Original thread on DHCP users here: > https://lists.isc.org/pipermail/dhcp-users/2016-December/020485.html > > having something like this in the dhcpd.conf file for DHCPv6: > > on commit { > if exists dhcp6.ia-na { > log(debug, > concat( "LEASED,", > "IPTIME,",binary-to-ascii(10, 32, "", > substring(option dhcp6.ia-na,36,4)),"," > ) > ); > } > } > > Will produce a value for IPTIME that is equal to the time requested by > the client instead of what was given by the server. > > For example: > > Client (Redhat Enterprise Linux 7 - ISC DHCP 4.2.5) sends a Renew for > an IPv6 address via DHCPv6 requesting the following times (As seen in > wireshark capture): > > T1: 3600 > T2: 5400 > Preferred Lifetime: 7200 > Valid Lifetime: 7500 > > Server (generic Linux - ISC DHCP 4.3.3) is configured with this time > setting in the pool6 {} statement: > > default-lease-time 600; > > Server responds with times like this (as seen in wireshark capture): > > T1: 0 > T2: 0 > Preferred Lifetime: 375 > Valid Lifetime: 600 > > What is logged in the log file is 7500 not 600. > > The client lease file shows the following times: > > Renew: 0 > Rebind: 0 > Preferred Lifetime: 375 > Valid Lifetime: 600 > > So, it seems that the dhcp options available in on commit {} are what > the client sent in instead of those the server sent in response? Is > that a bug? Or do I not understand how on commit {} works? I assumed > that on commit {} would have access to the options as set by the > server that were sent back to the client. > > It seems like a bug to me as the man page for DHCP options (man dhcp- > options(5)) states that the option is produced by the server: > > option dhcp6.ia-na string; > > The Identity Association for Non-temporary Addresses (ia-na) carries > assigned addresses that are not temporary addresses for use by the > DHCPv6 client. This option is produced by the DHCPv6 server software, > and should not be configured. > > --- > This email was received through isc.org Bug Submission Form