I have a piece of equipment I would like to default to a specific IP address when no dhcp servers are available. I have set the following static lease in /etc/dhcp/dhclient.conf: timeout 30; lease { interface "eth0"; fixed-address 192.168.1.254; option subnet-mask 255.255.255.0; option routers 127.0.0.1; expire never; } It works, but eth0 will only get this IP when dhclient.eth0.leases and dhclient.leases in /var/lib/dhcp/ are empty. Unless you guys have a good reason to advise against it, I would prefer if the static lease from dhclient.conf was assigned when a dhcp server doesn't reply instead of using old leases. It would make the troubleshooting process easier and allow some way to reach the equipment which is only accessible via ssh and has no display to print out the current ip. I read through the dhclient manual and a lot of google search results but couldn't find a built in way or any suggestions on how to do this. **Solutions I thought of:** 1-Empty dhclient.leases and set permissions so it can't be modified
2-Link dhclient.leases to /dev/null and set permissions so it can't be modified
3-Same as #1 but instead of setting up the static lease in dhclient.conf, manually add it to dhclient.leases before setting permissions.

Here is my interfaces file: auto lo iface lo inet loopback auto eth0 iface eth0 inet dhcp auto eth0:0 iface eth0:0 inet static address 10.20.8.231 netmask 255.255.255.0 gateway 10.20.8.1 up /sbin/route add 1.2.3.4 gw 10.20.8.1 down /sbin/route del 1.2.3.4 gw 10.20.8.1 From the multiple examples I have found online this should add routes when eth0:0 comes up but for some reason I can't get it to work. When I try to bring up the interface with ifup eth0:0 I get: RTNETLINK answers: File exists Failed to bring up eth0:0. Then, ifconfig shows eth0:0 is up but route -n does not show the new route. In fact it shows the exact same routes I had before. Nothing changed. Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 0.0.0.0 10.20.8.1 0.0.0.0 UG 0 0 0 eth0 10.20.8.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 This config is to be used on remote systems that can only be accessed via SSH. The whole idea is to keep eth0 set to dhcp as a backup when the site's network is changed (happened twice already) rendering the static ip unaccessible. The problem with this is that SSH (used by built in processes) uses the default route via eth0 and that doesn't work as the firewall (not managed by us) has been set to allow ssh only for the static IP on eth0:0. Note: In the example above 1.2.3.4 represents our ssh server and I am trying to route traffic via eth0:0 for that single host but after testing I may want to set the default route to use eth0:0 instead, but I also tried that and it failed the same way. I was using this line: up route add -net 0.0.0.0 netmask 0.0.0.0 gw 10.20.8.1
**Thank you for your assistance.**

there are so many tutorials out there explaining how to setup dhcpd server, in relation to providing ntp suggestions to dhcp clients, that I had always thought that ntp configuration was carried out automatically. Recently I started seeing clock drifts in my local network, so I assume this was a wrong assumption. So I set out to see how can one minimize the ntp client configuration, provided one has carried out the effort to set up ntp-server suggestions through dhcpd. I have not been able to find much apart from this Ubuntu specific help tutorial https://help.ubuntu.com/community/UbuntuTime . Even here (see paragraph under "Troubleshooting -> Which configuration file is it using?") the information is scarce but it says that if an /etc/ntp.conf.dhcp file is found it will be used instead. First of all the actual location that the writer meant here is /var/lib/ntp/ntp.conf.dhcp as observed in /etc/init.d/ntp , but regardless of that the presence of this file does not guarantee that the ntp will request servers from dhclient. As a result, I have to explicitly add the server clause in ntp.conf.dhcp for my local ntp server. But in that case, why do I even setup ntp settings on the dhcpd server? This seems to go against intuition, ie setup ntp settings once (ie on the server) and let dhcpd server delegate the information to the clients. How can I minimize (if not avoid altogether), client configuration for the ntp. Alternatively, how can I get ntp information through dhclient. Is there a cli solution that fits all linux distros? I assume every client should have the executables of ntpd, but I do not know how to proceed from there. Thank you EDIT: ubuntu client verbose output when running manually dhclient: sudo dhclient -1 -d -pf /run/dhclient.eth0.pid -lf /var/lib/dhcp/dhclient.eth0.leases eth0 Internet Systems Consortium DHCP Client 4.2.4 Copyright 2004-2012 Internet Systems Consortium. All rights reserved. For info, please visit https://www.isc.org/software/dhcp/ Listening on LPF/eth0/20:cf:30:0e:6c:12 Sending on LPF/eth0/20:cf:30:0e:6c:12 Sending on Socket/fallback DHCPREQUEST of 192.168.112.150 on eth0 to 255.255.255.255 port 67 (xid=0x2e844b8f) DHCPACK of 192.168.112.150 from 192.168.112.112 reload: Unknown instance: invoke-rc.d: initscript smbd, action "reload" failed. RTNETLINK answers: File exists * Stopping NTP server ntpd ...done. * Starting NTP server ntpd ...done. bound to 192.168.112.150 -- renewal in 41963 seconds. The ntpd service is restarted, yet running ntpq -cpe -cas afterwards I still do not see my local ntp server in the list of ntp servers. Of course my dhcpd server does have option ntp-servers subnet 192.168.112.0 netmask 255.255.255.0 { max-lease-time 604800; default-lease-time 86400; authoritative; ignore client-updates; option ntp-servers 192.168.112.112; #self ... (many other options) }

