What is the role of odhcpd / dnsmasq ?

When looking at the relevant documents, I found that the functions of the two services odhcpd / dnsmasq overlap. I wonder how the roles of these two services are distinguished?

for example:

  1. Is it possible to implement dns and dhcp services only by dnsmasq service in IPv4 environment?
  2. Does odhcpd only provide DHCPv6 service in IPv6 environment?
  3. The WAN port obtains the operator's IPv6-PD through PPPoE, and the LAN only configures IPv6 through SLAAC mode, so which service is responsible for the RA message?

If you only use ipv4, you only need dnsmasq.

Odhpcd is the OpenWrt-specific IPv6 addressing server for the Lan side. To my knowledge, it handles both DHCPv6 and slaac. (It could handle also DHCPv4 for ipv4, but normally does not. The functionality is somewhat limited.)

Odhcp6c is the OpenWrt IPv6 client daemon for the wan side, which interacts with the ISP's DHCPv6/slaac.

Both tools were developed roughly in 2013-2014, when the IPv6 support was ramped up and the old-school radvd proved to be too limited error OpenWrt usage.

OpenWRT's odhcpd parameters are not in a separate configuration file like other services, but mixed in the interface configuration file, which is very confusing.

It's been like in the documentation via https://openwrt.org/docs/techref/odhcpd
The preferred_lifetime parameter fails to modify the lifetime parameter in the SLAAC RA message. Do you know the reason? Does the lifetime in the RA message only support modification in DHCPv6 mode?

You can also if you like remove odhcpd and use Dnsmasq only for dhcpv6 an RA.
I could be totally off, but I for myself was not able to make DNS for clients available with odhcpd (hostnames in local DNS for each vlan). Once I removed it and used dnsmasq only it just worked. But I found no documents regarding that. So not quiet sure want went wrong.

The two service roles of odhcpd / dnsmasq overlap, and the official OpenWRT does not introduce it in detail, making it confusing. The configuration related to DHCPv6 or SLA message broadcast in SLAAC mode by dnsmasq is not officially provided, so there is no way to start. At present, I mainly want to solve how to customize or modify the preferred_lifetime parameter of RA messages in SLAAC mode

1 Like

OpenWrt's default dnsmasq configuration cannot do IPv6. You'd need to replace it with the dnsmasq-full package for that.

Not sure what system version you are using? I am using the official version 18.06.3. The WEB management interface does not have the configuration options you specified, and it does not take effect by directly editing the configuration file. Is it the reason that the system version does not support this parameter?

E.g:

config dhcp 'lan'
...
        option interface 'lan'
        option preferred_lifetime '10m' / option ra_lifetime '10m'
        option ra 'server'
...

18.06 is no longer supported, I am using 21.02.2.

1 Like

Does the odhcpd service of version 18.06.3 not support this parameter? Or is 18.06.3 no longer updated? So what is the earliest version that supports the preferred_lifetime parameters?

If I want to use dnsmasq-full to implement SLAAC RA Do you have the relevant configuration documentation?

18.06.x has been officially EOLed on December 9th, 2020 - nothing has (or will) happend to the branch since. 18.06.3 hasn't even been supported since July 2019…

It's dead, Jim.

1 Like

18.06.x stop supporting does not mean that the preferred_lifetime / ra_lifetime and other parameters are not supported before the support is stopped, I mean that the official documentation does not indicate which version these parameters are supported from.

But it does mean that few will remain eager to provide user support for it, especially when it comes to gory details (and 18.06.x was already deprecated, but still security maintained, since january 2020).

1 Like

Many newly supported parameters are specifically stated in the official document from which version to support, but preferred_lifetime / ra_lifetime These parameters are not stated in the introduction of the official document, which makes people think that this is not a new feature。

If a parameter is not supported by all versions, the official documentation should specify it.

You are right, I missed that in my statement.

@Borromini
Any how, current https://openwrt.org/docs/guide-user/base-system/dhcp lists
ra_preference, ra_mininterval, ra_maxinterval, ra_lifetime as config option for a dhcp pool of dnsmasq and the wiki page does not say anything about it that dnsmasq-full is required for these options. As I use dnsmasq-full anyway I can not check it right now.
@trendy has posted a screenshot that this can be set via LuCI, too.

As a site note: You can also use bird2 and configure radv: https://bird.network.cz/?get_doc&v=20&f=bird-6.html#ss6.11 If you like or need.

Why should it mention that? It is stated on the top of the page that dhcpv6 is handled by odhcpd-ipv6only and that covers a default installation. If the user wishes to install dnsmasq-full or odhcpd or something else, it is their responsibility to configure them properly.

1 Like

Because for instance, for option dnssec it is a site note that dnsmasq-full is required, so why not for RA and DHCPv6? Ok, and now we went off topic.

The only point I wanted to make, is that a user is free to remove odhcp6d and get "everything" from dnsmasq, read as in getting RA and DHCPv6 in addition to the default DHCPv4 from dnsmasq.

