DHCP breaking something in my networking.

When enabling pi-holes DHCP, after leases expired it seems to have broken my minecraft server and the linux vm I run on my phone.

Expected Behaviour:

After pi-hole takes over leases from my routers dhcp I expect networking in all areas to continue running smoothly. Please include as much detail relevant to your system/install as possible including, but not limited to: (Obligatory neofetch)

root@sylph:/etc/dhcp# neofetch --off
root@sylph.home
---------------
OS: Debian GNU/Linux 12 (bookworm) aarch64
Host: Raspberry Pi 5 Model B Rev 1.0
Kernel: 6.6.74+rpt-rpi-2712
Uptime: 18 days, 1 hour, 28 mins
Packages: 1905 (dpkg)
Shell: bash 5.2.15
Resolution: 1920x1080
CPU: (4) @ 2.400GHz
Memory: 580MiB / 8048MiB

Actual Behaviour:

After my dhcp leases were taken over by pi-hole everything works as anticipated except for my minecraft server which runs on a physical host called Ataribox, and the shell I run on my iphone called ishell can no longer do package updates, but has no problem doing anything else.

On Ataribox, here is some necessary information:

[root@ataribox ~]# neofetch --off
root@ataribox
-------------
OS: Rocky Linux 9.5 (Blue Onyx) x86_64
Host: HP EliteDesk 800 G2 DM 35W
Kernel: 5.14.0-503.35.1.el9_5.x86_64
Uptime: 6 days, 23 hours, 9 mins
Packages: 978 (rpm)
Shell: bash 5.1.8
Resolution: 1920x1080
CPU: Intel i5-6500T (4) @ 3.100GHz
GPU: Intel HD Graphics 530
Memory: 6350MiB / 7565MiB
[root@ataribox ~]# cat /etc/resolv.conf
# Generated by NetworkManager
search lan
nameserver 192.168.1.59 (this is my pi-hole)
nameserver 2605:a601:800c:2200:c641:1eff:fe88:652e (this is my pi-hole)

Minecraft Errors from ataribox

These errors were not present when the pi-hole was only doing dns. After it picked up on dhcp is where this became a problem. Just to be clear for anyone wondering, there isn't and has never been an instance where two dhcp servers are running at the same time. It seems the server can no longer do anything related to networking at all. Normally, I wouldn't care. But because it can't check in with microsofts authentication servers, nobody can join when the server is in online mode. When it tries to do anything to do with networking this is the error I get:

[12:03:34] [Forge Version Check/WARN] [ne.mi.fm.VersionChecker/]: Failed to process update information
java.net.http.HttpConnectTimeoutException: HTTP connect timed out
        at jdk.internal.net.http.HttpClientImpl.send(HttpClientImpl.java:945) ~[java.net.http:?] {}
        at jdk.internal.net.http.HttpClientFacade.send(HttpClientFacade.java:133) ~[java.net.http:?] {}
        at net.minecraftforge.fml.VersionChecker$1.openUrlString(VersionChecker.java:139) ~[fmlcore-1.20.1-47.3.6.jar%23632!/:?] {}
        at net.minecraftforge.fml.VersionChecker$1.process(VersionChecker.java:177) ~[fmlcore-1.20.1-47.3.6.jar%23632!/:?] {}
        at java.lang.Iterable.forEach(Iterable.java:75) ~[?:?] {re:mixin}
        at net.minecraftforge.fml.VersionChecker$1.run(VersionChecker.java:114) ~[fmlcore-1.20.1-47.3.6.jar%23632!/:?] {}
Caused by: java.net.http.HttpConnectTimeoutException: HTTP connect timed out
        at jdk.internal.net.http.ResponseTimerEvent.handle(ResponseTimerEvent.java:68) ~[java.net.http:?] {}
        at jdk.internal.net.http.HttpClientImpl.purgeTimeoutsAndReturnNextDeadline(HttpClientImpl.java:1780) ~[java.net.http:?] {}
        at jdk.internal.net.http.HttpClientImpl$SelectorManager.run(HttpClientImpl.java:1378) ~[java.net.http:?] {}
Caused by: java.net.ConnectException: HTTP connect timed out
        at jdk.internal.net.http.ResponseTimerEvent.handle(ResponseTimerEvent.java:69) ~[java.net.http:?] {}
        at jdk.internal.net.http.HttpClientImpl.purgeTimeoutsAndReturnNextDeadline(HttpClientImpl.java:1780) ~[java.net.http:?] {}
        at jdk.internal.net.http.HttpClientImpl$SelectorManager.run(HttpClientImpl.java:1378) ~[java.net.http:?] {}

