To: dhcp-confidential@isc.org
In-Reply-To: <rt-4.4.1-48176-1498646859-1165.45451-5-0@isc.org>
From: "Rob Riepel" <riepel@stanford.edu>
Message-ID: <BDA7D630-B30C-406C-B3E0-60079246814D@stanford.edu>
Date: Wed, 28 Jun 2017 15:11:30 -0700
MIME-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
content-type: text/plain; charset="utf-8"
References: <RT-Ticket-45451@isc.org> <B557ACFC-D426-466A-8FC5-FA4D42612A5C@stanford.edu> <rt-4.4.1-47758-1498585304-111.45451-5-0@isc.org> <E0D8B1C5-55F2-4978-89BE-0730EA1A8E5E@stanford.edu> <rt-4.4.1-49360-1498606844-1766.45451-5-0@isc.org> <rt-4.4.1-48176-1498646859-1165.45451-5-0@isc.org>
From riepel@stanford.edu  Wed Jun 28 22:11:40 2017
Content-Transfer-Encoding: quoted-printable
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2017-06-28_13:,, signatures=0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2017-06-28_13:,, signatures=0
Return-Path: <riepel@stanford.edu>
Subject: Re: [ISC-Bugs #45451] [confidential] DHCPv6 client class matching bug in DHCP server 4.3.5
X-RT-Original-Encoding: utf-8
Delivered-To: dhcp-confidential@bugs.isc.org
RT-Message-ID: <rt-4.4.1-64417-1498687903-809.45451-0-0@isc.org>
Content-Length: 1906

Thank you.

FWIW, our config is virtually the same for our DHCPv4 service (except we use "match hardware," as mentioned in my original message), and class matching works as expected. (I tested it after encountering the v6 problems to make sure I understood what I was doing.)

> On Jun 28, 2017, at 3:47 AM, Thomas Markwalder via RT <dhcp-confidential@isc.org> wrote:
> 
> Hello Rob:
> 
> We have pulled the files down, thank you.  The full config file is quite large which may have something to do with it.   My testing here was done based on the snippet you included before.
> 
> I will keep you updated with our findings but it may be a bit before we can spend much time on it.
> 
> Regards,
> 
> Thomas Markwalder
> ISC Software Engineering
> 
> On Tue Jun 27 23:40:44 2017, riepel@stanford.edu wrote:
>> On Jun 27, 2017, at 10:41 AM, Thomas Markwalder via RT <dhcp-
>> confidential@isc.org> wrote:
>> 
>> 
>>> This is an intriguing problem.  Thus far, using your configuration we
>>> have not been able to produce a mismatch. We are winding up work on
>>> our next releases, 4.3.6/4.1-ESV-R15, which are due out 7/31/17, so
>>> our resources are somewhat limited.
>>> 
>>> Could you supply us with pcaps of the traffic that causes the
>>> mismatch?
>> 
>> As you can see from the files, I restart the server, started tcpdump
>> (dst port 547 or dst port 546), and then told the "vile" client (same
>> one as before) to configure IPv6 automatically. It matched "roaming"
>> right off. The subsequent client, ac:bc:32:d3:2a:f1, which is a valid
>> "roaming" client didn't explicitly match "roaming," but it didn't get
>> an address either. About 15 seconds later it matched "roaming" and got
>> an address.
>> 
>> I've put the full config, log, and pcap files up at
>> http://web.stanford.edu/~riepel/dhcpv6/
>> 
>> Let me know when you've got them so I remove them.  Thanks.
>> 
>> --
>> Rob Riepel