Re: isc-dhcp-server not receiving DHCPDISCOVER
Greetings Bob,
On 12/05/2013 04:27 PM, Bob Proulx wrote:
> Russell L. Carter wrote:
>> I've got an internal net with several dual-homed jessie boxen.
>
> I see that you have 10.0.10.0/24 on one and 10.0.11.0/24 on the other. Is
> that correct? And you only want dhcpd to serve DHCP requests on the
> 10.0.10.0/24 network?
Correct.
[...]
>> subnet 10.0.11.0 netmask 255.255.255.0 {}
>
> Don't serve the 10.0.11.0/24 network. Which interface is which just for
> the discussion?
eth0
>> subnet 10.0.10.0 netmask 255.255.255.0 { pool { range 10.0.10.50
>> 10.0.10.100; } }
>
> Looks okay.
>
> Personally I always prefer to have the routers option configured in the
> subnet section. Because different subnets will have different routers and
> that makes it obvious and easy to set that way. I realize you only have
> the one and so the global definition should be fine. This is just looking
> to the future.
Right.
>> and I've set INTERFACES="eth0 eth1" in /etc/default/isc-dhcp-server.
>
> If you don't want dhcp to server DHCP requests to the 10.0.11.0/24 subnet
> then why have the interface listed? (Or if some other configuration is
> happening please say because the only thing that I can think of that makes
> sense is that you have one on one and one on the other but have disabled
> one of them.
>
>> isc-dhcp-server starts fine.
>
> You might want to verify:
>
> # netstat -na | grep :67 udp 0 0 0.0.0.0:67 0.0.0.0:*
>
> # netstat -a | grep :bootps udp 0 0 *:bootps *:*
Yup, I got that.
> Somewhat of a misfeature but the isc dhcpd (along with dnsmasq too) listens
> to all interfaces and simply ignores traffic not in the provided interface
> list. It would be better if it bound itself only to the interface IP
> address. Because binding to the wildcard address makes it impossible to
> run multiple daemons on the same machine. Which is often a collision when
> using VMs and dnsmasq for example.
>
>> I then listen for DHCP packets on the 10.0.10.0 net with
>>
>> $ dhcpdump -i eth0
>
> Looks good. I am sure you are also looking with tcpdump too? Just in case
> the packets are being seen but not as dhcp traffic for some reason?
>
>> On the test (jessie) client I have ifdown'd eth0 and execute
>>
>> $ dhclient -v eth0
>
> I am probably confused here but I always thought that the interface needed
> to be UP before you could run dhclient on it. And I always thought it
> needed root permission. Try both.
Ok, I need to do some experimenting here. I've broken out a long
patch cable to bypass the switch and am steeling myself for the
tcpdump learning experience. However, that's probably a big net plus
because I discovered that the stock wireshark is hanging for me after
a basic capture, even with all lookups turned off. grrr. Well I need
to diversify my tools evidently, even simplify.
Thanks Bob for the tips, the stuff below will keep me busy tomorrow
morning. I'll report back what I find.
Russell
> # ifconfig eth0 up # dhclient -v eth0
>
> But I worry about where DBDIR/dhclient.leases is defined to be by default?
> I don't know if you need to set it. This is the usual place on Debian for
> it.
>
> # dhclient -v -lf /var/lib/dhcp/dhclient.eth0.leases eth0
>
> Also you probably want to try the /etc/network/interfaces config and seeing
> if it is happier if it uses all of the defaults. I would start here. It
> is much easier than remembering all of the details manually.
>
> # ifdown eth0 ...edit /etc/network/interfaces...set up... iface eth0 inet
> dhcp ...save file... # ifup eth0
>
> Note that if the interface is up and you rearrange the file then ifdown
> won't match the up. They will be out of sync. This might leave a dhclient
> running in the background for example. You may have to clean things up.
> So normally you need to bring the interface down before making big changes
> to the file and then bringing it up afterward. But you are aware of the
> state such as whether dhclient is already running or not then you can
> carefully do it with it up too.
>
>> (I can bring up static eth0 on the client and ping the server fine)
>
> Good.
>
>> The problem is that no DHCP packet is received by the eth0 interface on
>> the server. As a first test I've ifdown'd the eth1 interface on the
>> server and tried running a dhclient and I DO see the DHCPDISCOVER
>> packets.
>
> On the client listen to the interfaces with tcpdump. Are the packets
> leaving it? Here are some possibly useful hints.
>
> # tcpdump -lni any # tcpdump -lni any not arp # tcpdump -lni any port
> bootps # tcpdump -lni eth0 not port ssh and not arp
>
>> Neither the server nor the client is running a firewall. iptables is not
>> even installed. For kicks I enabled /proc/sys/net/ipv4/ip_forward but
>> this had no effect. I've got a smart switch in the middle but I checked
>> and everything looks fine.
>
> I would install iptables so as to be able to dump the kernel netfilter
> rules and double check. Because something is blocking.
>
> # iptables -L
>
>> It looks to me that the client UDP broadcast is blocked from reaching the
>> server, but what could cause that?
>>
>> Any ideas much appreciated.
>
> dhcpdump is good but I would use tcpdump if just looking for the presence
> of packets. I would verify on the client that they are leaving down the
> interface. If they aren't making it to the interface then the server won't
> see them. If they are leaving the interface then they should be arriving
> at the server. If not then the switch in the middle is suspect. If you
> have auto-MDIX interfaces then you don't need a crossover cable and can
> avoid the switch with a direct connection between. (But that would seem to
> be unusual to have the switch blocking things.)
>
> The packets are either going some place, blocked from going, or not being
> generated. I don't know of any other possibilities. You will have to find
> them.
>
> Bob
>
Reply to: