Gl_monitor kills dnsmasq every 30 seconds

tve · 2019-10-28T06:19:06.393Z

I have an X750 Spitz that I just upgraded to 3.027. I notice in the logs that gl_monitor kills and restarts dnsmasq every 30 seconds, complaining about “dhcp-range for lan network is missing”. I have dhcp disabled (both ipv4 and ipv6) for the lan interface 'cause I have a separate router that does the DHCP. How do I fix gl_monitor?

Here’s what the system log looks like:

Sun Oct 27 23:04:23 2019 user.notice gl_monitor: dhcp-range for lan network is missing, restart dnsmasq
Sun Oct 27 23:04:23 2019 daemon.info dnsmasq[15444]: exiting on receipt of SIGTERM
Sun Oct 27 23:04:24 2019 user.notice dnsmasq: DNS rebinding protection is active, will discard upstream RFC1918 responses!
Sun Oct 27 23:04:24 2019 user.notice dnsmasq: Allowing 127.0.0.0/8 responses
Sun Oct 27 23:04:24 2019 daemon.info dnsmasq[18373]: started, version 2.80test2 cachesize 150
...
Sun Oct 27 23:04:55 2019 user.notice gl_monitor: dhcp-range for lan network is missing, restart dnsmasq
Sun Oct 27 23:04:55 2019 daemon.info dnsmasq[18373]: exiting on receipt of SIGTERM
Sun Oct 27 23:04:55 2019 user.notice dnsmasq: DNS rebinding protection is active, will discard upstream RFC1918 responses!
Sun Oct 27 23:04:55 2019 user.notice dnsmasq: Allowing 127.0.0.0/8 responses
Sun Oct 27 23:04:56 2019 daemon.info dnsmasq[20780]: started, version 2.80test2 cachesize 150
...
Sun Oct 27 23:05:27 2019 user.notice gl_monitor: dhcp-range for lan network is missing, restart dnsmasq
Sun Oct 27 23:05:27 2019 daemon.info dnsmasq[20780]: exiting on receipt of SIGTERM
Sun Oct 27 23:05:27 2019 user.notice dnsmasq: DNS rebinding protection is active, will discard upstream RFC1918 responses!
Sun Oct 27 23:05:27 2019 user.notice dnsmasq: Allowing 127.0.0.0/8 responses
Sun Oct 27 23:05:28 2019 daemon.info dnsmasq[23249]: started, version 2.80test2 cachesize 150
...

robotluo · 2019-10-28T08:05:14.594Z

Have you configured WAN port as LAN port?

cachrisman · 2020-03-24T11:04:18.497Z

I’m in the same boat as the OP. I’m using a GL-MT300N-V2 as an access point and print server, so I’ve used the Luci interface to put make the WAN port in the same VLAN as the LAN port and disabled DHCP on the LAN interface. I keep getting the following (and a bunch of lines from dnsmasq startup) every 30 seconds:

gl_monitor: dhcp-range for lan network is missing, restart dnsmasq

How can I fix this? Do I need to keep gl_monitor running? can I just disable the service from starting and end the process?

DaFox · 2020-05-09T11:16:22.571Z

Reason is /usr/bin/gl_monitor cannot cope with DHCP disabled on LAN interface. I have disabled DHCP on my LAN interface because I’m handling that on a pihole instance for my network.

To fix this, /usr/bin/gl_monitor would need to also check for value no-dhcp-interface=br-lan in the dnsmasq configuration file in /var/etc/dnsmasq.conf.*. Thus, just add this line as the first line in function ‘restore_lan_dnsmasq()’ in /usr/bin/gl_monitor:

[ ! -z "$(grep 'no-dhcp-interface=br-lan' /var/etc/dnsmasq.conf.*)" ] && return

which is effectively silencing the error after restarting /usr/bin/gl_monitor with:

/etc/init.d/gl_monitor restart

BradG · 2020-10-13T04:32:49.228Z

DaFox:

[ ! -z "$(grep 'no-dhcp-interface=br-lan' /var/etc/dnsmasq.conf.*)" ] && return

I also had this problem. I wanted to use the LAN interface on a network with an existing DHCP server.

I did something slightly different in the /etc/config/dhcp func:

[ "$(uci get dhcp.lan.ignore 2> /dev/null)" == 1 ]  && return 0

My proposed fix is to add a option ignore '1' to the config dhcp 'lan' section of /etc/config/dhcp. This solution can also be done in Luci.

Another test which probably needs to be run is the existence of the LAN interface. If the user changes the name of that bridge interface, it will mess everything up that way too.

So there probably also needs to be a test for “uci get dhcp.lan.interface” as well.

puddlewitt · 2022-03-11T11:12:17.077Z

I had the same issue with the GL-AX1800. My setup was with pihole providing DHCP services.

I’ve attempted to write up what I did, with thanks to the previous posts.

The comments by @BradG regarding the check for the interface named lan still hold true, be careful it looks like lots would break.

GL-AX1800

Issue

Higher than expected cpu usage
dnsmasq is constantly restarting with the following message in the systemlog

Fri Mar 11 10:48:45 2022 user.notice gl_monitor: dhcp-range for lan network is missing, restart dnsmasq

Fri Mar 11 10:48:45 2022 daemon.info dnsmasq[20661]: started, version 2.80 cachesize 150

Resolution Steps

Add a option ignore '1' to the config dhcp 'lan' section of /etc/config/dhcp. This appears to already be done for me…I made no changes.

For example…
```
config dhcp 'lan'
    option interface 'lan'
    option ignore '1'
```

Edit /usr/bin/gl_monitor and locate the function restore_lan_dnsmasq(). Add the following before the logging message dhcp-range for lan network is missing, restart dnsmasq

if [ "$(uci get dhcp.lan.ignore 2> /dev/null)" == 1 ]; then                             
  logger -t gl_monitor "ignore located, no action taken"
  return                                                
fi

For example…

if [ -n "$brlan" ]; then                                          
        if [ "$(uci get dhcp.lan.ignore 2> /dev/null)" == 1 ]; then                             
                logger -t gl_monitor "ignore located, no action taken"
                return                                                
        fi                                                            
                                                                           
        logger -t gl_monitor "dhcp-range for lan network is missing, restart dnsmasq"
        /etc/init.d/dnsmasq restart                                                  
fi

Restart the monitor service /etc/init.d/gl_monitor restart
Check the systemlog for Fri Mar 11 11:06:06 2022 user.notice gl_monitor: ignore located, no action taken

robotluo · 2022-03-14T01:05:38.313Z

This issue will be fixed in the new firmware.