search

TechnitiumSoftware / DnsServer

Technitium DNS Server
https://technitium.com/dns/
GNU General Public License v3.0
4.46k stars 432 forks source link

Cannot enable DHCP server on Debian / raspberry pi #197

Closed valkenburg closed 3 years ago

valkenburg commented 3 years ago

It seems that the condition in this line in DnsServerCore/Dhcp/Scope.cs always evaluates to true, even though I tried all possible ways to convince the app that my ip is static (which it most certainly is).

Perhaps add a simple override option?

ShreyasZare commented 3 years ago

Thanks for the feedback. I am already running DHCP on raspberry pi here without any issues. Can you share more details on how can this issue be reproduced?

jbuitt commented 3 years ago

I'm having the same problem as valkenburg. I'm Running Raspbian 10 and have tried setting a static IP in /etc/dhcpcd.conf and in /etc/network/interfaces. I've also gone so far as to completely remove the dhcpcd5 package from my system, which in theory should guarantee that there's no possible way the NIC should receive an IP from DHCP, and therefore not have any DHCP servers available.

Despite all these different attempts however, ipInterface.DhcpServerAddresses.Count still evaluates to a number greater than 0, which prevents the DHCP server from starting. Having some kind of flag to override this value, or prevent the DHCP check on the interface would be great.

Thanks!

ShreyasZare commented 3 years ago

@jbuitt Thanks for the feedback. Can you share your dhcpcd.conf here or send it as email to support@technitium.com? This is since I need to be able to reproduce this issue before making any changes. I am too running Raspbian 10 (Buster) for my home network and DHCP server is working here.

The validation check can be removed to fix this but it will have other untended serious issues like if the machine really has a dynamic IP address then once it expires it will make the server unreachable and then you will need to setup and run another DHCP server on the network to gain access back to it. This unreachability issue wont be fixable by average user who is new to networking and would then require reinstalling the OS back to gain access.

jbuitt commented 3 years ago

Hi ShreyasZare,

Thanks for your response. All my /etc/dhcpcd.conf has is the following:

interface eth0
static ip_address=192.168.0.1/24
static routers=192.168.0.254
static domain_name_servers=127.0.0.1

Also, the output of ip addr shows the following:

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether xx:xx:xx:xx:xx:xx brd ff:ff:ff:ff:ff:ff
    inet 192.168.0.1/24 brd 192.168.0.255 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx/64 scope global dynamic mngtmpaddr
       valid_lft 86250sec preferred_lft 14250sec
    inet6 fe80::ba27:ebff:fef3:d3ad/64 scope link
       valid_lft forever preferred_lft forever
3: wlan0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state DOWN group default qlen 1000
    link/ether xx:xx:xx:xx:xx:xx brd ff:ff:ff:ff:ff:ff

I wondered if the software was thinking that the IPv6 was somehow obtained over DHCP (e.g. dynamic) but I completely disabled IPv6 and had the same problem.

Your explanation of the validation check removal makes sense. It's best to figure out why Raspberry Pi thinks it's using DHCP and fix that.

Awesome software BTW. Keep up the great work!

Thanks!

valkenburg commented 3 years ago

Thanks for looking into this! My /etc/dhcpcd.conf:

hostname myhost
clientid
persistent
option rapid_commit
option domain_name_servers, domain_name, domain_search, host_name
option classless_static_routes
option ntp_servers
option interface_mtu
require dhcp_server_identifier
slaac private
interface eth0
static ip_address=192.168.1.17/24
static routers=192.168.1.2
static domain_name_servers=9.9.9.9
profile static_eth0
static ip_address=192.168.1.17/24
static routers=192.168.1.2
static domain_name_servers=9.9.9.9
fallback static_eth0
jbuitt commented 3 years ago

I had an extra Raspberry Pi to play around with and flashed a brand new copy of Raspbian (2020-12-02 Lite) and then installed Technitium. I then copied over my settings in the /etc/dns/ directory and wouldn't you know, the DHCP server started up just fine. So that proves there must be something strange about the original Raspberry Pi. I'm going to move the other services I have on the old Raspberry Pi to this new one and see if anything breaks. I'll keep the old one around in case you need me to run some commands or pull other configs to help narrow down the root cause.

ShreyasZare commented 3 years ago

@jbuitt thanks for the details. Does the other Pi that has DHCP working also has IPv6 address assigned via DHCPv6? It could be that the DHCP check condition is also counting IPv6 DHCP server.

@valkenburg thanks for the config. Does your setup too has ipv6 address configured via DHCPv6?

Both of your dhcpcd.conf looks good. I got exactly same config on my Pi too.

jbuitt commented 3 years ago

Yes, the new Pi where the DHCP server is working does have an IPv6 address assigned, so that doesn't seem to be the issue.

ShreyasZare commented 3 years ago

May be you may have tried this but have to ask if both of you have tried the same with a reboot? Sometimes things are fixed with a simple reboot.

jbuitt commented 3 years ago

Fair question, but yes I have rebooted the Pi several times and the problem remains.

jbuitt commented 3 years ago

I found my issue on the old Pi. Prior to installing Technitium, I had been running the ISC DHCP server and client. Once I removed those packages and ran service dns restart, the DHCP server started up successfully. Seems like there may have been some kind of conflict with running another DHCP server.

ShreyasZare commented 3 years ago

I found my issue on the old Pi. Prior to installing Technitium, I had been running the ISC DHCP server and client. Once I removed those packages and ran service dns restart, the DHCP server started up successfully. Seems like there may have been some kind of conflict with running another DHCP server.

There will definitely conflict if you already have another DHCP server running. Good to know that you could get it to work on the old Pi.

jbuitt commented 3 years ago

The odd part was that I thought I had completely disabled the ISC DHCP server & client, I confirmed neither were not running. There must have been something about having the packages installed that made the system think that it was connected with DHCP.

Can valkenberg confirm if they have a similar set up? Perhaps they have an existing DHCP server or client program installed?

valkenburg commented 3 years ago

I cannot confirm this right now anymore, as I moved to another dns server with dhcp (sorry to say). I did confirm that no other dhcp server was running, but after the fact this is quite useless since I cannot re-confirm now anymore. But I'm quite sure that the config files were still around.

ShreyasZare commented 3 years ago

I cannot confirm this right now anymore, as I moved to another dns server with dhcp (sorry to say). I did confirm that no other dhcp server was running, but after the fact this is quite useless since I cannot re-confirm now anymore. But I'm quite sure that the config files were still around.

thanks for the response.

ShreyasZare commented 3 years ago

New update now checks for ipv4 specific DHCP and provides more info in the error log that gets displayed to help fix the config of the machine.

jbuitt commented 3 years ago

Thank you!

Zorlin commented 2 years ago

Hi there,

I'm freshly hitting a bug like this on the latest Technitium (Version 8.0.2 as of this writing):

[2022-04-21 17:38:30 UTC] DHCP Server failed to activate scope: Homeprod
DnsServerCore.Dhcp.DhcpServerException: DHCP Server requires static IP address to work correctly but the network interface was found to have a dynamic IP address [10.1.2.1] assigned by another DHCP server: 10.1.1.1
   at DnsServerCore.Dhcp.Scope.FindInterface() in Z:\Technitium\Projects\DnsServer\DnsServerCore\Dhcp\Scope.cs:line 513
   at DnsServerCore.Dhcp.DhcpServer.ActivateScopeAsync(Scope scope, Boolean waitForInterface) in Z:\Technitium\Projects\DnsServer\DnsServerCore\Dhcp\DhcpServer.cs:line 991
