retry and fetch an updated firmware url if the first try 401s

[joshk]

this is a fix for #47

if the download returns a 401 it will retry once and then exit

I have also trapped Downloader exits and nil'd UpdateManager state where appropriate

[lawik]

Some notes on port numbering in tests but no major weirdness :)

[joshk]

@jjcarstens I'm wondering if maybe the better way to approach this issue is to have UpdateManager report back to the Socket on the status of the update (rescheduled, ignored, download error), and then Hub can decide if it sends the update again.

Thoughts?

[lawik]

For time being out of whack, one solution is to have the device include what they think the time is in join.

Then the server can tell whether the client is confused or has an expired thing. It can even pass down the current time. This could be an optional mechanism for getting the time (trust the server) which is helpful for a Pi for example. But mostly it lets one tell the difference between bad auth and being out of sync.

[jjcarstens]

A noble thought @lawik, but I don't think that will work. Time is a required component of the connect for a couple reasons:

• Device certs - the SSL stack on device may not even get to a connect attempt because it will check the server cert first and believe it is expired when it compares its terribly off device time
• Shared secret - Time is a component of the HMAC to assert validity. To detect the time is off and say "o, that's okay. Here's the time you should use" would be an anti-pattern negating the HMAC a bit

However, the middle ground is a decent idea to just include the date header in the rejection always. Though I am unsure if we could get that early enough in the SSL stack. Though Frank is currently working on a time server solution that could be used for conditions like this too which might be the better play to keep the time concern separate

[lawik]

Shared secret has this issue. The SSL is not failing, it gets a 401 and if we knew what it thinks the time is we can detect it and give a better "why is NervesHubLink not up"-experience.

My PIs have this and log a ton of 401s on every restart. My guess is that they generate times at UTC until NervesTime syncs. Or something. Time is not 1977-01-01 :) SSL works it seems

[joshk]

@jjcarstens I've reworked the logic of this feature to now send updates from the UpdateManager to the pid that called it. These updates are then sent to Hub, which can then update the registry and decide if there are further actions to take, like sending a new update to the device.

I think this is a better setup, and there are options to improve it further.

[joshk]

@jjcarstens is it ok to use elem(from, 0)? or is this bad practice?

[jjcarstens]

If we're not doing anything with the {:error portion of the tuple, why have it? We could just simplify and make it an atom return

[jjcarstens]

That or change the success condition to be {:ok, result} and we always return the same structure of %{result: :ok | :error, reason: reason}

[joshk]

there are six events that can be sent from the UpdateManager to Socket are, the update ...

• started
• was ignored
• was rescheduled
• completed successfully
• failed due to a 401 error (download_unauthorized)
• failed due to a non fatal download error (non_fatal)

I had modelled this as ...

• :started
• :ignored
• {:rescheduled, ms, rescheduled_to(ms)}
• :completed
• {:error, :download_unauthorized}
• and {:error, :non_fatal}

I could change :completed to {:ok, :completed} to match the structure of the error cases, although the :ok is kinda superfluous information. It would also mean that :ignored and :started would need to change.

In Hub each of these cases would update registry in slightly different ways.

Thoughts?

I also realized that I hadn't accounted for {:rescheduled, ms, rescheduled_to(ms)}