Getting a product serial number in prepare-device for amd64 classic

Has there been any thought to a process to ensure and advise customers on the importance and how they should generate unique serial numbers for their devices? It seems to me that this could become a hairy mess for some customers, especially if they ever let certain devices sit on a shelf disconnected for a length period of time and then bring the device back online, potentially with a duplicate serial number to an existing device.

some points

  • I’m not sure why sitting on a shelf is relevant to this?
  • the serial needs to be unique only with brand/model, not globally
  • afaik the serial-vault makes an assumption that devices have a strong opinion about what their serial is, this means assuming that the brand through manufacturing sets that/makes it available on the device itself OTOH from snapd POV serial is not mandatory in a serial-request, a device can leave out setting proposed-serial
  • the serial-vault could also have a mode where if the device doesn’t specify one it generates a strong random one if the brand doesn’t care (which sound strange on the face of it but as everything it all depends)

I’m not sure why sitting on a shelf is relevant to this?

It’s just an example. Say a device were sitting on the shelf with a certain serial number. Because we haven’t really advised the customer on how they should go about coming up with serial numbers for their devices and the importance of each being unique to their context, it’s possible that they might give another device the same one as the device sitting on the shelf since they forgot about it for some reason. It’s just a hypothetical example, but it’s important not to do.

Another reason “sitting on a shelf” may matter is protecting today’s deployments from possible future requirements of serial number uniqueness.

The Serial Vault previously did enforce uniqueness (AIUI). This was turned off, but not definitively for all time (AIUI). If a device is sitting on a shelf today with a non-unique serial number, and later the Serial Vault turns on enforcement of uniqueness, that system will never obtain a serial assertion and will never be able to install from a secure brand store. Perhaps other currently unimagined software will (reasonably) assume that a serial number uniquely describes a device (isn’t that fundamental to the idea of a serial number?).

So today, we do not forcefully warn/advise: Ensure your serial numbers are unique! (within the project domain). I worry this can set up for problems later.

1 Like

where should we do that?

I can add some wording here Gadget snaps , don’t know if it’s enough/the most relevant place

1 Like

That’s a start and probably worth doing. Thanks for volunteering to do that Samuel.

1 Like

I added this there (Gadget snaps):

If the device service (typically the serial-vault) requires to set registration.proposed-serial to use as the “serial number” (a string, not necessarly a number) part of the identification, then this must be set to a value that is unique across all devices of the brand and model. This also cannot contain /.

Thanks Pedronis.

The serial vault as I understand it does not now require a unique serial number. It does issue a serial assertion with the revision incremented for duplicate serial numbers. But, the SV did at one time require serial number uniqueness. I suppose it might again someday require uniqueness (non-unique serial numbers does not make much sense on the face of it.)

So the above added text does yet not seem to me to give enough advice.

I’m probably not understanding which part of my addition is unclear/insufficient. My advice there is basically:

  1. if must set registration.proposed-serial (which ATM is alway the case with the serial vault)
  2. then must set to something unique

On reread, I see that you are saying set it uniquely. But this follows a complex “if”. It is not clear to me that users can answer the “if” very easily.

Can we not simply say something like: Ensure the serial number is unique across brand/model…

I tried to turn the sentence(s) around, hopefully it’s clearer:

One must ensure that registration.proposed-serial is set to a value unique across all devices of the brand and model and that it does not contain a /. It is going to be used as the “serial number” (a string, not necessarily a number) part of the identification in case the device service supports setting it or requires it, as is the case with the serial-vault.

1 Like

Hi @pedronis @kyleN , This serial is supposed to be unique for every robot right? But this serial is given during building the gadget.

So there should be a way to change registration.proposed-serial after flashing the image, how do i do that?

Hi @rahul-tt,

I’m assuming that you are mixing MODEL_APIKEY and Serial Number. The model api key is gathered manually from the Serial Vault and given to the gadget snap during the building. However, the mentioned registration.proposed-serial is a dynamic configuration that can be set by using snapctl set registration.proposed-serial="" in your prepare-device hook. E.g. you could use device’s mac address(assuming that every device has a unique MAC Address) as of your serial number.

product_serial=\$(cat /sys/class/net/enp1s0/address)
snapctl set registration.proposed-serial="\"\${product_serial}\""

So when you flash your image to your device, prepare-device hook will run on the device not your host computer, then snapd will read registration.proposed-serial configuration and register it as of your serial number.

Thanks for the info, So if I add this

product_serial=\$(cat /sys/class/net/enp1s0/address)

in my prepare device hook then that should automatically set mac address as my proposed serial during the first boot right?

That’s true. But you also need to define network-observe interface in your snapcraft.yaml file. E.g.

hooks:
  prepare-device:
    plugs:
    - network-observe

Finally, make sure that network-observe is automatically connected by using the connections definition in the gadget.yaml file. E.g.

connections:
  - plug: your-gadget-snap-id:network-observe

Thank you very much this is what i wanted

But cant i do the autoconnect in the brand store with viewer permissions too?

I believe, if you are a collaborator or the Publisher for the gadget snap, you could use the available UI in https://dashboard.snapcraft.io/ to enable this initial auto-connection. I believe that the accounts with viewer roles can only download snaps from your own IoT App Store (a.k.a Brand Store)

To autoconnect via the Dashboard you must have role Reviewer in the store in which the snap is publised. Note also that only a subset of snapd interface interfaces are exposed.