Is there a way to show my current (client) DHCP lease? Or even better - retrieve all options/infos sent with DHCPACK?

I have isc-dhcp-4.2.5 server and client installed on two CentOS-7.4 boxes. I know this is quite old distro, but I can't change it for various reasons. Dhcp server configuration: option domain-name "mydomain.org"; option domain-name-servers ns1.mydomain.org, ns2.mydomain.org; default-lease-time 600; max-lease-time 7200; log-facility local7; option space myspace; option myspace.node-ip code 1 = ip-address; # Tell the server to return vendor-specific information option dhcp-parameter-request-list 43; class "vendor-classes" { match option vendor-class-identifier; } subclass "vendor-classes" "my-vendor-class-ID" { vendor-option-space myspace; option myspace.node-ip 10.5.6.7; } subnet 10.0.0.0 netmask 255.255.255.0 { range 10.0.0.50 10.0.0.60; option routers 10.0.0.254; } Dhcp client configuration: interface "veth0" { send dhcp-client-identifier "my-client-ID"; send vendor-class-identifier "my-vendor-class-ID"; send dhcp-lease-time 900; } I'm seeing two problems: 1. The client fails to send options dhcp-client-identifier and vendor-class-identifier, tcpdump does not show those 2. The server fails to send Option-43 It's almost that this version does not support dhcp-client-identifier and vendor-class-identifier at all? What am I doing wrong? PS. Latest ISC-dhcp (ver. 4.4.2) built from https://gitlab.isc.org/isc-projects/dhcp has no these problems.

I am using RHEL 8.9 and have created a basic dhclient hook script in which I want to log to a file. The script is able to write to places like /tmp, but not /opt. It can *read* files from /opt, but not write to the directory:

-shellsession
[root@server]# ls -la /etc/dhcp/dhclient-exit-hooks.d/test.sh
-rwxr-xr-x. 1 root root 159 Feb 12 22:47 /etc/dhcp/dhclient-exit-hooks.d/test.sh

[root@server]# cat /etc/dhcp/dhclient-exit-hooks.d/test.sh
#!/bin/bash
{ date; cat /opt/test1.txt; } >> /tmp/test1.txt # works as expected (reading from /opt and writing to /tmp)
date >> /opt/test2.txt # does not work; cannot write to /opt

When testing the hook I am seeing permission issues:

-shellsession
[root@server]# dhclient eth0
/etc/dhcp/dhclient-exit-hooks.d/test.sh: line 3: /opt/test2.txt: Permission denied

I have verified that write access is granted on the file in /opt, and even gone so far as to give write/execute to all users on the directory:

-shellsession
[root@server]# ls -la /opt/
total 8
drwxrwxrwx.  2 root root  40 Feb 12 22:46 .
dr-xr-xr-x. 17 root root 224 Dec 21 10:37 ..
-rw-rw-rw-.  1 root root   4 Feb 12 22:45 test1.txt
-rw-rw-rw-.  1 root root   4 Feb 12 22:46 test2.txt

File reading/writing to /tmp is working without issues. I also can run the script directly with root and not face any permission issues (it works as expected). Any ideas?

I have this server that loses its network config on reboots, it's running Ubuntu Server 18.04, I tried the netplan commands but none generated a thing, maybe it's because the interface isn't even there until I run dhclient, only then the system brings the interface up and DHCP assigns it its static address. On boot, only the loopback interface is brought up automatically. Instead of going crazy trying to decipher netplan--which most likely I'm not going to use much since I loathe Ubuntu for some reason--I'd like to go around it and just automatically run dhclient upon boot. Would something like a cron job work? Do I need to assign special permissions somewhere or have special permissions? Thanks for your help!

I am new to Linux, I installed CentOS 7.9 in my labtop. I do not know why, sometimes the fan was extremely noisy, then I type

to see which one caused this, I found "dhclient" consumes even 700%+ CPU (my CPU has 8 cores?)

15967 sshd      30  10 3707632   2.4g   4692 S 784.7 16.0 158:32.13 dhclient                                                                                    
 4134 ring      20   0 4258860 326992 113188 S   9.1  2.0  38:51.93 gnome-shell                                                                                 
 2495 root      20   0  599888 223084  95240 S   1.4  1.4   5:20.28 X                                                                                           
 4780 ring      20   0  681880  41128  19908 S   1.4  0.3   0:31.30 gnome-terminal-                                                                             
11130 root      20   0   39476   1276    988 S   1.4  0.0   8:44.93 monitor                                                                                     
    9 root      20   0       0      0      0 S   0.3  0.0   0:20.52 rcu_sched                                                                                   
  728 root     -51   0       0      0      0 S   0.3  0.0   0:03.63 irq/141-iwlwifi                                                                             
 4102 ring      20   0   68396   2496   1860 S   0.3  0.0   0:00.47 dbus-daemon                                                                                 
18583 ring      20   0 2828144 168724  62708 S   0.3  1.1   1:52.56 Isolated Web Co                                                                             
18806 ring      20   0 2768992 126664  60628 S   0.3  0.8   1:17.29 Isolated Web Co                                                                             
24739 ring      20   0   58680   2484   1532 R   0.3  0.0   0:00.15 top                                                                                         
    1 root      20   0  194644   7792   4236 S   0.0  0.0   0:07.88 systemd                                                                                     
    2 root      20   0       0      0      0 S   0.0  0.0   0:00.05 kthreadd

Then I use

/var/log/messages | grep dhclient

, these are messages, could any help find out what happened? what should I do to solve this problem?

Jan  1 20:22:51 eda dhclient: DHCPDISCOVER on virbr0 to 255.255.255.255 port 67 interval 15 (xid=0x6ae2ab58)
Jan  1 20:22:54 eda dhclient: [2024-01-01 20:22:54.479]  net      new job from 3389.xiao.my.id:3389 diff 8910K algo rx/0 height 154453
Jan  1 20:23:06 eda dhclient: DHCPDISCOVER on virbr0 to 255.255.255.255 port 67 interval 9 (xid=0x6ae2ab58)
Jan  1 20:23:15 eda dhclient: DHCPDISCOVER on virbr0 to 255.255.255.255 port 67 interval 11 (xid=0x6ae2ab58)
Jan  1 20:23:26 eda dhclient: DHCPDISCOVER on virbr0 to 255.255.255.255 port 67 interval 10 (xid=0x6ae2ab58)
Jan  1 20:23:36 eda dhclient: DHCPDISCOVER on virbr0 to 255.255.255.255 port 67 interval 7 (xid=0x6ae2ab58)
Jan  1 20:23:42 eda dhclient: [2024-01-01 20:23:42.031]  net      new job from 3389.xiao.my.id:3389 diff 9061K algo rx/0 height 154454
Jan  1 20:23:42 eda dhclient: [2024-01-01 20:23:42.956]  miner    speed 10s/60s/15m 1220.6 1257.6 n/a H/s max 2571.8 H/s
Jan  1 20:23:43 eda dhclient: No DHCPOFFERS received.
Jan  1 20:23:43 eda dhclient: No working leases in persistent database - sleeping.
Jan  1 20:24:43 eda dhclient: [2024-01-01 20:24:43.326]  miner    speed 10s/60s/15m 1151.4 1164.1 n/a H/s max 2571.8 H/s
Jan  1 20:25:43 eda dhclient: [2024-01-01 20:25:43.586]  miner    speed 10s/60s/15m 1205.5 1283.1 n/a H/s max 2571.8 H/s
Jan  1 20:26:31 eda dhclient: DHCPDISCOVER on virbr0-nic to 255.255.255.255 port 67 interval 6 (xid=0x364db7a7)
Jan  1 20:26:37 eda dhclient: DHCPDISCOVER on virbr0-nic to 255.255.255.255 port 67 interval 11 (xid=0x364db7a7)
Jan  1 20:26:43 eda dhclient: [2024-01-01 20:26:43.948]  miner    speed 10s/60s/15m 1326.5 1178.2 n/a H/s max 2571.8 H/s
Jan  1 20:26:48 eda dhclient: DHCPDISCOVER on virbr0-nic to 255.255.255.255 port 67 interval 9 (xid=0x364db7a7)
Jan  1 20:26:57 eda dhclient: DHCPDISCOVER on virbr0-nic to 255.255.255.255 port 67 interval 14 (xid=0x364db7a7)
Jan  1 20:27:11 eda dhclient: DHCPDISCOVER on virbr0-nic to 255.255.255.255 port 67 interval 14 (xid=0x364db7a7)
Jan  1 20:27:25 eda dhclient: DHCPDISCOVER on virbr0-nic to 255.255.255.255 port 67 interval 7 (xid=0x364db7a7)
Jan  1 20:27:32 eda dhclient: No DHCPOFFERS received.
Jan  1 20:27:32 eda dhclient: No working leases in persistent database - sleeping.
Jan  1 20:27:44 eda dhclient: [2024-01-01 20:27:44.309]  miner    speed 10s/60s/15m 1342.5 1264.8 n/a H/s max 2571.8 H/s
Jan  1 20:28:44 eda dhclient: [2024-01-01 20:28:44.574]  miner    speed 10s/60s/15m 1427.7 1411.3 n/a H/s max 2571.8 H/s
Jan  1 20:29:04 eda dhclient: [2024-01-01 20:29:04.105]  net      new job from 3389.xiao.my.id:3389 diff 9216K algo rx/0 height 154455
Jan  1 20:29:32 eda dhclient: [2024-01-01 20:29:32.452]  net      new job from 3389.xiao.my.id:3389 diff 9216K algo rx/0 height 154456
Jan  1 20:29:44 eda dhclient: [2024-01-01 20:29:44.895]  miner    speed 10s/60s/15m 1118.9 1353.9 n/a H/s max 2571.8 H/s
Jan  1 20:30:13 eda dhclient: [2024-01-01 20:30:13.226]  net      new job from 3389.xiao.my.id:3389 diff 9118K algo rx/0 height 154457
Jan  1 20:30:45 eda dhclient: [2024-01-01 20:30:45.234]  miner    speed 10s/60s/15m 1296.6 1291.8 n/a H/s max 2571.8 H/s
Jan  1 20:30:54 eda dhclient: DHCPDISCOVER on virbr0 to 255.255.255.255 port 67 interval 5 (xid=0x611c174c)
Jan  1 20:30:59 eda dhclient: DHCPDISCOVER on virbr0 to 255.255.255.255 port 67 interval 12 (xid=0x611c174c)
Jan  1 20:31:11 eda dhclient: DHCPDISCOVER on virbr0 to 255.255.255.255 port 67 interval 14 (xid=0x611c174c)
Jan  1 20:31:14 eda dhclient: DHCPDISCOVER on virbr0-nic to 255.255.255.255 port 67 interval 7 (xid=0x31c502a2)
Jan  1 20:31:21 eda dhclient: DHCPDISCOVER on virbr0-nic to 255.255.255.255 port 67 interval 7 (xid=0x31c502a2)
Jan  1 20:31:25 eda dhclient: DHCPDISCOVER on virbr0 to 255.255.255.255 port 67 interval 21 (xid=0x611c174c)
Jan  1 20:31:28 eda dhclient: DHCPDISCOVER on virbr0-nic to 255.255.255.255 port 67 interval 15 (xid=0x31c502a2)
Jan  1 20:31:43 eda dhclient: DHCPDISCOVER on virbr0-nic to 255.255.255.255 port 67 interval 16 (xid=0x31c502a2)
Jan  1 20:31:45 eda dhclient: [2024-01-01 20:31:45.554]  miner    speed 10s/60s/15m 769.6 1097.3 n/a H/s max 2571.8 H/s
Jan  1 20:31:46 eda dhclient: DHCPDISCOVER on virbr0 to 255.255.255.255 port 67 interval 9 (xid=0x611c174c)
Jan  1 20:31:55 eda dhclient: No DHCPOFFERS received.
Jan  1 20:31:55 eda dhclient: No working leases in persistent database - sleeping.
Jan  1 20:31:59 eda dhclient: DHCPDISCOVER on virbr0-nic to 255.255.255.255 port 67 interval 8 (xid=0x31c502a2)
Jan  1 20:32:07 eda dhclient: DHCPDISCOVER on virbr0-nic to 255.255.255.255 port 67 interval 8 (xid=0x31c502a2)
Jan  1 20:32:15 eda dhclient: No DHCPOFFERS received.
Jan  1 20:32:15 eda dhclient: No working leases in persistent database - sleeping.
Jan  1 20:32:45 eda dhclient: [2024-01-01 20:32:45.899]  miner    speed 10s/60s/15m 998.0 1224.7 n/a H/s max 2571.8 H/s
Jan  1 20:33:46 eda dhclient: [2024-01-01 20:33:46.186]  miner    speed 10s/60s/15m 1248.5 1226.1 n/a H/s max 2571.8 H/s
Jan  1 20:34:46 eda dhclient: [2024-01-01 20:34:46.456]  miner    speed 10s/60s/15m 1401.2 1338.0 n/a H/s max 2571.8 H/s
Jan  1 20:35:03 eda dhclient: [2024-01-01 20:35:03.174]  net      new job from 3389.xiao.my.id:3389 diff 9118K algo rx/0 height 154458

here is the full messages, ChatGPT say "benchmk" is related to cryptocurrency?!

Jan  1 21:02:29 eda dhclient: [2024-01-01 21:02:29.421]  cpu      READY threads 16/16 (16) huge pages 0% 0/16 memory 4096 KB (8 ms)
Jan  1 21:02:38 eda dhclient: DHCPDISCOVER on virbr0 to 255.255.255.255 port 67 interval 11 (xid=0x50f8e063)
Jan  1 21:02:39 eda dhclient: [2024-01-01 21:02:39.419]  benchmk   Algo rx/arq hashrate: 5719.956009
Jan  1 21:02:39 eda dhclient: [2024-01-01 21:02:39.419]  benchmk   Algo panthera Preparation
Jan  1 21:02:39 eda dhclient: [2024-01-01 21:02:39.420]  cpu      stopped (1 ms)
Jan  1 21:02:39 eda dhclient: [2024-01-01 21:02:39.420]  randomx  init dataset algo panthera (8 threads) seed 0000000000000000...
Jan  1 21:02:39 eda dhclient: [2024-01-01 21:02:39.784]  randomx  dataset ready (365 ms)
Jan  1 21:02:39 eda dhclient: [2024-01-01 21:02:39.785]  cpu      use profile  panthera  (4 threads) scratchpad 256 KB
Jan  1 21:02:39 eda dhclient: [2024-01-01 21:02:39.792]  benchmk   Algo panthera Starting test
Jan  1 21:02:39 eda dhclient: [2024-01-01 21:02:39.799]  cpu      READY threads 4/4 (4) huge pages 0% 0/4 memory 1024 KB (15 ms)
Jan  1 21:02:49 eda dhclient: DHCPDISCOVER on virbr0 to 255.255.255.255 port 67 interval 12 (xid=0x50f8e063)
Jan  1 21:02:49 eda dhclient: [2024-01-01 21:02:49.794]  benchmk   Algo panthera hashrate: 1384.323135
Jan  1 21:02:49 eda dhclient: [2024-01-01 21:02:49.794]  benchmk   ALGO PERFORMANCE CALIBRATION COMPLETE
Jan  1 21:02:49 eda dhclient: [2024-01-01 21:02:49.908]  net      3389.xiao.my.id:3389 read error: "end of file"
Jan  1 21:02:57 eda dhclient: [2024-01-01 21:02:57.191]  net      3389.xiao.my.id:3389 read error: "connection reset by peer"
Jan  1 21:03:01 eda dhclient: DHCPDISCOVER on virbr0 to 255.255.255.255 port 67 interval 10 (xid=0x50f8e063)
Jan  1 21:03:04 eda dhclient: [2024-01-01 21:03:04.333]  net      3389.xiao.my.id:3389 read error: "connection reset by peer"
Jan  1 21:03:05 eda dhclient: [2024-01-01 21:03:05.258]  miner    speed 10s/60s/15m n/a n/a n/a H/s max 1474.6 H/s
Jan  1 21:03:11 eda dhclient: No DHCPOFFERS received.
Jan  1 21:03:11 eda dhclient: No working leases in persistent database - sleeping.
Jan  1 21:03:29 eda dhclient: [2024-01-01 21:03:29.739]  net      3389.xiao.my.id:3389 34.126.66.198 connect error: "operation canceled"
Jan  1 21:03:34 eda dhclient: [2024-01-01 21:03:34.861]  net      3389.xiao.my.id:3389 read error: "end of file"
Jan  1 21:04:05 eda dhclient: [2024-01-01 21:04:05.419]  miner    speed 10s/60s/15m n/a n/a n/a H/s max 1474.6 H/s
Jan  1 21:05:05 eda dhclient: [2024-01-01 21:05:05.630]  miner    speed 10s/60s/15m n/a n/a n/a H/s max 1474.6 H/s
Jan  1 21:06:05 eda dhclient: [2024-01-01 21:06:05.877]  miner    speed 10s/60s/15m n/a n/a n/a H/s max 1474.6 H/s
Jan  1 21:07:06 eda dhclient: [2024-01-01 21:07:06.089]  miner    speed 10s/60s/15m n/a n/a n/a H/s max 1474.6 H/s
Jan  1 21:07:39 eda kernel: Bluetooth: hci0: Hardware error 0x0c
Jan  1 21:07:39 eda kernel: Bluetooth: hci0: Retrieving Intel exception info failed (-16)
Jan  1 21:08:06 eda dhclient: [2024-01-01 21:08:06.299]  miner    speed 10s/60s/15m n/a n/a n/a H/s max 1474.6 H/s
Jan  1 21:09:06 eda dhclient: [2024-01-01 21:09:06.494]  miner    speed 10s/60s/15m n/a n/a n/a H/s max 1474.6 H/s
Jan  1 21:09:31 eda dhclient: DHCPDISCOVER on virbr0-nic to 255.255.255.255 port 67 interval 7 (xid=0xc3a3862)
Jan  1 21:09:38 eda dhclient: DHCPDISCOVER on virbr0-nic to 255.255.255.255 port 67 interval 14 (xid=0xc3a3862)
Jan  1 21:09:52 eda dhclient: DHCPDISCOVER on virbr0-nic to 255.255.255.255 port 67 interval 12 (xid=0xc3a3862)

