I don't recall the full history of the ConfigureServiceForProfile API, but IIRC, it was initially created for managing WiFi services but may have later extended to support other types of service. Manager::UpdateProviderMapping() basically indicates that it only supports WiFi, VPN, WiMAX and Ethernet w/ 802.1x. So  regular Ethernet isn't supported.

+stevenjb may recall more context here and know better how chrome makes use of ConfigureServiceForProfile

For context: We're trying to save static ip config and/or dns nameservers and can't do so for ethernet with authentication=none.
Do you have any ideas how we could circumvent this?

Any update on this? This is blocking two other P1 bugs

voit: yes, this is an issue for a significant enterprise customer and it's somewhat embarrassing that Chrome OS is losing simple static IP address configuration.

Can we please prioritize the fix here?

benchan@: Do you have anyone working on shill who could tackle this or knows why it's not possible in the first place.

+kirtika@

I suspect this use case was never imagined. It would be ideal if Shill were to support this in ConfigureServiceForProfile, but if we need to special case saving IPConfigs and Nameservers for Ethernet in the NetworkHandler code, we could probably do that instead.

Working on a fix.

IIUC, there are two properties that users want to persist for Ethernet: Static IP and Nameservers.

The problem with storing Ethernet configurations is when to apply them. There are two options:

a) Apply to any Ethernet connection.
b) Apply to a particular MAC address.

From a UI perspective, b) would be pretty confusing with our current UI, especially if users expect (a). Also, allowing users to identify multiple Ethernet configurations would be a significant change.

We already persist EAP properties for Ethernet, using a special EthernetEAP configuration. I don't actually know when/how those are applied in Shill. We might be able to just use that profile entry for Static IP and Nameserver settings and apply those to any Ethernet connection.

Do we have information on specific use cases?
Is this primarily an Enterprise request, and if so is the intention to provide policy settings, or do we need UI for this?

The idea was to apply to an Ethernet connection, but pass the associated storage ID to shill under the hood, without exposing the MAC to the user.

I'm not sure I follow. If the value is going to be different depending on which ethernet adapter is plugged into the device, that is going to be confusing any way we do this.

Do we have information on specific use cases?
Yes, customer is using on digital signage devices (kiosk mode) - Chromebox or bas with built in ethernet.

Is this primarily an Enterprise request, and if so is the intention to provide policy settings, or do we need UI for this?
Pushing static IP via policy is a chicken/egg issue I don't think we should go down. Device would need to use DHCP to get an address, pull policy and then jump to the static IP. Also all devices in a given Org Unit in the admin console get same device policy so how do you then assign an IP to a device?

In this customer's case they just need to be able to manually assign static IP on the device and keep it working. Do note though that they will be pushing proxy information for Ethernet via policy.

bas should be Chromebase above.

OK, thanks, that helps.

I think that we should treat Ethernet as a single service, just like we do for EAP.

For this use case, if the device gets plugged into a different adapter, the user probably wants to keep the same static IP config. Even if they don't, tracking configurations by MAC or other identifier is going to be confusing and difficult. Requiring a manual configuration change does not seem unreasonable, and a quick survey of colleagues suggests that would be the expected behavior.

For Nameservers I think the same logic applies (even more so).

Ok, that makes sense. Ben, WDYT?

While we may assume a single Ethernet connection per device for now, we still need a way to gracefully handle the situation when two or more adapters are plugged into the device.  While I see the rationale in #19 that we want to apply the same static IP and nameserver configuration when a different Ethernet adapter is used on a device (or if the MAC address of the same Ethernet adapter may change across reboot), we should also be careful not to apply the same static IPs when two Ethernet connections are established.

One approach is that we can persist the static IP and nameserver configuration to a shill profile entry keyed with a MAC address (which is likely the one with the built-in Ethernet or the external Ethernet adapter used at the time of configuration). During the profiling matching, we can do a less precise match by ignoring the MAC addresss when only one Ethernet connection is present. If multiple Ethernet adapters are present, the MAC address can be taken into account -- it's still not as precise as we'd like, but a good approximation.

There would be a *lot* of UI work required to handle more than one Ethernet connection. Is this really something we plan to support? In the past we have decided that Shill would always just pick one and use that.

If we are concerned about a profile entry identified as just 'Ethernet', we could do something similar to what we do for EAP which has a profile entry named "Ethernet EAP Parameters" with an special type of EthernetEAP which we merge with the Ethernet service properties on the Chrome side. I'm not sure how Shill handles the EAP properties, but I would expect them to be applied to any/all Ethernet services.

I think it's entirely reasonable to map the static IP to a MAC address and use that IP on any Ethernet connection (except 802.11x maybe?) the device makes.

Chrome OS devices with > 1 Ethernet adapter should be pretty rare, not something we should spend a lot of time focusing on (I literally can't think of a use case for it since we don't do tethering or routing).

I wasn't proposing a full UI support in #21.  On the platform side, while it's reasonable to make the assumption that there is only one Ethernet connection supported for most cases, we still need a graceful handling when the assumption is violated (same principle applies to other assumption like single WiFi per device). There is a subtle difference between "fully support" and "gracefully handle".

If we want to simplify things, we can just not enable more than one Ethernet connection at any time, so our assumption is always satisfied. But applying the same static IP to two Ethernet connections just seems wrong to me.

Re comment #24 - If we ever support more than one Ethernet connection at the same time, I would expect that to show up in the UI, and even minimal support would require major re-factoring.

I agree that applying the same static IP to multiple connections would be incorrect, I am just suggesting that that would be the least of our difficulties :)

Re comment #23, I am somewhat biased by my personal experience where we commonly use USB -> Ethernet connectors for chromebooks. Each adapter has a unique MAC, and it's a use case that we would need to handle. For devices with internal Ethernet, there will generally only be one Ethernet device ever, so MAC mapping wouldn't really matter anyway.

Friendly ping - any progress on fixing the issue?

It's blocking important bug https://crbug.com/820213 that's should be fixed by our team asap as this one is resolved, so it would be great to have expectations for fixing this one to know when we'll need to plan the following work on our side.

Working on it. Should have a fix in within the next few days.