0

i am having issues with the network connectivity on Ubuntu server 16.04. I am connected to Verizon Fios via Ethernet (it's defined as dhcp on the /etc/network/interfaces file.)

The DHCP Client that I am using to connect to them is DHCP-ISC-Client, It's known as DHCLIENT as well.

The custom configuration that I am using on my dhclient.conf is:

supersede dhclient-lease-time 2000000; supersede dhcp-rebinding-time 2000000; supersede dhcp-renewal-time   2000000; timeout 1000000; select timeout 1; inital-interval 2;

Screenshot of the configuration file

My dhclient.conf looks like that.

before adding the supersede dhclient-lease-time 2000000; I was getting basically a lease of 3000 Seconds, after the expiration of that lease the DHCP server doesn't send any new offer to renew it. I have put 2000.000 seconds, but my internet drops after 3 hours, while I am connected to the internet, the dhcp-client keeps sending offers to the server (I don't know if It's acceptable or not)

Please, guys, seek your help here, Thanks.

Maruan Awad
  • 11
  • 2

1 Answers1

1

Are you using custom firewall rules of any kind?

Getting DHCP through firewalls can be a bit tricky, as the initial discover/offer/request/acknowledge cycle happens using broadcasts with source IP 0.0.0.0 and destination 255.255.255.255, but renewals have the option of using unicasts instead. If you are not allowing in UDP traffic from the DHCP server to your port 68/UDP, you might be accidentally filtering out the DHCP server's responses to the renewal requests sent by your system.

By superseding the lease/rebinding/renewal times, you're probably just shooting yourself in the foot. Your DHCP client is responsible for sending a lease renewal request after half of the lease time specified by the server has passed. So your dhclient should be starting to attempt a renewal after 1500 seconds or so from the initial IP allocation. But you've told dhclient that despite whatever the DHCP server says, dhclient doesn't have to do that until 2000000 seconds (>23 days) has passed, so the renewals will not happen.

Even if you supersede the lease time values, the DHCP server is not required to honor your modified time values: it can simply ignore the client's suggestion about longer lease times.

If the lease time configured at the DHCP server is 3000 seconds, then after your dhclient has held the address for 3000 seconds and not sent a renewal request, the DHCP server can release "your" IP address back to the pool of allocatable IP addresses. Depending on the number of clients requesting IP addresses from the DHCP server, it may take a while for "your" IP address to actually get reassigned to someone else, and during that time you may in practice still be able to use that IP address. In your case, it seems to take about 3 hours.

Once the IP actually gets assigned to someone else, then whatever protection against IP hijacking is in effect on your ISP shifts from protecting you to protecting the new holder of the IP address, and you will lose your internet connection as a result.

It might also be some sort of a periodic "cleanup" job in the ISP's infrastructure, disconnecting IP addresses that have been without a valid DHCP lease more than XXXX seconds. If you can get your previous IP address back after 3 hours by disabling & re-enabling your network interface, then this is probably what's happening.

telcoM
  • 4,448
  • 15
  • 25
  • Thanks so much for your answer. We have a firewall, but it is not pointing any IP to 0.0.0.0, The thing that concerns me is that the DHCP server doesn't come with a new IP. Instead, it just disconnects me even when a valid lease time is present, When I was using windows, the IP used to persist for days. – Maruan Awad Oct 18 '19 at 16:26
  • The DHCP server won't send an extension automatically; your `dhclient` must ask for a renewal. You've configured `dhclient` to ignore the fact that the DHCP server tells your client to renew at every 3000 seconds or less. You should verify that a) an extension request gets properly sent, b) the outgoing extension request is not blocked by a firewall, and c) that the DHCP server's response to the extension request actually gets back and is not blocked by a firewall. Since the extension request & response can be unicasts, they may require a different firewall rule than the initial DHCP request. – telcoM Oct 19 '19 at 13:28