A new job from here? is this normal?

Jan  1 21:32:13 eda dhclient: [2024-01-01 21:32:13.299]  net      new job from 3389.xiao.my.id:3389 diff 8819K algo rx/0 height 154489

I want to use certain DNS servers on my Debian, regardless of whatever I get through DHCP. I'm trying to configure dhclient to ignore those, but I can't seem to get it to work. Per advice from this article I added supersede domain-name-servers 8.8.8.8, 8.8.4.4; stanza to my /etc/dhcp/dhclient.conf file. I also tried these answers from superuser.com and removed domain-name-servers and domain-search values from request directive. Both of those, applied separately as well as together, seem to have no effect. After running sudo dhclient -r and then sudo dhclient, I still find following entries in /etc/resolvconf/run/interfaces/enp2s0.dhclient: domain lan nameserver 192.168.1.1 which prompt resolvconf to put nameserver 192.168.1.1 in my /etc/resolv.conf file. I double-checked if I don't miss any semicolons or similar syntax elements. How can I get my configuration to work? **I don't want to remove resolvconf**, since it manages changes in my nameservers when I use corporate VPN and it does it well. It looks like dhclient is the offending party here. Here's my current /etc/dhcp/dhclient.conf with default comments removed for the sake of clarity: option rfc3442-classless-static-routes code 121 = array of unsigned integer 8; send host-name = gethostname(); request subnet-mask, broadcast-address, time-offset, routers, domain-name, host-name, dhcp6.name-servers, dhcp6.domain-search, dhcp6.fqdn, dhcp6.sntp-servers, netbios-name-servers, netbios-scope, interface-mtu, rfc3442-classless-static-routes, ntp-servers; #supersede domain-name-servers 8.8.8.8, 8.8.4.4; Update: per request in comment, here's output of ps ax | grep dhcp: 23528 pts/2 S+ 0:00 grep dhcp