And it just does this over and over again with each thing it tries to check.
Here's another:

[12:07:21] [Forge Version Check/INFO] [ne.mi.fm.VersionChecker/]: [puzzleslib] Starting version check at https://raw.githubusercontent.com/Fuzss/modresources/main/update/puzzleslib.json
[12:07:36] [Forge Version Check/WARN] [ne.mi.fm.VersionChecker/]: Failed to process update information
java.net.http.HttpConnectTimeoutException: HTTP connect timed out
        at jdk.internal.net.http.HttpClientImpl.send(HttpClientImpl.java:945) ~[java.net.http:?] {}
        at jdk.internal.net.http.HttpClientFacade.send(HttpClientFacade.java:133) ~[java.net.http:?] {}
        at net.minecraftforge.fml.VersionChecker$1.openUrlString(VersionChecker.java:139) ~[fmlcore-1.20.1-47.3.6.jar%23632!/:?] {}
        at net.minecraftforge.fml.VersionChecker$1.process(VersionChecker.java:177) ~[fmlcore-1.20.1-47.3.6.jar%23632!/:?] {}
        at java.lang.Iterable.forEach(Iterable.java:75) ~[?:?] {re:mixin}
        at net.minecraftforge.fml.VersionChecker$1.run(VersionChecker.java:114) ~[fmlcore-1.20.1-47.3.6.jar%23632!/:?] {}
Caused by: java.net.http.HttpConnectTimeoutException: HTTP connect timed out
        at jdk.internal.net.http.ResponseTimerEvent.handle(ResponseTimerEvent.java:68) ~[java.net.http:?] {}
        at jdk.internal.net.http.HttpClientImpl.purgeTimeoutsAndReturnNextDeadline(HttpClientImpl.java:1780) ~[java.net.http:?] {}
        at jdk.internal.net.http.HttpClientImpl$SelectorManager.run(HttpClientImpl.java:1378) ~[java.net.http:?] {}
Caused by: java.net.ConnectException: HTTP connect timed out
        at jdk.internal.net.http.ResponseTimerEvent.handle(ResponseTimerEvent.java:69) ~[java.net.http:?] {}
        at jdk.internal.net.http.HttpClientImpl.purgeTimeoutsAndReturnNextDeadline(HttpClientImpl.java:1780) ~[java.net.http:?] {}
        at jdk.internal.net.http.HttpClientImpl$SelectorManager.run(HttpClientImpl.java:1378) ~[java.net.http:?] {}

Now, if I try to resolve these things outside of the minecraft server it has no problem:

[carson@ataribox ProdigiumServer]$ curl -v https://raw.githubusercontent.com/Fuzss/modresources/main/update/puzzleslib.json
*   Trying 2606:50c0:8001::154:443...
*   Trying 185.199.111.133:443...
* Connected to raw.githubusercontent.com (185.199.111.133) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
*  CAfile: /etc/pki/tls/certs/ca-bundle.crt
* TLSv1.0 (OUT), TLS header, Certificate Status (22):
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.2 (IN), TLS header, Certificate Status (22):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS header, Finished (20):
* TLSv1.2 (IN), TLS header, Unknown (23):
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
* TLSv1.2 (IN), TLS header, Unknown (23):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS header, Unknown (23):
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
* TLSv1.2 (IN), TLS header, Unknown (23):
* TLSv1.3 (IN), TLS handshake, Finished (20):
* TLSv1.2 (OUT), TLS header, Finished (20):
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.2 (OUT), TLS header, Unknown (23):
* TLSv1.3 (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / TLS_AES_128_GCM_SHA256
* ALPN, server accepted to use h2
* Server certificate:
*  subject: CN=*.github.io
*  start date: Mar  7 00:00:00 2025 GMT
*  expire date: Mar  7 23:59:59 2026 GMT
*  subjectAltName: host "raw.githubusercontent.com" matched cert's "*.githubusercontent.com"
*  issuer: C=GB; ST=Greater Manchester; L=Salford; O=Sectigo Limited; CN=Sectigo RSA Domain Validation Secure Server CA
*  SSL certificate verify ok.
* Using HTTP2, server supports multi-use
* Connection state changed (HTTP/2 confirmed)
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
* TLSv1.2 (OUT), TLS header, Unknown (23):
* TLSv1.2 (OUT), TLS header, Unknown (23):
* TLSv1.2 (OUT), TLS header, Unknown (23):
* Using Stream ID: 1 (easy handle 0x560519bf2660)
* TLSv1.2 (OUT), TLS header, Unknown (23):
> GET /Fuzss/modresources/main/update/puzzleslib.json HTTP/2
> Host: raw.githubusercontent.com
> user-agent: curl/7.76.1
> accept: */*
>
* TLSv1.2 (IN), TLS header, Unknown (23):
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* TLSv1.2 (IN), TLS header, Unknown (23):
* TLSv1.2 (OUT), TLS header, Unknown (23):
* TLSv1.2 (IN), TLS header, Unknown (23):
< HTTP/2 200
< cache-control: max-age=300
< content-security-policy: default-src 'none'; style-src 'unsafe-inline'; sandbox
< content-type: text/plain; charset=utf-8
< etag: "467092d3c658d3e12473f13aa4dd01976c824d9d85d313c69fa8afa6c394ab24"
< strict-transport-security: max-age=31536000
< x-content-type-options: nosniff
< x-frame-options: deny
< x-xss-protection: 1; mode=block
< x-github-request-id: 8874:A1AF8:B53E80:F64EF1:67FBF925
< accept-ranges: bytes
< date: Sun, 13 Apr 2025 18:09:25 GMT
< via: 1.1 varnish
< x-served-by: cache-bur-kbur8200055-BUR
< x-cache: HIT
< x-cache-hits: 0
< x-timer: S1744567765.420691,VS0,VE155
< vary: Authorization,Accept-Encoding,Origin
< access-control-allow-origin: *
< cross-origin-resource-policy: cross-origin
< x-fastly-request-id: 8414c0d57eb890d5bdbbd00af16c9fc02e50da23
< expires: Sun, 13 Apr 2025 18:14:25 GMT
< source-age: 0
< content-length: 1657
<
* TLSv1.2 (IN), TLS header, Unknown (23):
{
    "homepage": "https://www.curseforge.com/minecraft/mc-mods/puzzles-lib",
    "promos": {
        "1.16.2-latest": "1.0.15",
        "1.16.2-recommended": "1.0.15",
        "1.16.3-latest": "1.0.15",
        "1.16.3-recommended": "1.0.15",
        "1.16.4-latest": "1.0.15",
        "1.16.4-recommended": "1.0.15",
        "1.16.5-latest": "1.0.15",
        "1.16.5-recommended": "1.0.15",
        "1.17.1-latest": "2.0.2",
        "1.17.1-recommended": "2.0.2",
        "1.18-latest": "3.2.1",
        "1.18-recommended": "3.2.1",
        "1.18.1-latest": "3.2.1",
        "1.18.1-recommended": "3.2.1",
        "1.18.2-latest": "3.5.10",
        "1.18.2-recommended": "3.5.10",
        "1.19-latest": "4.0.18",
        "1.19-recommended": "4.0.18",
        "1.19.1-latest": "4.2.4",
        "1.19.1-recommended": "4.2.4",
        "1.19.2-latest": "4.4.3",
        "1.19.2-recommended": "4.4.3",
        "1.19.3-latest": "5.0.33",
        "1.19.3-recommended": "5.0.33",
        "1.19.4-latest": "6.0.11",
        "1.19.4-recommended": "6.0.11",
        "1.20-latest": "7.0.9",
        "1.20-recommended": "7.0.9",
        "1.20.1-latest": "8.1.32",
        "1.20.1-recommended": "8.1.32",
        "1.20.4-latest": "20.4.52",
        "1.20.4-recommended": "20.4.52",
        "1.21-latest": "21.0.28",
        "1.21-recommended": "21.0.28",
* TLSv1.2 (IN), TLS header, Unknown (23):
        "1.21.1-latest": "21.1.33",
        "1.21.1-recommended": "21.1.33",
        "1.21.3-latest": "21.3.21",
        "1.21.3-recommended": "21.3.21",
        "1.21.4-latest": "21.4.13",
        "1.21.4-recommended": "21.4.13",
        "1.21.5-latest": "21.5.4",
        "1.21.5-recommended": "21.5.4"
    }
* Connection #0 to host raw.githubusercontent.com left intact
}
[carson@ataribox ProdigiumServer]$ nslookup https://raw.githubusercontent.com
Server:         192.168.1.59
Address:        192.168.1.59#53

Non-authoritative answer:
Name:   https://raw.githubusercontent.com
Address: 185.199.110.133
Name:   https://raw.githubusercontent.com
Address: 185.199.109.133
Name:   https://raw.githubusercontent.com
Address: 185.199.108.133
Name:   https://raw.githubusercontent.com
Address: 185.199.111.133

iSH not updating.

This one is bizarre to me too. Certainly, like with the minecraft server, this is a symptom of an underlying problem that is most likely to do with user error, but it boggles my mind as to what could be causing these things. I have an app on my phone called iSH which is supposedly a full linux VM running a shelll.

So in this particular example, things hang for a while and don't error. But, it's the hanging for an extended period of time that's odd to me here, also before hand there was an error with doing this same thing in recent:

localhost:~# apk update
fetch http://apk.ish.app/v3.14-2023-05-19/main/x86/APKINDEX.tar.gz
fetch http://apk.ish.app/v3.14-2023-05-19/community/x86/APKINDEX.tar.gz
v3.14.10-42-gd8ce7b89082 [http://apk.ish.app/v3.14-2023-05-19/main]
v3.14.10-42-gd8ce7b89082 [http://apk.ish.app/v3.14-2023-05-19/community]
OK: 14621 distinct packages available
localhost:~# apk upgrade
OK: 198 MiB in 51 packages
localhost:~# cat /etc/resolv.conf 
search lan
nameserver 2605:a601:800c:2200:c641:1eff:fe88:652e
nameserver 192.168.1.59

Conclusion

Anyways, thank you for your time in looking at this, hopefully someone sees something goofy I have setup in my settings or something. When all is said and done I need to get the minecraft server back up and running, it had no problems until the pi-hole took over dhcp.

Debug Token:

Here is my debug token

Your IP addressing does not match what is configured on the interfaces:

   2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
       link/ether 2c:cf:67:38:b3:92 brd ff:ff:ff:ff:ff:ff
       inet 192.168.1.59/24 brd 192.168.1.255 scope global noprefixroute eth0
          valid_lft forever preferred_lft forever
       inet6 2605:a601:800c:2200:82cf:272f:4ce:ced9/64 scope global dynamic noprefixroute 
          valid_lft 85752sec preferred_lft 64152sec
       inet6 fe80::741d:b155:5a3:5474/64 scope link noprefixroute 
          valid_lft forever preferred_lft forever

You also have a highly convoluted DHCP server scheme:


*** [ DIAGNOSING ]: Discovering active DHCP servers (takes 6 seconds)
   Scanning all your interfaces for DHCP servers and IPv6 routers
   Timeout: 6 seconds
   
   * Received 88 bytes from fe80::c641:1eff:fe88:652e @ eth0
     Hop limit: 64
     Stateful address conf.: No
     Stateful other conf.: Yes
     Mobile home agent: No
     Router preference: Medium
     Neighbor discovery proxy: No
     Router lifetime: 1800 s
     Reachable time: N/A
     Retransmit time: N/A
     - Prefix: 2605:a601:800c:2200::/64
       Valid lifetime: 85744 sec
       Preferred lifetime: 64144 sec
       On-link: Yes
       Autonomous address conf.: Yes
     - Route: 2605:a601:800c:2200::/56
       Route preference: High
       Route lifetime: 86400 sec
     MTU: 1500 bytes (valid)
     Source link-layer address: C4:41:1E:88:65:2E
   
   * Received 48 bytes from fe80::14a8:c736:41f1:403c @ eth0
     Hop limit: undefined
     Stateful address conf.: No
     Stateful other conf.: No
     Mobile home agent: No
     Router preference: Medium
     Neighbor discovery proxy: No
     Router lifetime: 0 s
     Reachable time: N/A
     Retransmit time: N/A
     - Route: fd55:4cea:1e48::/64
       Route preference: Medium
       Route lifetime: 1800 sec
    Unknown option 26:  1a 01 80 00 00 00 00 00
     Source link-layer address: EC:A9:07:1E:ED:27
   
   * Received 40 bytes from fe80::9561:d546:c9ef:ebe4 @ eth0
     Hop limit: undefined
     Stateful address conf.: No
     Stateful other conf.: Yes
     Mobile home agent: No
     Router preference: Medium
     Neighbor discovery proxy: No
     Router lifetime: 0 s
     Reachable time: N/A
     Retransmit time: N/A
    Unknown option 26:  1a 01 80 00 00 00 00 00
     - Route: fd92:9d98:9daa:1::/64
       Route preference: Medium
       Route lifetime: 1800 sec
   
   * Received 48 bytes from fe80::14a8:c736:41f1:403c @ eth0
     Hop limit: undefined
     Stateful address conf.: No
     Stateful other conf.: No
     Mobile home agent: No
     Router preference: Medium
     Neighbor discovery proxy: No
     Router lifetime: 0 s
     Reachable time: N/A
     Retransmit time: N/A
     - Route: fd55:4cea:1e48::/64
       Route preference: Medium
       Route lifetime: 1800 sec
    Unknown option 26:  1a 01 80 00 00 00 00 00
     Source link-layer address: EC:A9:07:1E:ED:27
   
   Received 0 DHCP (IPv4) and 4 RA (IPv6) answers on eth0

There also looks to be an overlap in the address pool

   2025-04-13 11:53:22.451 MDT [180216M] WARNING: WARNING in dnsmasq core: not using configured address 192.168.1.59 because it is in use by the server or relay

I don't see any evidence that an IPv6 network is needed for the LAN. You'll make the troubleshooting and maintenance a lot easier if you stick to IPv4 only on the lan. If you must have an IPv6 address space then use ULA and not GUA addresses.

Hey, thanks so much for taking a look at this and helping me out. I really appreciate your time and expertise.

Firstly, you have a keen eye catching the discrepancies in the ipv6 addresses, I probably wouldn't have noticed that first glance. Thanks for pointing it out, I bet it points back to my old router. The question is, can I get network manager to update it based on what pi-hole is handing out in dhcp from dnsmasq? (Sorry again for ignorance, my focus is almost purely systems, so the networking side is a bit foggy for me.)

You'll have to forgive my ignorance here, I'm not understanding why you think my DHCP server scheme is convoluted (I also don't know what a dhcp scheme is to be frank.)

A note on the ipv6 network, I have disabled the ipv6 dhcp on my pi-hole. I would prefer to only do networking on ipv4, am I going to have to hand set all of my devices to disable ipv6, or is there an easier way to do this?

On the topic of an overlap in the address pool, I found this:

not using configured address `ADDRESS` because it is in use by the server or relay

Handing out addresses used by known critical infrastructure (like the DHCP server or a relay) is prevented to avoid IP address duplication issues.

This can happen when you have configured a static address assignment for the IP address of your Pi-hole. As this could result in an IP address conflict, Pi-hole offers a different free address from your configured DHCP pool. As this means Pi-hole behaves differently than you configured it to, it issues a warning.

The solution would be to either remove the static reservation for the Pi-hole itself (see `ADDRESS` in the warning) or simply accept this warning as it should only happen during debug log generation. When this warning appears outside of a running DHCP test, check that your Pi-hole is indeed using a static address.

I believe what's happening here is that I've statically define my pi-hole from the pi-hole dhcp interface, and I've statically set the address on the device as well, so when it tries to hand out the pi-holes ip it sees a device that already has it (the pi-hole) and we get the warning message.

As far as DNS is concerned, it would be sufficient to configure your router to not provide any IPv6 addresses as DNS server.
If your router doesn't support that, you'd have to make sure it uses one of your Pi-hole host machine's stable LLA or LUA IPv6 addresses, rather than its own IPv6.

You could also try to configure your router to not advertise any public IPv6 prefixes, and to disable its DHCPv6 server, but you still should verify that your router doesn't advertise its own LLA IPv6 address as DNS server.

While the router advertisements (RAs) from your debug log do not contain any recursive DNS server (RDNSS) lines, your resolv.conf likely points to your (Belkin?) router's GUA, suggesting your Pi-hole host OS has learned that via your router's RAs or via DHCPv6.

With regards to convolution, do you run any Apple networking equipment, or perhaps a hotspot via an iPhone?

RAs from your debug log originate not only from your router, but also from Apple devices offering a ULA route.

That's unusual, especially since your Pi-hole host doesn't have a ULA address.

My router is a linksys velop model WHW03v1. I just now disabled ipv6 - automatic, but other than that I'm unfortunately not seeing more ipv6 related settings to disable. I assumed that because I disabled my routers dhcp it would stop providing ipv4 and ipv6 entirely though, am I wrong in this assumption?

I'm not sure where to configure it not to advertise ipv6 prefixes, the only other ipv6 related setting I could find was the 'ipv6 - automatic' mentioned above and I did disable that. If we want to go deeper into tweaking these settings I might need to flash it with something like openwrt which I'm not certain I want to dive into quite yet, especially considering my level of ignorance on the networking side of things.

To answer the Apple networking question, yes I run a hotspot from my iphone, and I'm sure my significant other does too. If you don't disable it on your apple device I believe it just remains constantly up.

Thanks for your time, I'll keep things updated if anything changes, but as of now-- minecraft server is still broken. Is there a manual for idiots like me setting up dhcp on raspberry pi? I was hoping to avoid the RTFM approach as I spend at least 60 hours a week problem solving this way, (which is why I decided to go with pi-hole rather than dnsmasq or dhcpd) but I don't think it's avoidable at this point.

Thanks again for your time.

Changing the 'ipv6 - automatic' setting to disabled is what rescued the minecraft server. Thank you guys so much for your insight and expertise, I really appreciate it!

1 Like