<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <p><br>
    </p>
    <br>
    <div class="moz-cite-prefix">On 05/03/2018 10:14 PM, Rob Austein
      wrote:<br>
    </div>
    <blockquote type="cite"
      cite="mid:20180504031448.265762003E27F6@minas-ithil.hactrn.net">
      <pre wrap="">On Thu, 03 May 2018 21:31:59 -0400, Michael wrote:
</pre>
      <blockquote type="cite">
        <pre wrap="">
I'm getting this message on both of my alphas...can anyone tell me
what I'm doing wrong? I've double checked the PIN.... same one I use
to log into the console

Firmware tarball /usr/share/cryptech-alpha-firmware.tar.gz content:
-rw-r--r-- root/root    5324179 2017-12-15 09:31:00 alpha_fmc.bit
-rwxr-xr-x root/root      60644 2017-12-15 09:31:53 bootloader.bin
-rwxr-xr-x root/root    1455424 2017-12-15 09:31:53 bootloader.elf
-rwxr-xr-x root/root     494344 2017-12-15 09:31:55 hsm.bin
-rwxr-xr-x root/root    2465640 2017-12-15 09:31:55 hsm.elf
-rw-r--r-- root/root       2529 2017-12-14 17:32:43 tamper.hex
-rw-r--r-- root/root       3340 2017-12-15 09:32:01 MANIFEST
Uploading hsm.bin from /usr/share/cryptech-alpha-firmware.tar.gz
Initializing management port and synchronizing with HSM, this may take
a few seconds
wheel PIN:
Device does not seem to be ready for a file transfer (got
'\r\n\r\nAccess denied\r\n\r\nUsername: ')
Access denied
</pre>
      </blockquote>
      <pre wrap="">
Make sure it's the right username ("wheel", not "user" or "so").</pre>
    </blockquote>
    <font size="-1">I will double check.</font><br>
    <blockquote type="cite"
      cite="mid:20180504031448.265762003E27F6@minas-ithil.hactrn.net">
      <pre wrap="">

You may be running a version of the bootloader old enough that it
doesn't understand the current keystore format, and therefore gets
confused when looking up the PIN.  If so, it will think there is no
PIN set and will therefore fall back to the compiled-in last gasp PIN,
an annoying string which you can find in the source.
</pre>
    </blockquote>
    <font size="-1">Yes , I considered upgrading the bootloader. I
      assume you are referring to the very long PIN...</font><br>
    <blockquote type="cite"
      cite="mid:20180504031448.265762003E27F6@minas-ithil.hactrn.net">
      <pre wrap="">
If none of that works, you can re-flash via a programmer, or you can
try wiping the keystore to put it into a known state in which
everything will use the compiled-in last gasp PIN, then re-flash.
</pre>
    </blockquote>
    <font size="-1">I have the STLink installed and used it to verify
      the .bin file.(part of the acceptance test)  I have not used it
      yet to reflash. Good call on the keystore, i dont really have
      anything I can always rebuild.</font><br>
    <blockquote type="cite"
      cite="mid:20180504031448.265762003E27F6@minas-ithil.hactrn.net">
      <pre wrap="">
If you have keystore content you want to preserve across such an
operation, you can use cryptech_backup in "soft-backup" mode.

There's newer packaged firmware than the above on apt.cryptech.is if
you don't feel like building the current firmware yourself.
</pre>
    </blockquote>
    <font size="-1">One curious thing, if I use the "firmware upload" 
      command while in cryptech_console, I see the blue LED flash as
      described in the documentation indicating the bootloader is being
      accessed. Calling cryptech_upload from the terminal does not seem
      to reset to the bootloader (no flashing blue LED)</font><br>
  </body>
</html>