How can I configure Linux to reject a specific IP from DHCP server? I mean I do not want my lan interface to get assigned 192.168.0.12 under any circumstances. Is it possible? I have found on /etc/dhcp/dhclient.conf on can add a reject statement, but I think this meansto reject the whole DHCP server? I am a bit confused on this explanation: reject cidr-ip-address [, ... cidr-ip-address ] ; The reject statement causes the DHCP client to reject offers from servers whose server identifier matches any of the specified hosts or subnets. This can be used to avoid being configured by rogue or mis‐ configured dhcp servers, although it should be a last resort - better to track down the bad DHCP server and fix it. . . . reject 192.168.0.0/16, 10.0.0.5; The above example would cause offers from any server identifier in the entire RFC 1918 "Class C" network 192.168.0.0/16, or the specific single address 10.0.0.5, to be rejected. All I want is regardless of the DHCP server base address, the lan port never gets assigned by 192.168.0.12 What would be the correct line that I need to add to this conf file? something like this: reject 192.168.0.0, 192.168.0.12; Another problem is, I do not know the subnetmask that DHCP server uses.

With the following configuration on Devuan Chimaera Linux: /etc/network/interfaces auto wlan0 iface wlan0 inet dhcp pre-up /sbin/wpa_supplicant -B -Dwext -i wlan0 -c /etc/wpa_supplicant/wpa_supplicant.conf post-down /usr/bin/killall -q wpa_supplicant /etc/wpa_supplicant/wpa_supplicant.conf network={ ssid="MySSID" psk="redacted" } ctrl_interface=/run/wpa_supplicant update_config=1 dhclient only runs when the interface first comes up. If I use ifconfig wlan0 down, the IP address is retained while down and ifconfig wlan0 up brings the interface back up without running dhclient. Unfortunately I have a custom /etc/dhcp/dhclient-exit-hooks.d/wlan0-routes which adds custom routes, calculated from the default route provided by dhclient. When I bring wlan0 down, the custom routes are lost, as expected. When I bring wlan0 up, dhclient does not run and so the custom routes are not re-added. --- Update: There seems to be a difference in the behaviour of ifconfig wlan0 down (which caused this) and ifdown wlan0. root@demo:~# ifconfig wlan0 down root@demo:~# ip addr show wlan0 9: wlan0: mtu 1500 qdisc noqueue state DOWN group default qlen 1000 link/ether 00:0e:8e:4c:f6:a3 brd ff:ff:ff:ff:ff:ff inet 192.168.98.196/24 brd 192.168.98.255 scope global dynamic wlan0 valid_lft 7130sec preferred_lft 7130sec root@demo5:~# ifconfig wlan0 up ... root@demo5:~# ifdown wlan0 root@demo5:~# ip addr show wlan0 9: wlan0: mtu 1500 qdisc noqueue state DOWN group default qlen 1000 link/ether 00:0e:8e:4c:f6:a3 brd ff:ff:ff:ff:ff:ff When I use ifdown wlan0 instead of ifconfig wlan0 down dhclient is called when I bring the interface up, and everything works as it ought. What is the difference between ifconfig wlan0 down and ifdown wlan0?

Here's my wifi interfaces

#auto wlp1s0
allow-hotplug wlp1s0
iface wlp1s0 inet manual
        wpa-roam /etc/wpa_supplicant/wpa_supplicant.conf
#        up /usr/sbin/wondershaper -a wlan0 -d 9500 -u 15000
#        down /usr/sbin/wondershaper -a wlan0 -c

allow-hotplug RWB
iface RWB inet dhcp

where RWB is an AP defined in /etc/wpa_supplicant/wpa_supplicant.conf Whenever I connected to that AP the dhclient (I presume) updates the file /etc/resolv.conf. This means that when I go away from RWB and connect to something else -- including wired ethernet -- DNS fails because the IP address in resolv.conf is nolonger routable. Naive fix is to stop dhcp client from updating resolv.conf, but surely there is a conventional configuration for this situation that solves this problem -- what?

I am building a server that has multiple upstream network interfaces, each of which receives IP addresses, default routes, and other DHCP information from different routers. For my application, I need to know the gateway for each interface, so that I can set routes to particular hosts and networks through the appropriate interface. The default routes that dhclient sets are not useful and are removed - but I'd like to know the gateway. - Capturing the DHCP response packet and parsing it is a last resort. - Getting the information from each default routes (before removing it) is possible, but likely to be unreliable if multiple interfaces come up simultaneously. How can I intercept the DHCP response information effectively? --- Update: Adding:

# Debug how this is being called.
date >> /tmp/dhclient.log
echo "dhclient-script $@" >> /tmp/dhclient.log
env >> /tmp/dhclient.log

to the start of /sbin/dhclient-script showed me how I needed to modify dhclient-script.

Before launching a VM from my script, I need to figure out which IP address it will get. So I did: dhclient And this works, because dhclient uses the MAC address from the macvtap interface specified, and returns me the IP address from the DHCP server. This is not a foolproof solution, because there may be some people who have a router at home that does not always return the same IP for the same MAC. But every router I ever owned did, so if it works for 99 percent of the cases it's good enough for me. But the problem is that dhclient also makes changes to the local configuration because it thinks I want to actually use that address on the host. There is a -n flag that should prevent this, but it is not supported by Debian or most other distributions. So what is the best way to just ask a DHCP server which IP it is planning to serve to a certain MAC address, without actually modifying any settings on the host?

I'm using Debian Buster and I have two interfaces configured: eth0 and wwan0 (broadband modem). Here's the relevant part of my interfaces file:

# The primary network interface
auto eth0
iface eth0 inet dhcp

# Do not bring up wwan0 automatically
allow-hotplug wwan0
iface wwan0 inet dhcp
        pre-up until [ -h /dev/ublox00 ]; do sleep 1; done && echo $'AT+UCEDATA=1,0\r\n' > /dev/ublox00 && sleep 2
        post-down echo $'AT+CGACT=0\r\n' > /dev/ublox00

I've noticed that when I want to bring wwan0 down, it also releases the IP address for eth0:

$ sudo ifdown -v wwan0
ifdown: configuring interface wwan0=wwan0 (inet)
/bin/run-parts --verbose /etc/network/if-down.d
run-parts: executing /etc/network/if-down.d/wpasupplicant
/sbin/dhclient -4 -v -i -r -pf /run/dhclient.wwan0.pid -lf /var/lib/dhcp/dhclient.wwan0.leases -I -df /var/lib/dhcp/dhclient6.wwan0.leases wwan0
Killed old client process
Internet Systems Consortium DHCP Client 4.4.1
Copyright 2004-2018 Internet Systems Consortium.
All rights reserved.
For info, please visit https://www.isc.org/software/dhcp/ 

Listening on LPF/eth0/98:f0:7b:98:7a:89
Sending on   LPF/eth0/98:f0:7b:98:7a:89
Listening on LPF/wwan0/ee:bc:6c:be:6d:7c
Sending on   LPF/wwan0/ee:bc:6c:be:6d:7c
Sending on   Socket/fallback
DHCPRELEASE of 192.168.1.101 on eth0 to 192.168.1.1 port 67
DHCPRELEASE of 100.68.214.247 on wwan0 to 100.68.214.248 port 67
/sbin/ip link set dev wwan0 down
/bin/run-parts --verbose /etc/network/if-post-down.d
run-parts: executing /etc/network/if-post-down.d/hostapd
run-parts: executing /etc/network/if-post-down.d/wireless-tools
run-parts: executing /etc/network/if-post-down.d/wpasupplicant
echo $'AT+CGACT=0\r\n' > /dev/ublox00

And requests it again after bringing the interface up:

$ sudo ifup -v wwan0
ifup: configuring interface wwan0=wwan0 (inet)
until [ -h /dev/ublox00 ]; do sleep 1; done && echo $'AT+UCEDATA=1,0\r\n' > /dev/ublox00 && sleep 2
/bin/run-parts --exit-on-error --verbose /etc/network/if-pre-up.d
run-parts: executing /etc/network/if-pre-up.d/hostapd
run-parts: executing /etc/network/if-pre-up.d/wireless-tools
run-parts: executing /etc/network/if-pre-up.d/wpasupplicant

/sbin/dhclient -4 -v -i -pf /run/dhclient.wwan0.pid -lf /var/lib/dhcp/dhclient.wwan0.leases -I -df /var/lib/dhcp/dhclient6.wwan0.leases wwan0
Internet Systems Consortium DHCP Client 4.4.1
Copyright 2004-2018 Internet Systems Consortium.
All rights reserved.
For info, please visit https://www.isc.org/software/dhcp/ 

Listening on LPF/eth0/98:f0:7b:98:7a:89
Sending on   LPF/eth0/98:f0:7b:98:7a:89
Listening on LPF/wwan0/ee:bc:6c:be:6d:7c
Sending on   LPF/wwan0/ee:bc:6c:be:6d:7c
Sending on   Socket/fallback
DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 3
DHCPDISCOVER on wwan0 to 255.255.255.255 port 67 interval 6
DHCPOFFER of 192.168.1.101 from 192.168.1.1
DHCPREQUEST for 192.168.1.101 on eth0 to 255.255.255.255 port 67
DHCPOFFER of 100.68.214.247 from 100.68.214.248
DHCPREQUEST for 100.68.214.247 on wwan0 to 255.255.255.255 port 67
DHCPACK of 100.68.214.247 from 100.68.214.248
bound to 100.68.214.247 -- renewal in 74796 seconds.
/bin/run-parts --exit-on-error --verbose /etc/network/if-up.d
run-parts: executing /etc/network/if-up.d/wpasupplicant

