Bug #5648
closedDHCP lease reading is done in the wrong order
Description
DHCP uses a last-lease-wins system - new leases are appended to the leases file and automatically are preferred over earlier entries. However, the proxy uses a first-lease-wins, where we discard any leases that we already have in memory when parsing the leases file.
When you have a lease file like this:
lease 192.168.123.58 {
starts 5 2014/05/09 14:38:13;
ends 5 2014/05/09 14:48:13;
cltt 5 2014/05/09 14:38:13;
binding state active;
next binding state free;
rewind binding state free;
hardware ethernet 52:54:00:22:17:2b;
uid "\001RT\000\"\027+";
}
lease 192.168.123.59 {
starts 5 2014/05/09 14:39:00;
ends 5 2014/05/09 14:49:00;
cltt 5 2014/05/09 14:39:00;
binding state active;
next binding state free;
rewind binding state free;
hardware ethernet 52:54:00:22:17:2b;
}
lease 192.168.123.59 {
starts 5 2014/05/09 14:39:12;
ends 5 2014/05/09 14:49:12;
cltt 5 2014/05/09 14:39:12;
binding state active;
next binding state free;
rewind binding state free;
hardware ethernet 52:54:00:22:17:2b;
}
Then the proxy would report that /dhcp/192.168.123.0/52:54:00:22:17:2b has IP 192.168.123.58 - when in actual fact it has 192.168.123.59.
We need to rewire the proxy to replace leases in memory as it parses down the file.
Updated by Dominic Cleal over 10 years ago
- Status changed from Assigned to Ready For Testing
Updated by Dominic Cleal over 10 years ago
- Related to Bug #5637: DHCP conflicts triggered for non-conflicting leases added
Updated by Dominic Cleal over 10 years ago
- Related to Bug #5739: Host deletion finds irrelevant old leases added
Updated by Anonymous over 10 years ago
- Target version changed from 1.8.3 to 1.8.2
Updated by Anonymous over 10 years ago
- Status changed from Ready For Testing to Closed
- % Done changed from 0 to 100
Applied in changeset 2080b2eb85162c76e0edf2e4630a0f9a3a23b494.
Updated by Bryan Kearney over 10 years ago
- Bugzilla link set to https://bugzilla.redhat.com/show_bug.cgi?id=1107706
Updated by Lukas Zapletal about 10 years ago
One comment while I am investigating some DHCP race conditions:
Although in most cases the host will have IP .59, there are cases when that's not the case and IP .58 is the correct one. We can't simply tell which one is correct, because both leases are active since the former one has UID set. Therefore, in case the system reboots into different OS that reports UID (usually Windows, can be anything with DHCP client configured this way) then IP .59 becomes invalid.
I am leaving this note here for the record, just in case somebody hits this. I have some issues with discovery (this patch applied), I am investigaing what is wrong in this case.