Re: r299512 breaks dhclient on some networks

2016-05-19 Thread Don Lewis 
On 18 May, Conrad Meyer wrote:
> On Wed, May 18, 2016 at 5:19 PM, 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.
> 
> Yes.  The problem with r299512 is that it assumed the client_id was
> actually a valid struct hardware, as the array's size suggested, when
> in fact it has nothing to do with that struct.
> 
>>  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.
> 
> That seems like a pretty reasonable use of the client identifier.  Or
> less reasonably but still expected, only allowing client identifiers
> of exactly 6 bytes.

See section 9.14 in RFC 2132.  It's not a hard requirement because the
RFC uses MAY and SHOULD, but if the first byte of the ID is 1, then the
remainder of the ID should be a 6 byte ethernet MAC address.  If the
first byte is 0, then the ID is free form.

>> I think that r299512 is mostly incorrect and should be reverted.  The
>> problem reported by CID 1008682 is an overrun of hw_address.haddr.
>> struct hardware looks like this:
>>
>> struct hardware {
>> u_int8_t htype;
>> u_int8_t hlen;
>> u_int8_t haddr[16];
>> };
>>
>> I think the correct fix is just this:
>>
>> size_t hwlen = MIN(ip->hw_address.hlen,
>> sizeof(ip->hw_address.haddr));
>>
>> The old code was wrong because sizeof(client_ident)-1 is the
>> same as sizeof(struct hardware)-1, when it should be -2 to exclude both
>> htype and hlen from the calculation.
> 
> Yep.  Or equivalently, I've defined the length of client_ident in
> terms of sizeof(haddr) + 1.  The result is the same.
> 
>> The fix for CID 1305550 looks correct.
> 
> Maybe; though I reverted it too.  Really I think hlen > sizeof(haddr)
> is invalid, but I'm not familiar enough with dhclient.c to insert that
> check in the right place.  I think throwing in MIN() in an ad-hoc
> fashion maybe isn't the best approach.

If the MIN() is omitted, then Coverity might be able to figure out that
hlen is never greater than sizeof(haddr) and the code is clean.  Just
adding the MIN() might make Coverity think that hlen is not well known
and that it needs to evaluate the code with hlen values that either pass
or fail the comparison.

hlen appears to be set by the code in the AF_LINK section of
discover_interfaces().  Note that Coverity isn't flagging the memcpy()
there, even though it has know way of knowing the relationship between
the length passed to memcpy() there and sizeof(hlen).  Even with a
sanity check there, I think that is too far removed from the code in
make_discover() for it to draw any conclusions about whether hlen still
meets the constraint.

