dhcpcd-discuss

On 05/11/2018 16:50, Joakim Tjernlund wrote:
> 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?

No it doesn't.

> 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?

No sadly.

You can make ISC dhclient RFC conformant by setting this in the 
interface stanza in dhclient.conf:

send dhcp-client-identifier "\00021296%184KM000813"

But no, normally ISC dhclient takes the positition that you know exactly 
how RFC compliant fields should be formatted.
dhcpcd takes the position that the user doesn't know this and ensures 
it's always RFC compliant.

Roy