I want to understand under which circumstance this command is valid. As i can see, using this command the discover packets have unicast destination ip same as that of the provided server ip while the destination mac is broadcast. Is this a valid packet, as I am not able to get ip using this flag.
I think that receiving an answer with -s flag it depends on the listening dhcp server (or its configuration).
Short answer, it works with dhcpd server but it fails with dnsmasq one.
Long(er) answer, using "dhclient -v -s 172.16.0.1 eth1" will get an IP if the listening server is dhcpd:
[root@c602 ~]# dhclient -v -s 172.16.0.1 eth1 Internet Systems Consortium DHCP Client 4.1.1-P1 Copyright 2004-2010 Internet Systems Consortium. All rights reserved. For info, please visit https://www.isc.org/software/dhcp/ Listening on LPF/eth1/08:00:27:31:f2:d6 Sending on LPF/eth1/08:00:27:31:f2:d6 Sending on Socket/fallback DHCPDISCOVER on eth1 to 172.16.0.1 port 67 interval 7 (xid=0x6161a797) DHCPOFFER from 172.16.0.1 DHCPREQUEST on eth1 to 172.16.0.1 port 67 (xid=0x6161a797) DHCPACK from 172.16.0.1 (xid=0x6161a797) bound to 172.16.0.230 -- renewal in 19087 seconds. [root@c602 ~]# ip -4 a show dev eth1 3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000 inet 172.16.0.230/24 brd 172.16.0.255 scope global eth1
In both circumstances, when dhcpd or dnsmasq are the acting dhcp server, the DHCPDISCOVER is reaching the server but is not answered by dnsmasq; seen this with tcpdump on server machine. (tcpdump -nnnvvvi eth1 port 67 and port 68)