[FS#1348] dnsmasq config script doesn't handle vendorclass specifications properly

[LEDE Bugs]

A new Flyspray task has been opened.  Details are below. 

User who did this - cbz (cbz) 

Attached to Project - OpenWrt/LEDE Project
Summary - dnsmasq config script doesn't handle vendorclass specifications properly
Task Type - Bug Report
Category - Base system
Status - Unconfirmed
Assigned To - 
Operating System - All
Severity - Medium
Priority - Very Low
Reported Version - Trunk
Due in Version - Undecided
Due Date - Undecided
Details - This happens as of LEDE 17.01.4, and is a result of how /etc/init.d/dnsmasq script rebuilds the temp dnsmasq config file from the /etc/config/dhcp file.

dnsmasq supports the following construct:

dhcp-vendorclass=set:ubiquity,ubnt
dhcp-option=tag:ubiquity,1,192.168.1.10

The meaning of which would be that if a vendor string that matches 'ubnt' is seen, then the class 'ubiquity' is set against the device, any dhcp-options tagged with that class would be sent to devices so tagged.

The dhcp config files supports constructs like this:

config vendorclass 'ubiquity'
    option vendorclass 'ubnt'
    option networkid 'vendor:ubnt'
    list dhcp_option '1,192.168.1.10'

but in this case the value of networkid is pre-pended in each case to the dhcp_option string, like so:

dhcp-vendorclass=vendor:ubnt,ubnt
dhcp-option=vendor:ubnt,1,192.168.1.10

Which works as config - but only because the vendorclass specification is not at work at all - essentially all the matching is occurring within the dhcp-option (it wouldn't be possible to specify multiple values to be matched in the vendorclass specifier for instance).



 

More information can be found at the following URL:
https://bugs.lede-project.org/index.php?do=details&task_id=1348