New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 676195 link

Starred by 64 users

Issue metadata

Status: Verified
Closed: Dec 2017
EstimatedDays: ----
NextAction: ----
OS: Chrome
Pri: 2
Type: Feature

Sign in to add a comment

Regarding Issue 126802, UI for creating Chrome Device hostnames, can this be in the Admin control panel

Reported by, Dec 21 2016

Issue description

UserAgent: Mozilla/5.0 (X11; CrOS x86_64 8872.70.0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/55.0.2883.87 Safari/537.36
Platform: 8872.70.0 (Official Build) stable-channel panther

Steps to reproduce the problem:
1. Open network router
2. Search for connected equipment
3. No information on Chrome OS devices

What is the expected behavior?
The ability to give devices on the network a name so they can be easily identified. Easier than identifying by IP address.

What went wrong?
They don't currently do this,

Did this work before? No 

Chrome version: 55.0.2883.87  Channel: stable
OS Version: 8872.70.0
Flash Version: Shockwave Flash 23.0 r0

I'm unable to comment in the other thread, but I would like to request that this ability to add hostnames, if it is ever added, be added into the G Suite administration panel under Chrome Devices so I can assign hostnames to all my devices from a single convenient location.
Labels: -Type-Bug Type-Feature
David to prioritize this FR

Comment 2 by, Jan 2 2017

Blockedon: 126802
We will def look into this once the source item is resolved.

Comment 3 by, Jan 2 2017

Status: Assigned (was: Unconfirmed)

Comment 4 by, Jan 2 2017

Labels: -Pri-2 Pri-3
This is a HUGE need for us.  Please, Google, help with this situation.
I would like to be able to do this also for my devices.  Please add the feature.
Without having the hostname configurable and available, it makes troubleshooting wireless, dhcp, etc issues difficult.  Please add this so that we can add a hostname to our devices and then identify them in our router, switch, dhcp, etc client lists where connected hostnames are displayed.  Thanks!
This is a HUGE need for us, also.  Please, Google, help with this situation.
This would be a great help to us as well. Please Google.

Labels: -Pri-3 Pri-2
The policy will be surfaced as a string in the admin UI. Values:

(default) no policy:               No DHCP option 12 attached - Existing behavior
Policy=xxx                         xxx
Policy=${ASSET_ID}                 Device's asset ID [1]
Policy=${SERIAL_NUM}               Device's serial number
Policy=${MAC_ADDR}                 Device's MAC address
Policy=xxx+VAR+xxx                 xxx+VAR_VALUE+xxx

Blockedon: -126802
So if we say that we have only 3 variables (ASSET_ID, SERIAL_NUM, MAC_ADDR) and we do simple case-sensitive string substitution for them, then we actually have only two options: 

(default) no policy:               No DHCP option 12 attached - Existing behavior
Policy=xxxVARxxx                 xxxVAR_VALUExxx

But we would need to validate hostname after, and this brings us to question "What to do if resulting hostname is invalid?". We do not want to set invalid host name, as it might either result in rejected DHCP request, or be a way to exploit DHCP server vulnerabilities. And at this point there are few ways we can use to indicate errors: system logging and setting some message-containing host name.
I'd like for Cpanel to detect invalid hostnames, since this is the best place for the user to notice the error.

If an invalid hostname somehow makes it into the policy, shill can drop it and log an error.  This shouldn't normally happen, of course.


1) I don't see any validation of kHostnameProperty (hostname_) happening in $SHILL/dhcp/ so we should check that.  Same for vendor_class_.  Seeing string properties from Chrome getting copied directly into subprocess command-line arguments makes me nervous.

2) DhcpProperties::kHostnameProperty and DhcpProperties::kVendorClassProperty should probably be moved into dbus-constants.h in the system_api package so that Chrome can use them.
Re: cpanel detection, is this actually viable if we do client-side substitution of things like Asset ID?
Btw, Asset ID seem to have no validation - it can be arbitrary long, start with digits, contain weird UTF symbols, etc.

I believe we should have defend-it-depth here: sanity checks on at least 3 layers: ChromeOS (shill), Chrome (layer that applies policy) and CPanel (to prevent absurd values in policy).
If the Asset ID field is less restrictive than the Hostname field by design, I would suggest substituting (say) '_' for any disallowed characters found in the Asset ID, when shill creates the parameter to pass to dhcpcd.

For substitutions like "append the last 3 octets of the MAC address" (found in the doc we discussed over email), that should not present a validation problem, unless the final hostname string is too long.
tbh I would prefer not to work too hard on ensuring sanity of hostname. The admin is responsible for creating hostnames that fit into whatever use case they want to aim for. We can add warnings to admins so that they understand what they are getting themsevles into. But wouldn't do things like changing non-characters into _ and such. Seems quite overkill and unpredictable from an admin's perspective.
I normally wouldn't care either, but letting bad strings percolate into dhcpcd parameters or DHCP options could create security issues for software that isn't designed to handle them.
"_" isn't valid in DNS labels, only [-0-9a-zA-Z]
This is a limitation of hostnames, not a DNS limitation.

(DNS is not just for hostnames and hostnames are not just in DNS)
Project Member

Comment 21 by, Dec 4 2017

The following revision refers to this bug:

commit 339c49a48ae67a0a070c3f9c954a5a52c54057e1
Author: Denis Kuznetsov <>
Date: Mon Dec 04 01:03:37 2017

Add a policy to specify device Hostame in DHCP request.

Bug:  676195 
Change-Id: I450fcf3416f620ce9867d55ea225c610583d1169
Reviewed-by: Steven Bennetts <>
Reviewed-by: Julian Pastarmov <>
Reviewed-by: Sergey Poromov <>
Commit-Queue: Denis Kuznetsov <>
Cr-Commit-Position: refs/heads/master@{#521241}

Status: Fixed (was: Assigned)
Hi,  may I know where's the fix or feature got applied? Is it in the Admin Console? Any help and answers will be much appreciated. Thank you!
You configure a device name in Admin Console.
Then you take some router that supports  and see that after device connects to router, you check that there is a dhcp client connected with a given name.

Comment 25 by, Jan 29 2018

The admin console setting is planned for end of March, early April. We will update this bug once the setting is surfaced.
are you guys still on track to have this feature available by end of March, early April?
as you commented on #25, 
Do you have any update that can be shared with the customer?

Comment 28 by, Apr 12 2018

The change is available client-side but still not surfaced server-side. Due to some delays, we had to punt to Q2. So please expect this by end of this quarter.
Are there any updates on the availability of this feature please?
Is this feature available as of August 2018? If so please indicate where it is configured. Thanks.
Status: Verified (was: Fixed)
Cheers everyone,

I have a technical case open (16780036) requesting an update on this matter and public facing documentation on how to perform the procedure in his devices.  What's the feedback we have to provide in this matter?
Technical work on this is completed. Please reach out to marcuskoehler@ if you need additional information/public-facing docs and he can help coordinate that effort.
Any there any instructions on where this is configured / rollout schedule please?

Comment 35 Deleted

Project Member

Comment 36 by, Sep 3

The following revision refers to this bug:

commit 85203f2094a0673955fcef4716a79bec4a604e9c
Author: Denis Kuznetsov <>
Date: Mon Sep 03 14:24:11 2018

Make policy description public

Bug:  676195 
Change-Id: I75ba73a7ee75d446c8d5b79d8f4c45aed569940d
Reviewed-by: Sergey Poromov <>
Commit-Queue: Denis Kuznetsov <>
Cr-Commit-Position: refs/heads/master@{#588388}

 Issue 593574  has been merged into this issue.

Sign in to add a comment