If you're using udhcpc as a client when connecting to your ISP, and you happen to restart your router, it would be nice to be able to retain the least and request the same IP address when restarting. Certain routing packages (like Openwrt) reboot fairly quickly, and if you can get the same address back within 90 seconds, none of your open connections will be torn down (which is a win).
(In reply to comment #0) > If you're using udhcpc as a client when connecting to your ISP, and you happen > to restart your router, it would be nice to be able to retain the least and > request the same IP address when restarting. I'm confused. Something doesn't let you use -r IP option to achieve this? Please describe the problem in more details.
(In reply to comment #1) > (In reply to comment #0) > > If you're using udhcpc as a client when connecting to your ISP, and you happen > > to restart your router, it would be nice to be able to retain the least and > > request the same IP address when restarting. > > I'm confused. Something doesn't let you use -r IP option to achieve this? > Please describe the problem in more details. The initiates a /new/ lease request that asks for a specific address (i.e. via a DISCOVERY packet). I'm talking about reusing all of the previous state (server address, IP address, transaction address, expiration time, lease duration, etc) to refresh the /current/ lease (i.e. via a REQUEST packet), assuming that the previous lease hadn't been released during shutdown.
To be clear, I'll quote the ISC dhclient man page, which already has this functionality: In order to keep track of leases across system reboots and server restarts, dhclient keeps a list of leases it has been assigned in the dhclient.leases(5) file. On startup, after reading the dhclient.conf file, dhclient reads the dhclient.leases file to refresh its memory about what leases it has been assigned. When a new lease is acquired, it is appended to the end of the dhclient.leases file. In order to prevent the file from becoming arbitrarily large, from time to time dhclient creates a new dhclient.leases file from its in-core lease database. The old version of the dhclient.leases file is retained under the name dhclient.leases~ until the next time dhclient rewrites the database. Old leases are kept around in case the DHCP server is unavailable when dhclient is first invoked (generally during the initial system boot process). In that event, old leases from the dhclient.leases file which have not yet expired are tested, and if they are determined to be valid, they are used until either they expire or the DHCP server becomes available. A mobile host which may sometimes need to access a network on which no DHCP server exists may be preloaded with a lease for a fixed address on that network. When all attempts to contact a DHCP server have failed, dhclient will try to validate the static lease, and if it succeeds, will use that lease until it is restarted. A mobile host may also travel to some networks on which DHCP is not available but BOOTP is. In that case, it may be advantageous to arrange with the network administrator for an entry on the BOOTP data‐ base, so that the host can boot quickly on that network rather than cycling through the list of old leases. So what I'm talking about is the ability to statically maintain (and reuse) unexpired leases across reboots.
(In reply to comment #2) > (In reply to comment #1) > > (In reply to comment #0) > > > If you're using udhcpc as a client when connecting to your ISP, and you happen > > > to restart your router, it would be nice to be able to retain the least and > > > request the same IP address when restarting. > > > > I'm confused. Something doesn't let you use -r IP option to achieve this? > > Please describe the problem in more details. > > The initiates a /new/ lease request that asks for a specific address (i.e. via > a DISCOVERY packet). > > I'm talking about reusing all of the previous state (server address, IP > address, transaction address, expiration time, lease duration, etc) to refresh > the /current/ lease (i.e. via a REQUEST packet), assuming that the previous > lease hadn't been released during shutdown. I see the difference, but I don't see how is it materially different in practice. With "udhcpc -r IP" invocation, where IP is the IP is the last IP we were using, client will ask server to give it the previous address. Server should be ready for such common use case anyway, because this happens all the time when clients are rebooted. So it should give us this address. Do you work with server which doesn't?
(In reply to comment #4) > I see the difference, but I don't see how is it materially different in > practice. > > With "udhcpc -r IP" invocation, where IP is the IP is the last IP we were > using, client will ask server to give it the previous address. Server should be > ready for such common use case anyway, because this happens all the time when > clients are rebooted. So it should give us this address. > > Do you work with server which doesn't? I haven't tried with the servers that I currently have access to, but I know that I've worked with seriously (and deliberately) damaged servers in the past, including one that would not allow you to renew your lease... the reasons being that (1) if you had a stable IP address, it was easier to run a file-sharing P2P service like bit-torrent, and (2) it made 3rd party VoIP services competitive with this major US cable operator's own VoIP service... so constantly swapping out people IP addresses every few hours was an effective way to cripple all competitors' VoIP services. My point is that you shouldn't count on an ISP's service conforming to the spec or even refraining from certain malicious, disruptive practices.
(In reply to comment #3) > To be clear, I'll quote the ISC dhclient man page, which already has this > functionality: > > In order to keep track of leases across system reboots and server > restarts, dhclient keeps a list of leases it has been assigned in the > dhclient.leases(5) file. On startup, after reading the dhclient.conf > file, dhclient reads the dhclient.leases file to refresh its memory > about what leases it has been assigned. > > When a new lease is acquired, it is appended to the end of the > dhclient.leases file. In order to prevent the file from becoming > arbitrarily large, from time to time dhclient creates a new > dhclient.leases file from its in-core lease database. The old version > of the dhclient.leases file is retained under the name dhclient.leases~ > until the next time dhclient rewrites the database. > > Old leases are kept around in case the DHCP server is unavailable when > dhclient is first invoked (generally during the initial system boot > process). In that event, old leases from the dhclient.leases file > which have not yet expired are tested, and if they are determined to be > valid, they are used until either they expire or the DHCP server > becomes available. > > A mobile host which may sometimes need to access a network on which no > DHCP server exists may be preloaded with a lease for a fixed address on > that network. When all attempts to contact a DHCP server have failed, > dhclient will try to validate the static lease, and if it succeeds, > will use that lease until it is restarted. > > A mobile host may also travel to some networks on which DHCP is not > available but BOOTP is. In that case, it may be advantageous to > arrange with the network administrator for an entry on the BOOTP data‐ > base, so that the host can boot quickly on that network rather than > cycling through the list of old leases. > > So what I'm talking about is the ability to statically maintain (and reuse) > unexpired leases across reboots. I see. I think this functionality can be implemented by dhcp script: > When a new lease is acquired, it is appended to the end of the > dhclient.leases file... This can be implemented when "$script bound" is called, by recording values of $ip, $lease etc. > Old leases are kept around in case the DHCP server is unavailable when > dhclient is first invoked (generally during the initial system boot > process). In that event, old leases from the dhclient.leases file > which have not yet expired are tested, and if they are determined to be > valid, they are used... This can be implemented when "$script leasefail" is called, by analyzing previously-recorded lease(s), and activating it. > A mobile host which may sometimes need to access a network on which no > DHCP server exists may be preloaded with a lease for a fixed address on > that network. When all attempts to contact a DHCP server have failed, > dhclient will try to validate the static lease, and if it succeeds Also can be implemented by script's "leasefail" handler.
I tend to not implement this in udhcpc, for the reasons described above. If you disagree, please reopen and explain your position.
(In reply to comment #7) > I tend to not implement this in udhcpc, for the reasons described above. > > If you disagree, please reopen and explain your position. Ok, I thought I already did that, but here goes again. Your argument is predicated on the assumption that the server is correctly implemented, and that the network operator is motivated to have their server behave in the way that's least disruptive to clients: > Server should be ready for such common use case anyway, because this > happens all the time when clients are rebooted. This might be the case in a LAN environment where the customer and the network operator are in the same organization and reporting structure. It is not the case in a WAN environment. Respectfully, I don't think you understand how ISPs work. I'll give you the benefit of having worked for France Telecom for 5 years, Erol's Internet, Bellcore and Metricom for another 3 total. The laws of economics being what they are, an ISP wants to spend the least amount of operating costs on provisioning bandwidth for their network, while at the same time extracting the most revenue they can without forcing their customers into mass exodus. Hopefully this is something we can both agree on. Allowing a customer to have a stable IP address, even if it's dynamically allocated, allows him to operate services on a semi-permanent basis that consume large amounts of bandwidth (such as file sharing, video conferencing, and other server operation). More consuming large amounts of bandwidth means that the network operator needs to spend more money over-engineering their network, which cuts into their profit. It is not in an ISP's interest to strictly follow the specification and renew an unexpired lease if it can be avoided. My own experience dogfooding UBR-925s at Cisco Systems was that TCI and Comcast would issue a *new* IP address if a new negotiation cycle was initiated with a DISCOVERY packet. Conversely, they would honor an lease renewal cycle starting with a REQUEST and containing the same parameters as present in the last OFFER. (There was a period when even with a REQUEST to extend a lease, Comcast would NAK it and issue a new address; the speculative reason for doing this was to stop customers from using 3rd party VoIP services. This behavior has since stopped.) Bottom line: if you're counting on ISPs to follow the letter of the specification religiously server-side, you're going to be disappointed. Anyway, Postel's adage was "be conservative in what you send". In this scenario, the conservative thing to send would be a request for the same lease, not a new one, since that leaves the fewest IP addresses in a possibly unused state while the server keeps them tied up waiting for the leases to expire (even if this is unlikely, the entire point of Postel's adage was that the sender can never and should never count on the receiver doing the optimal thing).
I understand your explanation and agree with your arguments. I still think it needs to be implemented in the script, in udhcpc code.