• Ioannis 🎱 @ioannis.venizelos ·

    Open questions

    1. Modem connectivity model
      Do devices reach firmware.medido.com directly over the internet (Telefonica APN), or via concentrator proxy? This determines whether concentrator egress IPs belong in the FOTA whitelist or only in the "internal/testing" path.

    2. 172.16.0.0/12 — who uses this?
      Factory provisioning? On-prem concentrator LAN? Should this be on the public NLB SG or only on the EC2 SG for private/TGW access?

    3. Artifact contract
      Should S3 hold:\

    A) FOTA delivery files only (.sfb + manifests), or
    B) Both RED archive (.bin.enc/.sig) and FOTA delivery files (different prefixes)?
    Recommendation: B with prefixes firmware/ (archive) and fota/ (delivery mirror). TLS certificate source for MVP

    1. Block on OPS-909 private CA?
      Or import existing Varity RSA cert to unblock testing?

    2. Draft commit?
      Do we have a branch/MR with the Tom's June implementation? If yes, we should reconcile rather than rewrite.

    3. Legacy FOTA/ path
      Still needed for devices on legacy bootloader (Release_Legacy builds), or only FOTA_SB/ going forward?

    Edited by Ioannis
  • Tom Niessink @medido.niessink ·

    Would be great if it was available from the new vodafone connection as well, see OPS-944 for more on this. But I guess we'll want it to stay local/lan traffic from vodafona APN for which we'll need a new locally hosted zone with override for firmware.medido.com to local IP and the DNS resolver endpoints created for this in the network account should serve this override records to the devices connected over the vodaphone APN.

    Edited by Tom Niessink
  • Tom Niessink @medido.niessink ·

    Do devices reach firmware.medido.com directly over the internet (Telefonica APN), or via concentrator proxy?

    Firmware updates happen with direct connection to the FOTA webserver hosting the firmware. So it's separate from the concentrator mostly except if you reuse the public NLB (cheaper to run but likely harder to manage) to accept the ingress traffic and forward it to the FOTA server.

  • Tom Niessink @medido.niessink ·

    172.16.0.0/12 — who uses this?

    This is the new fodafone APN. Ask Jeffrey/Sander for more on the desirable FOTA connectivity.

    Edited by Tom Niessink
  • Ioannis 🎱 @ioannis.venizelos ·

    QUESTIONS : (Devops)

    1. Does firmware always use hostname firmware.medido.com for FOTA downloads (both secure /FOTA_SB/ and legacy /FOTA/ paths)? Any hardcoded IP fallback?
    2. For Vodafone devices: will they use the same hostname and same URL paths (/FOTA_SB/{version}/...)? Any firmware change needed, or is DNS override enough?
    3. Is 172.16.0.0/12 the expected Vodafone device LAN pool (source IPs we should allow on the private FOTA path)? Or a different range?
    4. HTTPS on private IP: devices connect to private IP but TLS cert is for firmware.medido.com — is that the same as today's legacy behavior (no SNI)?
    5. Any devices that must keep using the public/EIP path after Vodafone rollout, or full cutover?
    6. Still needed for devices on legacy bootloader (Release_Legacy builds), or only FOTA_SB/ going forward?

    ANSWERS : (Firmware team)

    1. It currently always uses firmware.medido.com and then uses /FOTA/ for the legacy bootloader. I have implemented firmware.medido.com/FOTA_SB/ as a place holder, but it can be changed to a different url and path using commands. The idea was to have the legacy builds on the old server and the new builds on a new server I believe.
    2. Yes, I would prefer that the end of the path would stay the same. I can change everything before the version, but if you would change anything on the /{version}/... part, I would have to make changes in the firmware. TL;DR, I can change firmware.medido.com/FOTA_SB/, everything after that is hard-coded
    3. Yes, the ip range of the devices is going to be 172.16.0.0/12 on the Vodafone system
    4. No, currently there is no TLS at all on the firmware server, hence why we need a new one Aparently there is. I am not certain what the TLS infrastructure for that looks like. For the devices I believe we connect to the http endpoint currently. The old build will use TLS, but I would have to check if it can connect to the https endpoint of the old fota server.
    5. Not that I know of. We (firmware devs) need access to the files s.t. we can supply them to production and maybe if we have to remove/add something for testing or breaking bugs, but apart from that only the devices need access
    6. Yeah, this server is meant for the new bootloader only (Release build), not the legacy build. They both have different file formats and we don't want the encrypted fota files to be hosted next to the unencrypted fota files on the same server. For the legacy bootloader we will use the old server for now.

    Above design is based on the feedbacks from answers. Pending to find out if we need to include the private CA now or later.

  • jeffrey @jeffrey.pronk ·

    Looks good to me in general.

    Some small points/questions:

    • I already asked you on the merge request you made in our repo what the purpose is of the archive files?
    • I noticed a question if there is a fallback in the firmware in case the DNS does not work. This is not the case for the FOTA server. That one is only reachable through the DNS as it is not as critical as the concentrator which has a direct ip fallback option.
0% Loading or .
You are about to add 0 people to the discussion. Proceed with caution.
Please register or to comment