See screen shots in drive share: https://drive.google.com/drive/folders/1QCOkJ1pKYhOL5XxCkEfwRR-6u9ySXRkU?usp=sharing

Deleted: Screenshot 2018-07-30 at 6.00.46 PM (2).png 181 KB

	Screenshot 2018-07-30 at 6.00.46 PM (2).png 181 KB View Download

Hey Pavol, can you triage or route this one.

Just in case it slipped your attention

Alex, do you remember if we tried to repro this and could not, or if we did not try to repro this, or if we successfully reproed this?

I think we've been doing something here but can't remember.

I don't have access to https://storage.googleapis.com/public_pac/proxysample.pac so I don't see what's configured there, but I guess the ProxySettings should not influence the DNS settings!?

Regarding DNS settings: we have "NameServersConfigType" and "StaticIPConfig" in https://chromium.googlesource.com/chromium/src/+/master/components/onc/docs/onc_spec.md. which you probably want here.
However, this seems not to be fully implemented. The UI doesn't update, for example. There is some logic to transfer these values to shill, but I don't know if that is working at all and the ONC validator is probably not ready for this either (https://cs.chromium.org/chromium/src/chromeos/network/onc/onc_validator.cc?rcl=d8026346bbf3912253dde2af73266153481c6be4&l=626).
So this is probably a feature request and not a real bug. It could probably be a nice starter-project for the upcoming nooglers, I'll take with Drew about it.

Could you share config example? So I could test it on Chromad. Thanks!

{
   "GlobalNetworkConfiguration": {},
   "NetworkConfigurations": [ {
      "Ethernet": {
         "Authentication": "None"
      },
      "GUID": "{test2222222}",
      "Name": "CorpEthernet",
      "Type": "Ethernet",
      "NameServersConfigType": "Static",
      "StaticIPConfig": {
        "Type": "IPv4",
        "NameServers": ["8.8.8.8"],
        "IPAddress": "123.123.123.123",
        "RoutingPrefix": 8
      }
   },
   {
      "WiFi": {
        "SSID": "GoogleGuestPSK",
        "Security": "WPA-PSK",
        "Passphrase": "***********",
        "AutoConnect": true
      },
      "GUID": "{test11111111}",
      "Name": "CorpEthernet",
      "Type": "WiFi",
      "NameServersConfigType": "Static",
      "StaticIPConfig": {
        "Type": "IPv4",
        "NameServers": ["8.8.8.8"],
        "IPAddress": "123.123.123.123",
        "RoutingPrefix": 8
      }
   } ]
}


ONC validator requires "StaticIPConfig" to have "IPAdress" and "RoutingPrefix", which I guess is not what we want here. 

Looking at /var/chache/shill/default.profile, I can see that the "StaticIP.NameServer" is correctly applied for the WiFi network, but not for the ethernet network. The UI remains unchanged for both.


@aluong: Do you explicitely want to set a specific DNS name server or do you just want to prevent users from changing the settings?

Yep, does not seem to work at all.

re: #8 - Customer wants to prevent users from changing settings. 

Do we need another crbug or can we make this a feature request?

It would helpful to allow a customer to configure a policy to:
- Set DNS servers and not allow users to change
- Block users from changing DNS settings, preserving existing DHCP/DNS settings

re: #12: this is fine, we don't need another bug.
We will probably have one of our upcoming team members tackle this as his first task (should start next week).

@marcuskoehler: Can you take care how this should look/work like on the server-side or pass on to server-side PM/eng. Client-side implementation should be independent.

Hi Alexander - just checking since it's been a few weeks so hoping we have an engineer working on this? :)

Hi voit@google.com, was wondering if there any update or movement on the bug? 

Hi, I'm working on fixing behavior of IP address and DNS settings for another issue  https://crbug.com/847429 
This one is closely related, so I certainly will finish them together soon. 

Thank you so voit@google.com! We would like to communicated an M72 release date to our customer for this - is that feasible?

Yes, M72 sounds feasible.

Checking in here if there is something that we can test on DEV or CANARY?

Hi benchan@ and stevenjb@. Maybe you have an idea why shill handles ethernet networks without authentication differently from other network types?

I get a crash:

{
   "dbusErrorMessage": "service type is unsupported",
   "dbusErrorName": "org.chromium.flimflam.Error.NotSupported",
   "errorDetail": "Config.CreateConfiguration Failed: org.chromium.flimflam.Error.NotSupported: service type is unsupported",
   "errorName": "Config.CreateConfiguration Failed"
}

 when calling dbus method ConfigureServiceForProfile. Check out the shill code links below.

https://cs.corp.google.com/chromeos_public/src/platform2/shill/manager.cc?q=platform2/shill/manager.cc&sq=package:chromeos_public&g=0&l=2298

https://cs.corp.google.com/chromeos_public/src/platform2/shill/manager.cc?q=platform2/shill/manager.cc&sq=package:chromeos_public&g=0&l=2647

https://cs.corp.google.com/chromeos_public/src/platform2/shill/manager.cc?q=platform2/shill/manager.cc&sq=package:chromeos_public&g=0&l=906

It's currently one of the causes of ethernet networks not being properly handled by policy settings (we can't save managed settings for these networks).

+aghuie (PM networking) -me

Zakhar, are we still on track for M72 with this given that the branch is today? This is a blocker for one of our pilot programs. Is there anything we can do to help?

Hi, I think right now shill's implementation specifics do not let us implement it for Ethernet networks with authentication type "None". you can take a look at comment 23 for details.

We have a solution for the WiFi networks and Ethernet networks with "8021X" authentication type. But seems, that it's not what was originally reported in this bug. 

You can ask hendrich@ in person for more details, as we discussed it with him.

Yeah, we tested it for different configs just a few minutes ago. While the UI was blocked for wifi, we couldn't get it to work with unauthenticated Ethernet. I'll ask around to see how this can be resolved.

Reassigning to poromov@ as his team is going to handle this.