[Feature Request] Add proper DHCP options to Glinet Web Interface

The default Glinet DHCP options are way too limited and need a redesign.

Please add the following for each DHCP client:

  • dhcp options to push, like custom dns and gw
  • change the way the clients are named

If you edit the /etc/confug/dhcp file to implement dhcp push options, the naming is bugged in the current solutions:

image

The problem is, that the Glinet DHCP page uses the "tag" feature in the /etc/confug/dhcp file to name them. This is not a good way and causes issues if you use the tag for what it is designed in Openwrt:

config tag 'owndns'
	list dhcp_option '6,1.1.1.1,8.8.8.8'

config host
	option mac '...'
	option ip '192.168.8.165'
	option name 'mkdr-HUE'
	option tag 'owndns'

config host
	option mac '...'
	option ip '192.168.8.11'
	option tag 'mkdr-V11'

You need to change this from tag to name, or store the names in another file.

The field "Description" in the glinet web interface need / should be changed to host-name and use the "name" option in the config file.

Then also add options for dchp_option for each client too to push custom DNS for example or custom gw for each client.

The whole interface should be extended too to properly see lease times, end leases, or give each client different lease times.

The options also should have their own list entry here as DHCP instead of it being in "LAN", this is confusing.

image

Another issue which needs to be changed:

image

You cant edit the DNS fields for network wan if it is set to DHCP. DHCP should allow custom DNS servers though. You can only edit this by changing /etc/config/network manually

config interface 'wan'
	option device 'eth0'
	option ipv6 '0'
	option vlanid '0'
	option disabled '0'
	option classlessroute '0'
	option metric '1'
	option proto 'dhcp'
	option peerdns '0'
	list dns '1.1.1.1'
	list dns '8.8.8.8'

Tag allow to write name with space and symbol. For example "Kitchen's speaker".

The openwrt tag option in this config file is not meant to be abused in this way. it is used in the way I gave an example, for tagging and setting options for tags like dhcp_options. Like I said. They need to store these names somewhere else in their Glinet Api db. Or add some arbitrary 2nd line into the file like tag2 or glinet_tag.

There is no DB. One of the reasons why GL firmware acts how it acts is that they use the OpenWrt config files as plain as possible.

You store your information somewhere I dont care where and how. A txt file is also a db. Then add a 2nd line to the config file and name it tag2. but dont abuse the tag in this case.This needs to be changed. The argument is in my original post and simple to understand why.

It was just for your understanding.

At the end @bruce and R&D need to take a look. I don‘t agree that DHCP is too limited because it's a consumers device. They just want it to work, no professional network.

Sooner or later GL needs to impmement an easy / advanced view for configs.

2 Likes

Another way try use DHCP server in Adguard home which does have names.

Hmm, i'd like this option but because the gl ui is for simple use maybe not allow full use of dhcp options or tags at all visible on the ui, since that might confuse users.

What if a user navigates to clients and click edit on one, then has a option for custom dns and either the dhcp tag becomes a more backgrounded group, maybe base the tags naming with the custom dns, the only issue then is detecting pre existing tags to avoid making dupes this doesn't seem easy in uci since there isn't a lookup function afaik, you must for loop each time on all tag nodes and then compare names.

Dhcp option 6 is often the most used case, so it looks better to have it implemented like this.

^ edit

Maybe it doesn't need to be this complicated, actually i think a user understands more about the term 'group' as tag, so then you can add the tag field to client edit and the mac/ip in one simple struct, the only issue resides with uci though since it cannot be called like uci show dhcp.mytag its uci show dhcp.@tag[2] where 2 can be any type ordered tag how it has been placed, so it still need iteration with string comparison so they need to write a helper function to get the tags by string name.

Normally im against iterations but if its called efficiënt only with editing or adding, it won't cost super much performance.

GL GUI -> Network -> DNS, here already support to custom DNS address for LAN.

Although it can not modify in the WAN, but after custom set up Network -> DNS, all DNS requests will also point to that DNS IP.

We know that DNS can be configured in many places in Luci, which is very useful for advanced users.
But for basic users, they know that one place can manually modify the DNS in the GL GUI, if the DNS setting appears in multiple places, they will have questions.

Add, one DNS setting is also for VPN, if VPN is enabled and the users set up custom DNS at the WAN interface, mistakenly believing that the traffic goes to interface WAN (WAN DNS) but in fact is wgclient/ovpnclient.

This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.