I think the best thing to do is to remove both instances of MIN() and
optionally add an assert() before
if (!options[DHO_DHCP_CLIENT_IDENTIFIER]) {
where it will protect both memcpy() calls.

BTW, the location of
char client_ident[sizeof(struct hardware)];
violates style(9).

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: r299512 breaks dhclient on some networks

2016-05-19 Thread Don Lewis 
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.

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: r299512 breaks dhclient on some networks

2016-05-18 Thread Conrad Meyer 
On Wed, May 18, 2016 at 5:19 PM, 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.

Yes.  The problem with r299512 is that it assumed the client_id was
actually a valid struct hardware, as the array's size suggested, when
in fact it has nothing to do with that struct.

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

That seems like a pretty reasonable use of the client identifier.  Or
less reasonably but still expected, only allowing client identifiers
of exactly 6 bytes.

> I think that r299512 is mostly incorrect and should be reverted.  The
> problem reported by CID 1008682 is an overrun of hw_address.haddr.
> struct hardware looks like this:
>
> struct hardware {
> u_int8_t htype;
> u_int8_t hlen;
> u_int8_t haddr[16];
> };
>
> I think the correct fix is just this:
>
> size_t hwlen = MIN(ip->hw_address.hlen,
> sizeof(ip->hw_address.haddr));
>
> The old code was wrong because sizeof(client_ident)-1 is the
> same as sizeof(struct hardware)-1, when it should be -2 to exclude both
> htype and hlen from the calculation.

Yep.  Or equivalently, I've defined the length of client_ident in
terms of sizeof(haddr) + 1.  The result is the same.

> The fix for CID 1305550 looks correct.

Maybe; though I reverted it too.  Really I think hlen > sizeof(haddr)
is invalid, but I'm not familiar enough with dhclient.c to insert that
check in the right place.  I think throwing in MIN() in an ad-hoc
fashion maybe isn't the best approach.

Best,
Conrad
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: r299512 breaks dhclient on some networks

2016-05-18 Thread Ian FREISLICH 
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.

But, r300174 has it working again for me.  I can't speak to the
correctness of the fix though.

Ian

-- 

Ian Freislich


-- 
 

Cape Augusta Digital Properties, LLC a Cape Augusta Company

*Breach of confidentiality & accidental breach of confidentiality *

This email and any files transmitted with it are confidential and intended 
solely for the use of the individual or entity to whom they are addressed. 
If you have received this email in error please notify the system manager. 
This message contains confidential information and is intended only for the 
individual named. If you are not the named addressee you should not 
disseminate, distribute or copy this e-mail. Please notify the sender 
immediately by e-mail if you have received this e-mail by mistake and 
delete this e-mail from your system. If you are not the intended recipient 
you are notified that disclosing, copying, distributing or taking any 
action in reliance on the contents of this information is strictly 
prohibited.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: r299512 breaks dhclient on some networks

2016-05-18 Thread Ian FREISLICH 
On 05/18/16 19:49, Conrad Meyer wrote:
> Hey Ian,
>
> r299512 incorrectly encoded client identifiers because I misunderstood
> the intent of the sizeof()-scaled client_id.  I reverted that change
> and replaced it with r300174, which I believe fixes the first overrun
> more correctly.
Just checked and DHCP is working again.

> (Coverity may still complain about CID 1305550, but I don't believe
> it's valid for 'hlen' to exceed sizeof(hw_addr.haddr).)
>
> Thanks,
> Conrad
>
> On Wed, May 18, 2016 at 3:49 PM, Ian FREISLICH
>  wrote:
>> Hi
>>
>> I cannot for the life of me figure out why the change in r299512 breaks
>> DHCP on one network I use but not on another network.
>>
>> The only clue I can find is that the request whose response is ignored
>> has the following client ID:
>> 1:6:0:22:5f:70:a1:df
>>
>> The request whose response is use has this client ID:
>> 1:0:22:5f:70:a1:df
>>
>> Here's a dhcpdump of the request/offer that gets ignored.
>>
>> ---
>>
>>   TIME: 2016-05-18 18:46:39.134
>> IP: 0.0.0.0 (00:22:5f:70:a1:df) > 255.255.255.255 (ff:ff:ff:ff:ff:ff)
>> OP: 1 (BOOTPREQUEST)
>>  HTYPE: 1 (Ethernet)
>>   HLEN: 6
>>   HOPS: 0
>>XID: 92a34fc3
>>   SECS: 0
>>  FLAGS: 0
>> CIADDR: 0.0.0.0
>> YIADDR: 0.0.0.0
>> SIADDR: 0.0.0.0
>> GIADDR: 0.0.0.0
>> CHADDR: 00:22:5f:70:a1:df:00:00:00:00:00:00:00:00:00:00
>>  SNAME: .
>>  FNAME: .
>> OPTION:  53 (  1) DHCP message type 1 (DHCPDISCOVER)
>> OPTION:  61 (  8) Client-identifier 01:06:00:22:5f:70:a1:df
>> OPTION:  12 (  3) Host name zen
>> OPTION:  55 (  9) Parameter Request List  1 (Subnet mask)
>>  28 (Broadcast address)
>>   2 (Time offset)
>> 121 (Classless Static Route)
>>   3 (Routers)
>>  15 (Domainname)
>>   6 (DNS server)
>>  12 (Host name)
>> 119 (Domain Search)
>>
>> ---
>>
>>   TIME: 2016-05-18 18:46:39.134
>> IP: 10.0.0.1 (4c:5e:0c:62:4f:82) > 10.0.0.80 (00:22:5f:70:a1:df)
>> OP: 2 (BOOTPREPLY)
>>  HTYPE: 1 (Ethernet)
>>   HLEN: 6
>>   HOPS: 0
>>XID: 92a34fc3
>>   SECS: 0
>>  FLAGS: 0
>> CIADDR: 0.0.0.0
>> YIADDR: 10.0.0.80
>> SIADDR: 10.0.0.1
>> GIADDR: 0.0.0.0
>> CHADDR: 00:22:5f:70:a1:df:00:00:00:00:00:00:00:00:00:00
>>  SNAME: .
>>  FNAME: .
>> OPTION:  53 (  1) DHCP message type 2 (DHCPOFFER)
>> OPTION:  54 (  4) Server identifier 10.0.0.1
>> OPTION:  51 (  4) IP address leasetime  259200 (3d)
>> OPTION:   1 (  4) Subnet mask   255.255.255.0
>> OPTION:   3 (  4) Routers   10.0.0.1
>> OPTION:   6 (  4) DNS server10.0.0.1
>> ---
>>
>>
>> And here's the request/offer that works (with the r299512 backed out)
>>
>> ---
>>
>>   TIME: 2016-05-18 18:35:33.817
>> IP: 10.0.0.220 (00:22:5f:70:a1:df) > 255.255.255.255 (ff:ff:ff:ff:ff:ff)
>> OP: 1 (BOOTPREQUEST)
>>  HTYPE: 1 (Ethernet)
>>   HLEN: 6
>>   HOPS: 0
>>XID: 866cfd85
>>   SECS: 4
>>  FLAGS: 0
>> CIADDR: 0.0.0.0
>> YIADDR: 0.0.0.0
>> SIADDR: 0.0.0.0
>> GIADDR: 0.0.0.0
>> CHADDR: 00:22:5f:70:a1:df:00:00:00:00:00:00:00:00:00:00
>>  SNAME: .
>>  FNAME: .
>> OPTION:  53 (  1) DHCP message type 3 (DHCPREQUEST)
>> OPTION:  50 (  4) Request IP address10.0.0.220
>> OPTION:  61 (  7) Client-identifier 01:00:22:5f:70:a1:df
>> OPTION:  12 (  3) Host name zen
>> OPTION:  55 (  9) Parameter Request List  1 (Subnet mask)
>>  28 (Broadcast address)
>>   2 (Time offset)
>> 121 (Classless Static Route)
>>   3 (Routers)
>>  15 (Domainname)
>>   6 (DNS server)
>>  12 (Host name)
>> 119 (Domain Search)
>>
>> ---
>>
>>   TIME: 2016-05-18 18:35:33.817
>> IP: 10.0.0.1 (4c:5e:0c:62:4f:82) > 10.0.0.220 (00:22:5f:70:a1:df)
>> OP: 2 (BOOTPREPLY)
>>  HTYPE: 1 (Ethernet)
>>   HLEN: 6
>>   HOPS: 0
>>XID: 866cfd85
>>   SECS: 0
>>  FLAGS: 0
>> CIADDR: 0.0.0.0
>> YIADDR: 10.0.0.220
>> SIADDR: 10.0.0.1
>> GIADDR: 0.0.0.0
>> CHADDR:

Re: r299512 breaks dhclient on some networks

2016-05-18 Thread Don Lewis 
On 18 May, To: c...@freebsd.org wrote:
> On 18 May, Conrad Meyer wrote:
>> Hey Ian,
>> 
>> r299512 incorrectly encoded client identifiers because I misunderstood
>> the intent of the sizeof()-scaled client_id.  I reverted that change
>> and replaced it with r300174, which I believe fixes the first overrun
>> more correctly.
>> 
>> (Coverity may still complain about CID 1305550, but I don't believe
>> it's valid for 'hlen' to exceed sizeof(hw_addr.haddr).)
> 
> It's not, but the MIN() doesn't hurt.  Coverity may no longer complain
> though because your change may think that hlen is only 16 at this point
> since that is what the earlier change tests against.
> 
> If it is checked in one place, it should probably be checked in both, or
> you could just add an assert() to check it ...

If you removed the tests in both places, Coverity would probably just
assume that everything is just fine and dandy ...

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: r299512 breaks dhclient on some networks

2016-05-18 Thread Don Lewis 
On 18 May, Conrad Meyer wrote:
> Hey Ian,
> 
> r299512 incorrectly encoded client identifiers because I misunderstood
> the intent of the sizeof()-scaled client_id.  I reverted that change
> and replaced it with r300174, which I believe fixes the first overrun
> more correctly.
> 
> (Coverity may still complain about CID 1305550, but I don't believe
> it's valid for 'hlen' to exceed sizeof(hw_addr.haddr).)

It's not, but the MIN() doesn't hurt.  Coverity may no longer complain
though because your change may think that hlen is only 16 at this point
since that is what the earlier change tests against.

If it is checked in one place, it should probably be checked in both, or
you could just add an assert() to check it ...

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: r299512 breaks dhclient on some networks

2016-05-18 Thread Don Lewis 
On 18 May, Ian FREISLICH wrote:
> Hi
> 
> I cannot for the life of me figure out why the change in r299512 breaks
> DHCP on one network I use but not on another network.
>  
> The only clue I can find is that the request whose response is ignored
> has the following client ID:
> 1:6:0:22:5f:70:a1:df
> 
> The request whose response is use has this client ID:
> 1:0:22:5f:70:a1:df
> 
> Here's a dhcpdump of the request/offer that gets ignored.
> 
> ---
> 
>   TIME: 2016-05-18 18:46:39.134
> IP: 0.0.0.0 (00:22:5f:70:a1:df) > 255.255.255.255 (ff:ff:ff:ff:ff:ff)
> OP: 1 (BOOTPREQUEST)
>  HTYPE: 1 (Ethernet)
>   HLEN: 6
>   HOPS: 0
>XID: 92a34fc3
>   SECS: 0
>  FLAGS: 0
> CIADDR: 0.0.0.0
> YIADDR: 0.0.0.0
> SIADDR: 0.0.0.0
> GIADDR: 0.0.0.0
> CHADDR: 00:22:5f:70:a1:df:00:00:00:00:00:00:00:00:00:00
>  SNAME: .
>  FNAME: .
> OPTION:  53 (  1) DHCP message type 1 (DHCPDISCOVER)
> OPTION:  61 (  8) Client-identifier 01:06:00:22:5f:70:a1:df
> OPTION:  12 (  3) Host name zen
> OPTION:  55 (  9) Parameter Request List  1 (Subnet mask)
>  28 (Broadcast address)
>   2 (Time offset)
> 121 (Classless Static Route)
>   3 (Routers)
>  15 (Domainname)
>   6 (DNS server)
>  12 (Host name)
> 119 (Domain Search)
>
> ---
> 
>   TIME: 2016-05-18 18:46:39.134
> IP: 10.0.0.1 (4c:5e:0c:62:4f:82) > 10.0.0.80 (00:22:5f:70:a1:df)
> OP: 2 (BOOTPREPLY)
>  HTYPE: 1 (Ethernet)
>   HLEN: 6
>   HOPS: 0
>XID: 92a34fc3
>   SECS: 0
>  FLAGS: 0
> CIADDR: 0.0.0.0
> YIADDR: 10.0.0.80
> SIADDR: 10.0.0.1
> GIADDR: 0.0.0.0
> CHADDR: 00:22:5f:70:a1:df:00:00:00:00:00:00:00:00:00:00
>  SNAME: .
>  FNAME: .
> OPTION:  53 (  1) DHCP message type 2 (DHCPOFFER)
> OPTION:  54 (  4) Server identifier 10.0.0.1
> OPTION:  51 (  4) IP address leasetime  259200 (3d)
> OPTION:   1 (  4) Subnet mask   255.255.255.0
> OPTION:   3 (  4) Routers   10.0.0.1
> OPTION:   6 (  4) DNS server10.0.0.1
> ---
> 
> 
> And here's the request/offer that works (with the r299512 backed out)
> 
> ---
> 
>   TIME: 2016-05-18 18:35:33.817
> IP: 10.0.0.220 (00:22:5f:70:a1:df) > 255.255.255.255 (ff:ff:ff:ff:ff:ff)
> OP: 1 (BOOTPREQUEST)
>  HTYPE: 1 (Ethernet)
>   HLEN: 6
>   HOPS: 0
>XID: 866cfd85
>   SECS: 4
>  FLAGS: 0
> CIADDR: 0.0.0.0
> YIADDR: 0.0.0.0
> SIADDR: 0.0.0.0
> GIADDR: 0.0.0.0
> CHADDR: 00:22:5f:70:a1:df:00:00:00:00:00:00:00:00:00:00
>  SNAME: .
>  FNAME: .
> OPTION:  53 (  1) DHCP message type 3 (DHCPREQUEST)
> OPTION:  50 (  4) Request IP address10.0.0.220
> OPTION:  61 (  7) Client-identifier 01:00:22:5f:70:a1:df
> OPTION:  12 (  3) Host name zen
> OPTION:  55 (  9) Parameter Request List  1 (Subnet mask)
>  28 (Broadcast address)
>   2 (Time offset)
> 121 (Classless Static Route)
>   3 (Routers)
>  15 (Domainname)
>   6 (DNS server)
>  12 (Host name)
> 119 (Domain Search)
>
> ---
> 
>   TIME: 2016-05-18 18:35:33.817
> IP: 10.0.0.1 (4c:5e:0c:62:4f:82) > 10.0.0.220 (00:22:5f:70:a1:df)
> OP: 2 (BOOTPREPLY)
>  HTYPE: 1 (Ethernet)
>   HLEN: 6
>   HOPS: 0
>XID: 866cfd85
>   SECS: 0
>  FLAGS: 0
> CIADDR: 0.0.0.0
> YIADDR: 10.0.0.220
> SIADDR: 10.0.0.1
> GIADDR: 0.0.0.0
> CHADDR: 00:22:5f:70:a1:df:00:00:00:00:00:00:00:00:00:00
>  SNAME: .
>  FNAME: .
> OPTION:  53 (  1) DHCP message type 5 (DHCPACK)
> OPTION:  54 (  4) Server identifier 10.0.0.1
> OPTION:  51 (  4) IP address leasetime  259200 (3d)
> OPTION:   1 (  4) Subnet mask   255.255.255.0
> OPTION:   3 (  4) Routers   10.0.0.1
> OPTION:   6 (  4) DNS server10.0.0.1
> ---

It looks to me like r299512 is changing the format of the client
identifier by inserting the struct

Re: r299512 breaks dhclient on some networks

2016-05-18 Thread Conrad Meyer 
Hey Ian,

r299512 incorrectly encoded client identifiers because I misunderstood
the intent of the sizeof()-scaled client_id.  I reverted that change
and replaced it with r300174, which I believe fixes the first overrun
more correctly.

(Coverity may still complain about CID 1305550, but I don't believe
it's valid for 'hlen' to exceed sizeof(hw_addr.haddr).)

Thanks,
Conrad

On Wed, May 18, 2016 at 3:49 PM, Ian FREISLICH
 wrote:
> Hi
>
> I cannot for the life of me figure out why the change in r299512 breaks
> DHCP on one network I use but not on another network.
>
> The only clue I can find is that the request whose response is ignored
> has the following client ID:
> 1:6:0:22:5f:70:a1:df
>
> The request whose response is use has this client ID:
> 1:0:22:5f:70:a1:df
>
> Here's a dhcpdump of the request/offer that gets ignored.
>
> ---
>
>   TIME: 2016-05-18 18:46:39.134
> IP: 0.0.0.0 (00:22:5f:70:a1:df) > 255.255.255.255 (ff:ff:ff:ff:ff:ff)
> OP: 1 (BOOTPREQUEST)
>  HTYPE: 1 (Ethernet)
>   HLEN: 6
>   HOPS: 0
>XID: 92a34fc3
>   SECS: 0
>  FLAGS: 0
> CIADDR: 0.0.0.0
> YIADDR: 0.0.0.0
> SIADDR: 0.0.0.0
> GIADDR: 0.0.0.0
> CHADDR: 00:22:5f:70:a1:df:00:00:00:00:00:00:00:00:00:00
>  SNAME: .
>  FNAME: .
> OPTION:  53 (  1) DHCP message type 1 (DHCPDISCOVER)
> OPTION:  61 (  8) Client-identifier 01:06:00:22:5f:70:a1:df
> OPTION:  12 (  3) Host name zen
> OPTION:  55 (  9) Parameter Request List  1 (Subnet mask)
>  28 (Broadcast address)
>   2 (Time offset)
> 121 (Classless Static Route)
>   3 (Routers)
>  15 (Domainname)
>   6 (DNS server)
>  12 (Host name)
> 119 (Domain Search)
>
> ---
>
>   TIME: 2016-05-18 18:46:39.134
> IP: 10.0.0.1 (4c:5e:0c:62:4f:82) > 10.0.0.80 (00:22:5f:70:a1:df)
> OP: 2 (BOOTPREPLY)
>  HTYPE: 1 (Ethernet)
>   HLEN: 6
>   HOPS: 0
>XID: 92a34fc3
>   SECS: 0
>  FLAGS: 0
> CIADDR: 0.0.0.0
> YIADDR: 10.0.0.80
> SIADDR: 10.0.0.1
> GIADDR: 0.0.0.0
> CHADDR: 00:22:5f:70:a1:df:00:00:00:00:00:00:00:00:00:00
>  SNAME: .
>  FNAME: .
> OPTION:  53 (  1) DHCP message type 2 (DHCPOFFER)
> OPTION:  54 (  4) Server identifier 10.0.0.1
> OPTION:  51 (  4) IP address leasetime  259200 (3d)
> OPTION:   1 (  4) Subnet mask   255.255.255.0
> OPTION:   3 (  4) Routers   10.0.0.1
> OPTION:   6 (  4) DNS server10.0.0.1
> ---
>
>
> And here's the request/offer that works (with the r299512 backed out)
>
> ---
>
>   TIME: 2016-05-18 18:35:33.817
> IP: 10.0.0.220 (00:22:5f:70:a1:df) > 255.255.255.255 (ff:ff:ff:ff:ff:ff)
> OP: 1 (BOOTPREQUEST)
>  HTYPE: 1 (Ethernet)
>   HLEN: 6
>   HOPS: 0
>XID: 866cfd85
>   SECS: 4
>  FLAGS: 0
> CIADDR: 0.0.0.0
> YIADDR: 0.0.0.0
> SIADDR: 0.0.0.0
> GIADDR: 0.0.0.0
> CHADDR: 00:22:5f:70:a1:df:00:00:00:00:00:00:00:00:00:00
>  SNAME: .
>  FNAME: .
> OPTION:  53 (  1) DHCP message type 3 (DHCPREQUEST)
> OPTION:  50 (  4) Request IP address10.0.0.220
> OPTION:  61 (  7) Client-identifier 01:00:22:5f:70:a1:df
> OPTION:  12 (  3) Host name zen
> OPTION:  55 (  9) Parameter Request List  1 (Subnet mask)
>  28 (Broadcast address)
>   2 (Time offset)
> 121 (Classless Static Route)
>   3 (Routers)
>  15 (Domainname)
>   6 (DNS server)
>  12 (Host name)
> 119 (Domain Search)
>
> ---
>
>   TIME: 2016-05-18 18:35:33.817
> IP: 10.0.0.1 (4c:5e:0c:62:4f:82) > 10.0.0.220 (00:22:5f:70:a1:df)
> OP: 2 (BOOTPREPLY)
>  HTYPE: 1 (Ethernet)
>   HLEN: 6
>   HOPS: 0
>XID: 866cfd85
>   SECS: 0
>  FLAGS: 0
> CIADDR: 0.0.0.0
> YIADDR: 10.0.0.220
> SIADDR: 10.0.0.1
> GIADDR: 0.0.0.0
> CHADDR: 00:22:5f:70:a1:df:00:00:00:00:00:00:00:00:00:00
>  SNAME: .
>  FNAME: .
> OPTION:  53 (  1) DHCP message type 5 (DHCPACK)
> OPTION:  54 (  4) Server identifier 10.0.0.1
> OPTION:  51 (  4) IP address leasetime  259200 (3d)
> OPTION:   1 (

r299512 breaks dhclient on some networks

2016-05-18 Thread Ian FREISLICH 
Hi

I cannot for the life of me figure out why the change in r299512 breaks
DHCP on one network I use but not on another network.
 
The only clue I can find is that the request whose response is ignored
has the following client ID:
1:6:0:22:5f:70:a1:df

The request whose response is use has this client ID:
1:0:22:5f:70:a1:df

Here's a dhcpdump of the request/offer that gets ignored.

---

  TIME: 2016-05-18 18:46:39.134
IP: 0.0.0.0 (00:22:5f:70:a1:df) > 255.255.255.255 (ff:ff:ff:ff:ff:ff)
OP: 1 (BOOTPREQUEST)
 HTYPE: 1 (Ethernet)
  HLEN: 6
  HOPS: 0
   XID: 92a34fc3
  SECS: 0
 FLAGS: 0
CIADDR: 0.0.0.0
YIADDR: 0.0.0.0
SIADDR: 0.0.0.0
GIADDR: 0.0.0.0
CHADDR: 00:22:5f:70:a1:df:00:00:00:00:00:00:00:00:00:00
 SNAME: .
 FNAME: .
OPTION:  53 (  1) DHCP message type 1 (DHCPDISCOVER)
OPTION:  61 (  8) Client-identifier 01:06:00:22:5f:70:a1:df
OPTION:  12 (  3) Host name zen
OPTION:  55 (  9) Parameter Request List  1 (Subnet mask)
 28 (Broadcast address)
  2 (Time offset)
121 (Classless Static Route)
  3 (Routers)
 15 (Domainname)
  6 (DNS server)
 12 (Host name)
119 (Domain Search)
   
---

  TIME: 2016-05-18 18:46:39.134
IP: 10.0.0.1 (4c:5e:0c:62:4f:82) > 10.0.0.80 (00:22:5f:70:a1:df)
OP: 2 (BOOTPREPLY)
 HTYPE: 1 (Ethernet)
  HLEN: 6
  HOPS: 0
   XID: 92a34fc3
  SECS: 0
 FLAGS: 0
CIADDR: 0.0.0.0
YIADDR: 10.0.0.80
SIADDR: 10.0.0.1
GIADDR: 0.0.0.0
CHADDR: 00:22:5f:70:a1:df:00:00:00:00:00:00:00:00:00:00
 SNAME: .
 FNAME: .
OPTION:  53 (  1) DHCP message type 2 (DHCPOFFER)
OPTION:  54 (  4) Server identifier 10.0.0.1
OPTION:  51 (  4) IP address leasetime  259200 (3d)
OPTION:   1 (  4) Subnet mask   255.255.255.0
OPTION:   3 (  4) Routers   10.0.0.1
OPTION:   6 (  4) DNS server10.0.0.1
---


And here's the request/offer that works (with the r299512 backed out)

---

  TIME: 2016-05-18 18:35:33.817
IP: 10.0.0.220 (00:22:5f:70:a1:df) > 255.255.255.255 (ff:ff:ff:ff:ff:ff)
OP: 1 (BOOTPREQUEST)
 HTYPE: 1 (Ethernet)
  HLEN: 6
  HOPS: 0
   XID: 866cfd85
  SECS: 4
 FLAGS: 0
CIADDR: 0.0.0.0
YIADDR: 0.0.0.0
SIADDR: 0.0.0.0
GIADDR: 0.0.0.0
CHADDR: 00:22:5f:70:a1:df:00:00:00:00:00:00:00:00:00:00
 SNAME: .
 FNAME: .
OPTION:  53 (  1) DHCP message type 3 (DHCPREQUEST)
OPTION:  50 (  4) Request IP address10.0.0.220
OPTION:  61 (  7) Client-identifier 01:00:22:5f:70:a1:df
OPTION:  12 (  3) Host name zen
OPTION:  55 (  9) Parameter Request List  1 (Subnet mask)
 28 (Broadcast address)
  2 (Time offset)
121 (Classless Static Route)
  3 (Routers)
 15 (Domainname)
  6 (DNS server)
 12 (Host name)
119 (Domain Search)
   
---

  TIME: 2016-05-18 18:35:33.817
IP: 10.0.0.1 (4c:5e:0c:62:4f:82) > 10.0.0.220 (00:22:5f:70:a1:df)
OP: 2 (BOOTPREPLY)
 HTYPE: 1 (Ethernet)
  HLEN: 6
  HOPS: 0
   XID: 866cfd85
  SECS: 0
 FLAGS: 0
CIADDR: 0.0.0.0
YIADDR: 10.0.0.220
SIADDR: 10.0.0.1
GIADDR: 0.0.0.0
CHADDR: 00:22:5f:70:a1:df:00:00:00:00:00:00:00:00:00:00
 SNAME: .
 FNAME: .
OPTION:  53 (  1) DHCP message type 5 (DHCPACK)
OPTION:  54 (  4) Server identifier 10.0.0.1
OPTION:  51 (  4) IP address leasetime  259200 (3d)
OPTION:   1 (  4) Subnet mask   255.255.255.0
OPTION:   3 (  4) Routers   10.0.0.1
OPTION:   6 (  4) DNS server10.0.0.1
---



-- 
Ian Freislich


-- 
 

Cape Augusta Digital Properties, LLC a Cape Augusta Company

*Breach of confidentiality & accidental breach of confidentiality *

This email and any files transmitted with it are confidential and intended 
solely for the use of the individual or entity to whom they are addressed. 
If you have received this email in error please notify the system manager. 
This