0

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.

1 Answer 1

0

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)

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .