I still disagree. If devices don't let you change their name - either directly by static setting or by assigning them hostnames via DHCP -, they broke the standard and they should be fixed at first. Omada controller already displays names of all devices implementing the hostname mechanism correctly. Bugs should be fixed at the root and not by elsewhere fixing the symptoms they cause.

While I can see enough reasoning in your feature request, this:

mikernova wrote

Setting a static DHCP name on your router has no impact here.  A DNS name is simply an alias for an IP address.

is wrong. You can indeed set the hostname of a system using the DHCP's hostname option, but the client has to ask for it. See https://www.ingmarverheij.com/configure-hostname-via-dhcp/. Of course, vendors not caring about the hostname won't ask DHCP for it, too.

It is also the way hardcoded hostnames make it into the DNS automatically (for example in dnsmasq which is a DHCP/DNS server). In fact, all the names seen in Omada Controller are added to the DNS forwarding server running on the router this way.

mikernova, I think you still didn't get my point. Here is a quick test with one of my SOHO devices.

Hardcoded name:

# cat dhcp.leases 
1559505374 40:3f:8c:xx:yy:zz 192.168.11.68 Neffos_N1 *
#

Change hostname in DHCP:

config host                                                                     
        option mac '40:3f:8c:xx:yy:zz'                                          
        option ip  '192.168.11.68'                                              
        option name 'MySmartphone'                                              
 

DNS query:

# nslookup 192.168.11.68
Server:    127.0.0.1
Address 1: 127.0.0.1 localhost.

Name:      192.168.11.68
Address 1: 192.168.11.68 MySmartphone.lan

#

No modification or "weird software" needed in client device software. So we already have two authoritative places to define the hostname: on the device itself (if not lacking the capability to do so) and in DNS/DHCP. Every SOHO router I know of adds static name mappings from DHCP into its DNS no matter whether it's a master or forwarding DNS.

Thus, if TP-Link enhances the controller, in my opinion they should just use DNS lookups for unknown devices providing no WiFi hostname so that there is one central place to define names. The client device itself does not need to set or modify its hostname and it does not need to use the DHCP 012 option.

In contrast, adding another database with aliases just for WiFi hostnames not provided by the device would introduce more weirdness in my opinion.

Before you complain that a DHCP hostname is just a hostname for a device based on its IPs: yes. If you rather want to be able to add a note for clients which come and go and where IPs are re-used from day to day like in public hotspots: that's a completely other thing than a hostname.

YMMV, you need not to share my opinion, I have absolutely no problem with this. Since this topic comes up every then and when since years already, I'm now out of this discussion.

Polarice wrote

For us Network Administrators that have use Competitor Network Equipment (eg. Cisco, Ubiquity etc) we have had this feature on those devices, USED IT and LIKED IT. Irrespective if you personally find it the Wrong way to do things. For My Business doing it this way is a Must. I have switched to TP Link Omada for its ease of use.

My critics is not about liking it or not, it's about work-arounds of broken things in unrelated software instead of fixing broken things in broken devices, where fixes belong to. When Omada Controller will become overloaded with features like in Cisco's, UBNT's products (BTW: why don't you use them if they have such features?) etc., it will lose the »ease of use« like some of today's IT products, which have lost the »ease of use« already (a good example is TLS with strong ciphers, which breaks downward compatibility for old Mail Transfer Agents and web browsers). For my part, I just don't buy IoT products which don't support setting a hostname in usual ways, that's DNS/DHCP-assigned or static hostnames.

What's more, tracking devices to identify users is forbidden by law in the EU according to the DSGVO (data protection law). Also, tracking devices and privacy concerns are the reasons why vendors introduced randomly changing MAC addresses of mobile devices years ago (»MAC address spoofing«, much like IPv6 privacy extensions), which will prevent tracking devices by MAC address by using randomized MAC addresses when searching for WLAN networks.

But actually, I don't care about features I won't use as long as they don't break existing functionality - a good example of such a broken functionality in OC is the »integration« of client isolation in a new »guest network« function for SOHO users, who were not able to set up a guest network by normal means. For me as a Network Administrator this silent change did cause hours of support b/c of suddenly broken hotspots, whose junior network admins did turn on »guest network« out of curiousity (we speak of hundreds of hotspots with ten-thousands of users).

In fact I don't care about alias names for MAC addresses in OC as a replacement of hostnames, but I still think it's the wrong place to »fix« it, no matter whether Cisco or UBNT do so in their products.

Polarice wrote

Secondly,

I guessed you would say go to the other devices.

No, I asked why people request features on the grounds that »Cisco and UBNT has this feature, too« instead of buying Cisco or UBNT in the first place. I would do so if I need certain features not present in Omada Controller, but present in Cisco or UBNT controllers. In fact I use UBNT routers in Omada networks for the very reason because of their features not present in TP-Link routers.

If you are putting such energy into defending TP Link and thier lack of inclusion of a simple feature that could actual improve Customers experiance, I would ask....

 

You are terribly wrong; I don't care about such a feature. TP-Link already promised to add this feature in a future version of Omada Controller, they just need some time. I only hope they will prioritize outstanding fixes to real Omada Controller bugs still present before adding work-arounds for bugs in broken IoT client devices. Also, I hope they consider DNS queries to set hostnames defined at the place where such definitions belong to in addition to add aliases manually as a last resort.

Remember, OC is a business-class product and professional network admins can usually work-around such limitations of clients not setting a hostname (except maybe for crappy IoT products not obeying any standards) as I and others have suggested. If such suggestions are not helpful for you, just ignore them and wait for addition of this feature as announced by TP-Link already.

Are you actually employed by them?

[...]

 

We are a Family Business, So I am the IT nerd, Marketing Designer, Electrician, Waiter, Brewer, Delivery Boy, etc.

As a nerd you could recognize posts of TP-Link employees by their »TP-Link« badge below their nickname, so to answer your question: no, I'm not employed by TP-Link, I'm just a user of their business-class products.

Just be patient, TP-Link did announce adding the alias name feature already.

No need to remember them every two weeks by digging out old threads from as far as 2017. Until it has been implemented you could try the suggestions from me and others to set up hostnames in DHCP servers, it will at least work with devices obeying common standards - and yes, it works in almost all business-class DHCP servers this way except probably in DHCP servers used in cheap SOHO devices. For example, it works in UBNT EdgeRouter X, a 49$ business-class device running isc-dhcp and/or dnsmasq, the two most popular DHCP servers in the industry, which are both included in EdgeOS as well as in any Linux system and which is one of the reasons I use UBNT or any other Linux-based router even in Omada networks.