OpenWrt/LEDE Project

  • Status Closed
  • Percent Complete
    100%
  • Task Type Bug Report
  • Category Packages
  • Assigned To
    Yousong Zhou
  • Operating System All
  • Severity High
  • Priority Very Low
  • Reported Version All
  • Due in Version Undecided
  • Due Date Undecided
  • Private
Attached to Project: OpenWrt/LEDE Project
Opened by PussAzuki - 13.05.2019
Last edited by Yousong Zhou - 09.06.2019

FS#2281 - The Dnsmasq-full seems have problems when it was compiled without DHCP function

First,select the package dnsmasq-full but not select the option " Build with DHCP support”, then save the .config and start compiling ,finally extract the installation file or firmware to install or flash,and now you will see the dnsmasq won’t start even if you modify it in the /etc/config/dhcp file unless you manually change its startup script. The keyword should be dhcp-ignore-names ,dhcp-broadcast and dhcp-leasefile.According to the documentation, when I go to modify the dnsmasq setting in the /etc/config/dhcp file and delete its dhcp related settings, dnsmasq’s dhcp function can be disabled, but it is not implemented in this way.I used odhcpd to serve as a dhcpv4 and dhcpv6 server and I think it’s no need to keep dnsmasq’s DHCP function.

Closed by  Yousong Zhou
09.06.2019 08:21
Reason for closing:  Fixed
Additional comments about closing:  

Now there is a way out with commit http://g it.openwrt.org/0299a4b73e729504dfdc5c456 3535db082bdf941

PussAzuki commented on 18.05.2019 09:16

Anyone can help me? If my statement is not clear enough, I can talk about it in more detail. You don’t say anything makes me very worried.

Project Manager
Yousong Zhou commented on 25.05.2019 08:17

2 things to note

- Some options have default values, e.g. –dhcp-leasefile. Deleting it or setting it an empty value will make them take on default values in the end
- Some options are added unconditionally, e.g. –dhcp-broadcast

I would suggest grepping out dhcp-related options at the end of config generation

diff --git a/package/network/services/dnsmasq/files/dnsmasq.init b/package/network/services/dnsmasq/files/dnsmasq.init
index 93a8f9a108..e35a8a7933 100644
--- a/package/network/services/dnsmasq/files/dnsmasq.init
+++ b/package/network/services/dnsmasq/files/dnsmasq.init
@@ -1027,6 +1027,11 @@ dnsmasq_start()
 		done
 	}
 
+	if dnsmasq --version | grep -q ' no-DHCP\>'; then
+		grep -v dhcp "$CONFIGFILE" >"$CONFIGFILE.1"
+		mv "$CONFIGFILE.1" "$CONFIGFILE"
+	fi
+
 	procd_open_instance $cfg
 	procd_set_param command $PROG -C $CONFIGFILE -k -x /var/run/dnsmasq/dnsmasq."${cfg}".pid
 	procd_set_param file $CONFIGFILE

Sorry for the late reply, but no need to worry. It just takes time.

PussAzuki commented on 25.05.2019 08:53

If dnsmasq-full was compiled with DHCPv4 function only, can this pass that?

Project Manager
Yousong Zhou commented on 25.05.2019 09:20

That falls into the same setting as with "dnsmasq" package. I think it should work.

I think the real problem is that initscript does not take into consideration all the combinations of customizations for dnsmasq-full. The patch I provided above can only serve as a rough hack. To seriously tackle the issue, we need to check option by option while in the same time trying to not break existing configs

PussAzuki commented on 25.05.2019 09:23

OK, I will wait for you. Thanks for listening to me.

Project Manager
Yousong Zhou commented on 25.05.2019 09:29

I cannot make promise. Been too busy these days, sorry.

Project Manager
Yousong Zhou commented on 26.05.2019 16:09

Hi, I just sent out a patch [1] for review. Please give it a try to see if it works for you. Thank you.

[1] http://patchwork.ozlabs.org/patch/1105581/

PussAzuki commented on 26.05.2019 17:48

This setting in the script does not seem to be ignored: DHCPBOGUSHOSTNAMEFILE="/usr/share/dnsmasq/dhcpbogushostname.conf"
And it can make you crazy!

PussAzuki commented on 26.05.2019 17:54

If you have enough time, I think we should adjust the order of the script content, even rewrite it.It looks a bit messy now.

Project Manager
Yousong Zhou commented on 27.05.2019 01:44
This setting in the script does not seem to be ignored: DHCPBOGUSHOSTNAMEFILE="/usr/share/dnsmasq/dhcpbogushostname.conf"
> And it can make you crazy!

Set dhcpbogushostname to 0, it will not be output.

Two things to note in this implementation
»
- The option list is not exhausted. Supposedly only those options that
» may cause dnsmasq to reject with "unsupported option (check that
» dnsmasq was compiled with DHCP/TFTP/DNSSEC/DBus support)" are taken
» into account here
» - This provides a way out but users' cooperation is still needed. E.g.
» option dnssec needs to be turned off, otherwise the service script
» will try to add –conf-file pointing to dnssec specific anchor file
» which dnsmasq lacking dnssec support will reject
If you have enough time, I think we should adjust the order of the script content, even rewrite it.It looks a bit messy now.

No, I do not have such plan in the near future. If it's really that bad, someone will do.

PussAzuki commented on 27.05.2019 04:50

Set dhcpbogushostname to 0, it will not be output. —-
I'm sure there is nothing about this according to the document and it is why I feel that if we can, we should rewrite the script.I have taken a look on document: https://openwrt.org/docs/guide-user/base-system/dhcp#all_options

Project Manager
Yousong Zhou commented on 27.05.2019 05:39

Rewrite is not the solution to documentation being incomplete.

That said, feel free to improve the code ;)

PussAzuki commented on 10.06.2019 06:30

Set dhcpbogushostname to 0, it will not be output.
–But it won't be set by default, which means it still brings problem to you!
I just came back from experiencing padavan and then suffered this bug.We should carefully examine the difference between theory and practice...

Project Manager
Yousong Zhou commented on 10.06.2019 07:38

Hi PussAzuki, I wish you well, I really do. No need to suffer or be driven crazy because of a piece of software ;)

As said in the commit message, the change is mainly for providing a way out for users with such customized dnsmasq build, i.e. they should be able to run dnsmasq by customizing only uci config, no need to tinker with code part.

This provides a way out but users' cooperation is still needed. E.g.
option dnssec needs to be turned off, otherwise the service script
will try to add –conf-file pointing to dnssec specific anchor file
which dnsmasq lacking dnssec support will reject

If you got better solution, note that we are all ears to hear it.

PussAzuki commented on 10.06.2019 10:53

Yes, as you said, this is designed for high-customized players, but when I did a clean flash and then started the router after that, it didn’t react at all.... because the package odhcpd has taken the DHCP responsibility of dnsmasq-full. But by default this won't be written in the file and this can be a big problem...
I noticed that there is a correlation decision on odhcpd in the startup script of dnsmasq. Maybe that is a breakthrough.For example, if there is no other software can do DHCP function when make menuconfig, then odhcpd-ipv6only will be switched to odhcpd and take the initiative to assume DHCP responsibility by default. Or separate the functions of the startup script, and combine them into scripts as needed...

Loading...

Available keyboard shortcuts

Tasklist

Task Details

Task Editing