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?
> I would like to get isc-dhcp-server up so I can configure my new
> UniFi toy. The server has two statically configured interfaces,
> eth0 and eth1.
>
> The server's dhcpd.conf contains:
>
> ddns-update-style none;
> log-facility local7;
> option domain-name "xx.pinyon.org";
> option domain-name-servers 10.0.10.5, 10.0.10.7;
> option routers 10.0.10.5;
> default-lease-time 600;
> max-lease-time 7200;
> authoritative;
Looks good.
> 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?
> 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.
> 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 *:*
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.
# 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
Attachment:
signature.asc
Description: Digital signature