I was able to repro the issue, upgrading from v62 to v64 reverted to DHCP for Ethernet connection.

Done additional testing - 
1. Issue only happens if network is set up using device policy
2. Wasn't able to repro with update to v65 - either v62-v65 or v64-v65. Not sure if fixed or coincidence 

I was able to verify that we still see the issue on our Beta devices that recently updated from 65.0.3325.107 to 66.0.3359.79.  I cannot test the Primary devices as they are only using the Stable Channel of 64.0.3282.190.

I assume this is strictly about Ethernet configurations?

Could you log in and file a feedback report after an update reproduces the issue? 

Also, would it be possible to attach the device policy being used? (You can also email it to stevenjb @ chromium.org).

+emaxx@ - Do we re-apply device policy after an update? I seem to recall that under certain conditions we remove an existing configuration before applying the policy configuration, which could cause this.

+pavol who also may be familiar with how we apply device policy network settings

Definitely want to understand the repro steps (what exactly is configured via device policy? I didn't think device policy would let you set static IPs. It doesn't really surprise me if you have a device-policy configured network, you tweak some setting for that network, and then that setting is lost later when we apply a policy update.

Could you describe what exactly you've configured through policy and what you've configured manually on the device?

The contents of the OpenNetworkConfiguration and DeviceOpenNetworkConfiguration entries from chrome://policy would be very helpful. Please make sure to blank out any personal information that might appear there before posting it here.

Thanks a lot!

Yes, these are strictly Ethernet configurations.  We have Wifi turned off due to restrictions on the environment.  We currently set the static IPs manually on each device prior to log in.  The static IP is good until the device restarts from an update.  After the restart, we lose our internet connectivity on the device because the IP reverts back to DHCP so we have to set the IP information again to regain Internet connectivity.  I will get the device policy today and attach to this ticket.

Here are a couple of our device policies.  00155 is a BETA device and 00106 is a STABLE device.

Deleted: policies_00106_clean.json 18.3 KB

policies_00106_clean.json 18.3 KB View Download

Deleted: policies_00155_clean.json 18.2 KB

policies_00155_clean.json 18.2 KB View Download

00106 is currently on version 64.0.3282.190
00155 is currently on version 66.0.3359.102

I don't see anything suspicious in that policy, and I can't reproduce the problem after reboot with a test account with an Ethernet policy. I have that set up with a static IP config so I will wait for the next update (I am on the Dev channel so it should be pretty soon) and report back.

The only thing I can think of is that one of the scenarios triggering deletion of an existing Shill entry is being triggered after an update here:

https://cs.chromium.org/chromium/src/chromeos/network/policy_applicator.cc?type=cs&q=PolicyApplicator::GetEntryCallback&l=127

I will put up a CL to log that info by default to chrome://device-log so that it will show up in feedback reports so we should get more info in the future.

I have 2 remaining BETA devices on 65.0.3325.89 that I can upgrade to 66.0.3359.79 to test again.  Are there any logging switches or anything that I can turn on to capture anything pertinent while upgrading those 2 devices?

Not currently unfortunately. I'll try to get the logging changes merged to
66 though so that the next 66 update will log the issue, assuming it is
what I think it might be.

I was able to reproduce it upgrading device (Stout) from 65.0.3325.199 to 66.0.3359.117. Steps:

1. In CPanel, restrict all device networks except Ethernet
2. Enroll device to domain
3. Login as user
4. Turn off DHCP (Settings > Network > Ethernet > Network > Configure IP address automatically)
5. Go to about://chrome and upgrade the device, reboot

After upgrade and reboot "Configure IP address automatically" parameter is ON.

Repro steps are in #c14

Hello!
This bug is receiving this notice because there has been no acknowledgment of its existence in quite a bit of time.
- If you are currently working on this bug, please provide an update.
- If you are currently affected by this bug, please update with your current symptoms and relevant logs.

If there has been no updates provided by EOD Wednesday, 12/12/18 (5pm EST), this bug will be archived and can be re-opened at any time deemed necessary.

Thank you!

Still seeing the issue on my Beta devices:
Google Chrome Version	
71.0.3578.71
Platform Version	
11151.45.0 (Official Build) beta-channel panther
Firmware Version	
Google_Panther.4920.24.26
TPM Firmware Version	
422

raising to P1 as a major customer is now hitting this issue and cannot switch to DHCP. Assigning to atwilson@ for routing as pmarko is OoO till EoY.

It seems we have clear steps to reproduce this and that it tends to occur during AU.

Logs / timeline / screenshots are available at:

https://drive.google.com/corp/drive/folders/1phAQlgeVSFinxEVrVczffhT5j73vG56g

Drew, can we get this in front of someone soon? It's a major customer facing the issue.

Sergey, PTAL - also, route to the networking team if we think it's Shill itself losing the static IP config rather than chrome.

None of the provided policies in this thread actually define static IP configs. And in that case we default to DHCP anyways (according to go/onc). And if the network is specified via policy, we don't take any user settings into account anyway, even though the UI was still visible.

voit@ recently/currently fixed that UI bug (847429 + 869199) and AFAIK also actually implemented proper support for IPConfig/Nameservers in policies (@voit: did this even work before? Or was it just UI/recommended changes?)

IIRC m66 was the version with the new webUI, we might just be talking about the UI bug voit@ is currently working on.

We still have problems with IPConfig/Nameserver settings/policies for ethernet networks without authentication. @voit: Do you know when this 'special handling' of ethernet networks without auth landed (or can you point me to the code)? Even with your fixes, are we able to set IPConfig/Nameservers for ethernet without auth at all (through settings UI, not through policy). I could see how this would erase IPConfiguration through updating chrome versions, but then it should also not be possible to set them again at all.

- We don't and never have allowed setting of static IP via admin console policy, ONC may support it but we've never allowed it on the server-side.

- Why in the world would we ever purposely erase user-provided static IP addresses? We should never do that.

This seems like it should be a pretty straightforward automated test (set static IP address, upgrade version, confirm static IP address still in place). Can we make that happen so we are catching these kind of regressions?

>> Why in the world would we ever purposely erase user-provided static IP addresses? We should never do that.
I guess that was not intentional and more a side-effect of some other changes.

@voit: could you file a bug for this "can't store settings for ethernet with Authentication=none" and cc me, benchan@ & ljusten@. This problem is now blocking multiple efforts (chromad, your changes to nameservers/ipconfig in policy, IPconfig in user settings).

voit: any update on these steps? We have a large customer hitting this issue and need to show progress on resolving.

hendrich, will your fix for  crbug.com/847429  cover this as well?

voit@ created the fix for  bug 847429 , but that doesn't solve the problem for this bug here. Bug 916041 should solve that, but I don't see a lot of movement there. The people working on shill should have more knowledge/background to that problem.

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