If requested, report network interfaces to management server.

chrome/browser/policy/proto/cloud/device_management_backend.proto

Index: chrome/browser/policy/proto/cloud/device_management_backend.proto
diff --git a/chrome/browser/policy/proto/cloud/device_management_backend.proto b/chrome/browser/policy/proto/cloud/device_management_backend.proto
index 2d1e856dab3db5dcb64038b84325ff150004ef80..c367f52e8bcb8ca816555e8807516524fa50d513 100644
--- a/chrome/browser/policy/proto/cloud/device_management_backend.proto
+++ b/chrome/browser/policy/proto/cloud/device_management_backend.proto
@@ -359,6 +359,18 @@ message DeviceLocation {
   optional string error_message = 10;
 }
 
+// Details about a network interface.
+message NetworkInterface {
+  // String describing the interface type.

[pneubeck (no reviews), 2013/07/04 15:51:48]

This should refer to the list of possible strings.

Description of the respective Shill property: shill/doc/device-api.txt

List of constants: third_party/cros_system_api/dbus/service_constants.h

[Mattias Nissler (ping if slow), 2013/07/11 17:41:46]

Made an enum and translation table instead.

+  optional string type = 1;

[Bin, 2013/07/10 18:02:49]

Once we start collecting network interface address, we will show them on CPanel,
and maybe add a function to export them. We need to document the possible values
for the type.

The type will be Flimflam types defined below? If yes, can we document that in
the proto? Ideally, the type should be an enum. But if they are taken from the
type constants below, then I am fine with that too.

// Flimflam type options.
const char kTypeEthernet[] = "ethernet";
const char kTypeWifi[] = "wifi";
const char kTypeWimax[] = "wimax";
const char kTypeBluetooth[] = "bluetooth";
const char kTypeCellular[] = "cellular";
const char kTypeVPN[] = "vpn";

[Mattias Nissler (ping if slow), 2013/07/11 17:41:46]

Made an enum.

+
+  // MAC address (if applicable) of the corresponding network device.

[Bin, 2013/07/10 18:02:49]

There are three MAC address formats:

MM:MM:MM:SS:SS:SS
MM-MM-MM-SS-SS-SS
MMM.MMM.SSS.SSS

We are using the first one? Can we document that?

[Mattias Nissler (ping if slow), 2013/07/11 17:41:46]

Done.

+  optional string mac_address = 2;

[pneubeck (no reviews), 2013/07/04 15:51:48]

encoding of the MAC address?

[Mattias Nissler (ping if slow), 2013/07/11 17:41:46]

Done.

+
+  // MEID (if applicable) of the corresponding network device.
+  optional string meid = 3;

[Bin, 2013/07/10 18:02:49]

If I remember correctly, MEID is used for CDMA devices and IMEI is used for GSM
devices. Are all 3G Chrome devices come with CDMA only and will be that case in
the future too? Or should we rename it to mobile identifier to cover both cases?

[Mattias Nissler (ping if slow), 2013/07/11 17:41:46]

I added a separate field for IMEI, so you have whatever identifier is applicable
and also know which one it is.

Caveat: These IDs come directly from the connection manager, and I can't confirm
the format for all Chrome devices. Greg, do you know whether these are in
standard format?

+}
+
 // Report device level status.
 message DeviceStatusReportRequest {
   // The OS version reported by the device is a platform version
@@ -383,6 +395,9 @@ message DeviceStatusReportRequest {
 
   // The device location.
   optional DeviceLocation device_location = 7;
+
+  // List of network interfaces.
+  repeated NetworkInterface network_interface = 8;
 }
 
 // Report session (a user on one device) level status.