Like I said, my personal reason was that I was unable to get AAAA records for dhcpv6 clients and also no AAAA records for slaac. So I removed odhcp6d and let dnsmasq(-full) handle it.... The following is from 21.02 and I recently discovered that I have done the same on 19.07 and even forgot about doing so in the meantime.

config dhcp                     'vlan16'                               
    option  interface           'vlan16'                               
    option  domain              'net.mgmt.home.arpa'                   
    option  start               '32'                                   
    option  limit               '215'                                  
    option  leasetime           '12h'                                  
    option  dhcpv4              'server'                               
    list    dhcp_option         'option:dns-server, 192.168.0.1'                               
    list    dhcp_option         'option:domain-name, net.mgmt.home.arpa.'                      
    list    dhcp_option         'option:ntp-server, 192.53.103.103'                            
    list    dhcp_option         '100,UTC'  # PCode                                             
    list    dhcp_option         '101,UTC'  # TCode                                             
    list    dhcp_option         'option:domain-search, net.mgmt.home.arpa.'                    
    list    dhcp_option         'option:classless-static-route, 192.168.0.0/16,192.168.16.1'   
    option  dhcpv6              'server'                                                       
    list    dhcp_option         'option6:dns-server, [fde6:a09a:b373::1]'                      
    list    dhcp_option         'option6:domain-search, net.mgmt.home.arpa.'                   
    list    dhcp_option         'option6:ntp-server, de.pool.ntp.org.'                         
    option  ra                  'server'                                                       
    option  ra_slaac            '1'                                                            
    list    ra_flags            'managed-config'                                               
    list    ra_flags            'other-config'           


root@cpe:~# dig +short any ap2.net.mgmt.home.arpa
192.168.16.132
fde6:a09a:b373:10:0:3ff:fe01:10
fde6:a09a:b373:10::3a51
2003:e4:bf1b:XX10:0:3ff:fe01:10


root@ap2:~# ip -br -6 addr show dev br-vlan16; echo ; ip -6 route show dev br-vlan16
br-vlan16        UP             fde6:a09a:b373:10:0:3ff:fe01:10/64 \
                                2003:e4:bf1b:XX10:0:3ff:fe01:10/64 \
                                2003:e4:bf1b:XX10::3a51/128 \
                                fde6:a09a:b373:10::3a51/128 \
                                fe80::3ff:fe01:10/64 

default from 2003:e4:bf1b:XX10::3a51 via fe80::1ff:fe01:10 proto static metric 512 pref medium
default from 2003:e4:bf1b:XX10::/64 via fe80::1ff:fe01:10 proto static metric 512 pref medium
default from fde6:a09a:b373:10::3a51 via fe80::1ff:fe01:10 proto static metric 512 pref medium
default from fde6:a09a:b373:10::/64 via fe80::1ff:fe01:10 proto static metric 512 pref medium
2003:e4:bf1b:XX10::/64 proto static metric 256 pref medium
fde6:a09a:b373:10::/64 proto static metric 256 pref medium
fe80::/64 proto kernel metric 256 pref medium

Because RAs and DHCPv6 are there already in a default installation, in contrast to dnssec, and the aim of OpenWrt is to fit as much as possible in a small image.

and the aim of OpenWrt is to fit as much as possible in a small image.

My image is still under 8 MB and I take the luxury of including pppoe, freeradius, batman, batctl-full, bird2 and bird2c, wpad-openssl, ... My point: The 4 MB era has already ended, and I still have some space left....

That beside, it might be just an historic reason why odhcpd was chooses back in the days, and I do not doubt that it has its use cases but compared to dnsmasq it seams to have a limited feature set. Only by comparing the wiki, man pages and documentation within each src/git.

That dnsmasq is trying to do/is doing "stuff" far beyond is another discussion, but as a user, I would expect that, if my (dhcp) clients hostname is available on the local dns via v4, and it should be available on v6, too.
And it seams not to work properly on a default installation, again please correct me if I'm wrong!
If this is really the case, that on a default installation a dhcp client is accessible by its name on v4 but not on v6 then this is a bug and not a feature. And I can hardly imagine that nobody encountered this misbehavior before me.

Another note: The wiki is full of esoteric examples I imagine only 0.001% of the user base or even less will ever use, but these examples are there. This is good and this is bad. I'm not in the position to judge why or why not people want to stuff they way they do. But again, if the wiki page of dhcp lists all possible config options even these which are not available on a default installation with the mark that the user is expected to install addition software or swap a packaged, then this fact would be on other options too. Or the mark that that or the other option is used by odhcp AND by dnsmasq(-full). Documentation is only cool when it is complete, because then software can be used by the user.

And last point before I say good night: The last time I checked:

The name LEDE is an abbreviation for Linux Embedded Development Environment, a reference to its flexibility and embedded buildroot origins, making it a solid choice for embedded Linux applications far beyond the wireless router and network appliance realm.

Good night -.-