[2022-04-21 17:38:30 UTC] [10.1.1.11:54061] DnsServerCore.DnsWebServiceException: Failed to enable DHCP scope, please check logs for details: Homeprod
   at DnsServerCore.WebServiceDhcpApi.EnableDhcpScopeAsync(HttpListenerRequest request) in Z:\Technitium\Projects\DnsServer\DnsServerCore\WebServiceDhcpApi.cs:line 663
   at DnsServerCore.DnsWebService.ProcessRequestAsync(HttpListenerRequest request, HttpListenerResponse response) in Z:\Technitium\Projects\DnsServer\DnsServerCore\DnsWebService.cs:line 827

Specifically, I'm trying to enable DHCP for the subnet 10.1.0.0/16, and a range of 10.1.1.2 thru 10.1.1.254.

I've triple-checked that I'm using a static IP, and even turned off ipv6 in the pursuit of fixing it. Eventually I found that changing to a subnet mask of 10.1.1.0/24 "worked", in that I could successfully enable it in the GUI, but that would mean giving out an incorrect subnet mask to my DHCP clients and thus I was unable to leave that in that state. Any help is appreciated :)

I've moved to ISC Kea for DHCP for now, but would love to revisit this at some point and am happy to debug in temporary short bursts.

ShreyasZare commented 2 years ago

Specifically, I'm trying to enable DHCP for the subnet 10.1.0.0/16, and a range of 10.1.1.2 thru 10.1.1.254.

I've triple-checked that I'm using a static IP, and even turned off ipv6 in the pursuit of fixing it. Eventually I found that changing to a subnet mask of 10.1.1.0/24 "worked", in that I could successfully enable it in the GUI, but that would mean giving out an incorrect subnet mask to my DHCP clients and thus I was unable to leave that in that state. Any help is appreciated :)

Thanks for the details. I configured the DHCP scope on an Ubuntu server VM with the same network range and its working well. See the screenshot below:

image

Can you post details on all of the network interfaces on your system with their IP config? The error that you see is here in code. The method try to find an interface which matches the scope range and when such an interface is found, it checks if the interface has any DHCP server ipv4 address set which tells that the IP was dynamically assigned.

Zorlin commented 2 years ago

ip a dump: 

wings@dns01:~$ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
2: ens18: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether fe:25:3e:29:78:79 brd ff:ff:ff:ff:ff:ff
    altname enp0s18
    inet 10.1.2.1/16 brd 10.1.255.255 scope global ens18
       valid_lft forever preferred_lft forever

Network interfaces:

wings@dns01:~$ ls /etc/network/interfaces.d/
wings@dns01:~$ cat /etc/network/interfaces
# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

source /etc/network/interfaces.d/*

# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
auto ens18
iface ens18 inet static
    address 10.1.2.1/16
    gateway 10.1.1.1
iface ens18 inet6 static
# This is an autoconfigured IPv6 interface
#iface ens18 inet6 auto
ShreyasZare commented 2 years ago

That's strange actually. The DNS server code is getting DHCP server ipv4 address from the call so it thinks its dynamic. It could be some unrelated/strange issue. Have you tried rebooting once just in case to see if this goes away?

Zorlin commented 2 years ago

Yep, tried a bunch of reboots and totally disabling ipv6 in case it was related, no dice :(

ShreyasZare commented 2 years ago

Yep, tried a bunch of reboots and totally disabling ipv6 in case it was related, no dice :(

This might sound strange, but try configuring a different static IP like 192.168.0.0/16, apply the changes and reconfigure it back to the current static IP. This might clear some values which dotnet runtime is probably reading. Just add an additional IP to your laptop's interface in the same range to help after switching the first time if you are on ssh and not on console.

Zorlin commented 2 years ago

Yep, using a VM in Proxmox, so should be fine to console in without network :) I'll give it a shot soon. Thanks!

Zorlin commented 2 years ago

Tried that, no dice. It's still thoroughly convinced I'm using a DHCP IP :(

I'm installing an Ubuntu 22.04 test machine now to see if it behaves better.

Zorlin commented 2 years ago

Ubuntu 22.04 worked out of the box, so it appears to be an issue with that specific configuration and Debian 11.

If it helps, I noticed "interface" was blank on the Debian box in Technitium.

ShreyasZare commented 2 years ago

Ubuntu 22.04 worked out of the box, so it appears to be an issue with that specific configuration and Debian 11.

If it helps, I noticed "interface" was blank on the Debian box in Technitium.

Thanks for the feedback. Good to know you got it working on another setup.

Zorlin commented 2 years ago

No worries, I'm very happily now a "production user" of Technitium, with a massive human userbase of... two people. But it's working and running my home lab and apartment nicely. :) Thanks.

besynnerlig commented 2 years ago

FWIW, I just created a new Proxmox Technitium DNS LXC (debian) (using a script from this page ) and stumbled upon this same error. The DHCP scope just wouldn't activate even though I had set a fixed IP (but not initially, I changed that at a later point). However I solved it by installing a new Proxmox Technitium DNS LXC but this time I configured the container at start (not afterwards) to use a fixed IP and now it works. So my conclusion is that it doesn't help to change from DHCP to fixed afterwards. My LXC container runs debian. Seems to work great now.

ShreyasZare commented 2 years ago

FWIW, I just created a new Proxmox Technitium DNS LXC (debian) (using a script from this page ) and stumbled upon this same error. The DHCP scope just wouldn't activate even though I had set a fixed IP (but not initially, I changed that at a later point). However I solved it by installing a new Proxmox Technitium DNS LXC but this time I configured the container at start (not afterwards) to use a fixed IP and now it works. So my conclusion is that it doesn't help to change from DHCP to fixed afterwards. My LXC container runs debian. Seems to work great now.

It seems to be some issue with the dotnet runtime which keeps reading the old DHCP server info for some reason for debian. Haven't seen it on Ubuntu or Raspbian that I usually deploy.

drhaywardj commented 2 years ago

Just had the same issue with Debian 11. I found that there was a file hanging around from the old dhcp lease (/var/lib/dhcp/dhclient.ens18.lease, in my case). Deleted the file and rebooted. After that I was able to Enable the scope.

ShreyasZare commented 2 years ago

Just had the same issue with Debian 11. I found that there was a file hanging around from the old dhcp lease (/var/lib/dhcp/dhclient.ens18.lease, in my case). Deleted the file and rebooted. After that I was able to Enable the scope.

That's great! Thanks for posting here.

Zorlin commented 2 years ago

It's a VM running in Proxmox, so I've got a vnc console. I'll give it a try soon and report back. You're meaning edit /etc/network/interfaces to a 192.168.x.x address (different subnet), reboot, edit back, reboot?

Cheers

On Sun, 24 Apr 2022, 7:21 pm Shreyas Zare, @.***> wrote:

Yep, tried a bunch of reboots and totally disabling ipv6 in case it was related, no dice :(

This might sound strange, but try configuring a different static IP like 192.168.0.0/16, apply the changes and reconfigure it back to the current static IP. This might clear some values which dotnet runtime is probably reading. Just add an additional IP to your laptop's interface in the same range to help after switching the first time if you are on ssh and not on console.

— Reply to this email directly, view it on GitHub https://github.com/TechnitiumSoftware/DnsServer/issues/197#issuecomment-1107820350, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAKONLACD2MEL37VEODPSHDVGUVC5ANCNFSM4UA63EPQ . You are receiving this because you commented.Message ID: @.***>

ShreyasZare commented 2 years ago

It's a VM running in Proxmox, so I've got a vnc console. I'll give it a try soon and report back. You're meaning edit /etc/network/interfaces to a 192.168.x.x address (different subnet), reboot, edit back, reboot? Cheers

Just try what @drhaywardj posted earlier:

Just had the same issue with Debian 11. I found that there was a file hanging around from the old dhcp lease (/var/lib/dhcp/dhclient.ens18.lease, in my case). Deleted the file and rebooted. After that I was able to Enable the scope.