0

Due to a device loss in the network, a new DNSMASQ configuration has been brought in on a different server. The server happens to be a Raspberry Pi 4B. Many devices are able to obtain IP addresses, but some (Windows 10 devices in particular) are timing out on the DHCP request. This is new; there was no known problem before with DHCP, and I don't any reason for this configuration to be biased. The configuration is:

# Use interface wlan0
#interface=eth0
#interface=lo
#interface=wlan0

listen-address=10.158.54.3
listen-address=127.0.0.1

bind-interfaces

# Don't forward unqualified names (hpmicro1)...
domain-needed

# Don't forward some non-routed addresses
bogus-priv

# don't forward requests for the intranet subdomain
local=/lovelady.com/

# Assign addresses between 10.158.54.65 and 10.158.54.200 with a 24 hour lease time
dhcp-range=10.158.54.101,10.158.54.200,12h

# Forward DNS requests to the local DNS and then Google DNS
server=10.158.54.3
server=8.8.8.8
server=8.8.4.4

dhcp-option=option:router,10.158.54.1    # Default gateway
dhcp-option=6,10.158.54.3               # DNS (that's me)

# append domain to all hosts
domain=lovelady.com

expand-hosts # Add domain also to any simple names in /etc/hosts    

dhcp-host=b4:2e:99:a2:58:77,Velmicro
dhcp-host=ac:1f:6b:17:f6:25,NAS-1,10.158.54.10
dhcp-host=ac:1f:6b:9a:cb:6c,PLEX-NAS1
dhcp-host=b8:27:eb:ba:a0:7b,pi-in-the-sky
dhcp-host=00:1c:d2:f1:94:3d,inet-radio
dhcp-host=38:f7:3d:b1:12:3f,Amazon-BSMT
dhcp-host=fc:a1:83:43:30:76,Amazon-LivRm
dhcp-host=20:df:b9:57:9d:46,Google-Home
dhcp-host=b8:27:eb:9b:e1:91,octopi-w,10.158.54.20
dhcp-host=50:87:b8:00:8e:46,luvtablo

Would appreciate any help you can provide...

Improve this question
2
  • 1
    You should look at the DHCP clients' logs to get a clue, but the server log may be helpful too, if the connection succeeded but the response is "ignored" or not received. For me the server configuration looks fine. Finding an error is always done by searching the logs...
    – nix
    Commented Apr 22, 2020 at 7:53
  • Thanks for the tip @nix. I set up logging of requests in dnsmasq's startup script /etc/rc.d (--log-requests, --log-facility /var/log/dnsmasq.log) and stopped the service and restarted. Then I did a fresh "ipconfig/renew" from windows and checked its event viewer. No recent activity at all in the Windows / Application logs, and no recent DHCP-CLIENT activity at all in the Windows / System logs.Event Viewer. Also no /var/log/dnsmasq.log file appears. Any additional tips? Thanks!
    – Dennis
    Commented Apr 22, 2020 at 13:46

1 Answer 1

Reset to default
0

Turns out that the message about timeout is misleading. Apparently since recent versions of Windows 10, the system will sometimes try to reset the loopback interface (a.k.a. localhost, or 127.0.0.1) and that is what the error was saying. After windoze finally timed out on the loopback interface, it obtained an IP address for the other applicable interfaces. Windows should not ever try to reset the localhost interface, and usually it doesn't. But it has moods, apparently.

Improve this answer

You must log in to answer this question.

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