dhcpcd-discuss

On Mon, 2018-11-05 at 15:43 +0000, Roy Marples wrote:
> CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.
> 
> 
> Hi Joakim
> 
> On 05/11/2018 13:28, Joakim Tjernlund wrote:
> > Using both option 61 and 60 in dhcpd with same input data(
> > dhcpcd -i 21296%184KM000334 -I 21296%184KM000334 ....) I get
> > different lengths, tcpdump reports:
> > 
> > Client-ID Option 61, length 18: "21296%184KM000334"
> > Vendor-Class Option 60, length 17: "21296%184KM000334"
> > 
> > Client ID is off by one.
> > 
> > Is this intentional?
> > In any case this makes subclass matching is ISC dhcp server difficult.
> 
> Yes this is intentional.
> The first byte of the ClientID data denotes how it is formed. 0
> represents a string.
> See RFC 2132 9.14

OK, do you know if ISC dhcp client does this too?

I managed to match this is ISC dhcp server by:
class "vendor-classes" {                                                        
        match option dhcp-client-identifier;                                     
    }
subclass "vendor-classes" "\00021296%184KM000813" {
...

Notice the extra NUL in front. This looks ugly and I have seen
others which skips this extra NUL which makes me believe that ISC clients does
not do this.
Is there a better match statement I can you which allows med to skip
the extra NUL and works with ISC clients too?

 Jocke