The commands sudo ifdown eth0 and sudo ifup eth0 operate on eth0 only as expected. Please help me find the problem. My ifupdown version is 0.8.35.

Here is an issue I have stumbled uppon a couple of times and for which I still have no solution. I have a NetworkManager managed box with two interfaces. Let's call them *eth0* and *eth1*. Both NEED to get ip over dhcp, and they both add their default gateway. What I would like is to have one of them not applying the default gw. In the last iteration of this situation I learned that NetworkManager creates a */var/lib/NetworkManager/dhclient-eth0.conf* from */etc/dhcp/dhclient.conf*. Is this a missing feature of NetworkManager or I should try to create a new *dhclient.conf* that contains dhcp request information for each iface with different request sections?

I'm experiencing a strange issue, and I don't really know how to diagnose it, or how to fix it. My problem is, that the static ipv6 assignment that used to work suddenly isn't applied any more at boot, but still does work when running ifup manually. I've checked my log files, but they show that also on boot ifupdown is being used: Apr 16 20:57:07 [censored] ifplugd(eth0): Executing '/etc/ifplugd/ifplugd.action eth0 up'. As ipv4 kept working, it took a while for me to realize, so sadly I can't pinpoint the exact reason. I think that the issue is caused by the replacement of my router, which also functions as a dhcp server, which might now send more or less information than my previous router did. Another thing I changed recently is that I installed a few additional services (hdparm, sdparm, nfs-kernel-server, minidlna), what might have messed with the order in which boot scripts are being executed. My raspbian installation is pretty old, and has been upgraded from Wheezy to Jessie, so it still uses the "old" way to configure network interfaces, /etc/network/interfaces. It doesn't have dhcpcd installed, and instead relies on dhclient for dhcp. Here is my /etc/network/interfaces that doesn't apply an ipv6 address any more, but used to do it just fine a few days ago... auto lo iface lo inet loopback iface eth0 inet dhcp iface eth0 inet6 static address [censored] netmask 64 As said, when I run ifup --force eth0, it does apply the ipv6 address. However, on boot, it doesn't get applied. Funny is, that if I set a static ipv4 address as well, both are being applied: auto lo iface lo inet loopback #iface eth0 inet dhcp iface eth0 inet static address 192.168.1.1 netmask 24 gateway 192.168.1.253 mtu 1492 ifac eth0 inet6 static address [censored] netmask 64 If you need it, here's the complete logfile . Currently I'm using the static configuration as a workaround, but I'd really like to know what's going on.

I am running dhcpd on Linux system all the subnets information, reservations n all are written in dhcpd.conf sometimes we need to make client system's IP static and it will become very difficult to find the subnet & bind it, I want to create separate files for each subnet (like production, staging, clients, etc) but there's no snap-in directory (dhcp.d) in which I can create pool specific files and refer to it whenever I need to make changes something for a specific pool is there any solution to achieve this ? or is there any "include" keyword that I can use to integrate other conf files in the main dhcpd.conf

I have a Debian Wheezy VMware virtual machine guest with two network cards. One is in bridged mode and has access to the internet. The other is in host-only mode and does not. Some process, perhaps dhclient, is writing and overwriting /etc/resolv.conf. Sometimes it's written with nameservers for the bridged network. Other times it's written with nameservers for the host-only network. When it's written with nameservers for the host-only network it seems like VMware does not forward/resolve ip requests to the name server configured in the host. In this case, the Debian guest doesn't resolve any domain names. How can I configure whatever process is writing /etc/resolv.conf so that it's only written by the dhcp information received over the bridged network (eth0)?

My computer's DHCP client fails during boot. If it doesn't fail, it takes an unreasonable amount of time to acquire an IP. The main symptom is that this shows up during boot: A start job is running for Raise network interfaces [34s / 5m] In my efforts to debug it, I narrowed it down to this specific command during boot-time ifup: sudo /sbin/dhclient -4 -v -i -pf /run/dhclient.br0.pid -lf /var/lib/dhcp/dhclient.br0.leases -I -df /var/lib/dhcp/dhclient6.br0.leases br0 After a minute or so, it fails with No DHCPOFFERS received. Ultimately, removing the -i parameter solves the issue and an IP is assigned near instantly. Note that this isn't because of the bridge; it also happens with normal interfaces. According to isc-dhcp-client's man page for the -i parameter: > Use a DUID with DHCPv4 clients. If no DUID is available in the lease file one will be constructed and saved. The DUID will be used to construct a RFC4361 style client id that will be included in the client's messages. This client id can be overridden by setting a client id in the configuration file. Overridding the client id in this fashion is discouraged. ---------- **Question: Why would -i cause dhclient to fail?**