Re: r299512 breaks dhclient on some networks
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
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
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
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
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: 00:22:5f:70:a1:df:00:00:00:00:00:00:00:00:00:00 >> SNAME: . >> F
Re: r299512 breaks dhclient on some networks
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
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
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
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 ( 4) Subnet mask 255