Dfu-programmer fails with "no device present"

Nitrokeys
1

I’ve just tried to update the firmware (for the first time) according to following instructions:

https://www.nitrokey.com/en/doc/firmware-update-storage

After setting to upgrade mode, the app says “Nitrokey not connected”. When invoking:

dfu-programmer at32uc3a3256s erase

from DOS terminal (Windows 8.1), it fails with following error:

dfu-programmer: no device present.

How to fix this?

Thanks!

Marc

2

Hi Marc,

can you send us the USB enumeration of the PC with the connected stick.

A tool like
http://www.uwe-sieber.de/usbtreeview_e.html
shows that.

3

Hello Rubo,

Sorry for the late reply. I’ve managed to upload the new firmware from a virtual machine. I recall seeing a couple of devices using USBDeview.exe. Removing them as recommend did not help. Please let me know if you still want to see the USB enumeration or other diagnostic data.

Marc

4

Compile the binary yourself. Don’t use the one from your package repository. It worked for me that way.

5

Another thing worth a shot is running command line window with Administrator privileges and then running the programmer. Under Linux such action is necessary for successful flashing (running with sudo).

6

Not exact on Windows, but on other systems where I have been able to get dfu-programmer up and running:
a) use lsusb to get the Bus (x) and the Device Number (y)
b) use sudo dfu-programmer:x,y erase for the first step of firmware upgrade.
Without sudo you will not have the HW access , and the device might not be found with x,y given

7

Greetings. I am having the same issue and would really appreciate help.
After the “erase” command succeeded, dfu-programmer reports:

dfu-programmer: no device present

The device is present according to lsusb:

Bus 002 Device 007: ID 03eb:2ff1 Atmel Corp.

I tried the solution provided above, but the result does not change:

dfu-programmer at32uc3a3256s:2,7 flash --suppress-bootloader-mem firmware_V0.47.0.hex

Still gives “no device present”.

Thanks in advance. The device is currently not responsive and contains a valid key.

8

Hi,

on which system are you working? As far as I know lsusb is a UNIX command? So you are not on Windows as the OP?

If so: did you execute the command with root permissions?

Kind regards
Alex

9

Ubuntu 18.04

Eventually, I would like to use it on Mac OS (I needed to downgrade the firmware to make it work with Mac OS), but the flashing tool does not compile on the Mac. I was able to compile it on Ubuntu.

Yes, executing as
sudo dfu-programmer …

10

Hi,

does the Nitrokey App recognize the NK Storage?

Why not using the binary? But compiling it yourself probably is not the cause…

I guess: you did try plugging in and out, rebooting your system, used different USB ports etc?

Have you tried ‘erase’ again? It should state

Checking memory from 0x2000 to 0x3FFFF...  Empty.
Chip already blank, to force erase use --force.

So if you can access the device with erase I don’t see why you shouldn’t with the flash command, yet :thinking:

11
  • The Nitro key App no longer recognizes the device at all.
  • I did not know there was a binary, I went back and installed it from the distro, successfully. No change in results. Still getting “no device present to all commands”.
  • Yes, I did try plugging in/out, rebooting, several times.
  • Yes, I also did try re-erasing, bu the erase command also gives “no device present”.
  • Again I was only able to access the device with the erase command once, no longer.

Here is the verbose lsusb output of the device (bus/device updated since replug:

Bus 002 Device 003: ID 03eb:2ff1 Atmel Corp.

Couldn’t open device, some information will be missing
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass 0 (Defined at Interface level)
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 64
idVendor 0x03eb Atmel Corp.
idProduct 0x2ff1
bcdDevice 10.00
iManufacturer 1
iProduct 2
iSerial 3
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 27
bNumInterfaces 1
bConfigurationValue 1
iConfiguration 0
bmAttributes 0xc0
Self Powered
MaxPower 100mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 0
bInterfaceClass 254 Application Specific Interface
bInterfaceSubClass 1 Device Firmware Update
bInterfaceProtocol 2
iInterface 0
Device Firmware Upgrade Interface Descriptor:
bLength 9
bDescriptorType 33
bmAttributes 15
Will Detach
Manifestation Tolerant
Upload Supported
Download Supported
wDetachTimeout 0 milliseconds
wTransferSize 65535 bytes
bcdDFUVersion 1.01

12

And the --debug 9 output of the command:

$ dfu-programmer at32uc3a3256s:2,3 erase --debug 9
 target: at32uc3a3256s
 chip_id: 0x2ff1
 vendor_id: 0x03eb
 command: erase
 quiet: false
 debug: 9
 device_type: AVR32
------ command specific below ------
validate: true

dfu-programmer: no device present.
13

Greetings again.

I went on an old Windows machine and installed the binary of dfu-installer. Also installed the driver successfully and the system recognized device. However, the erase command result is identical to the one seen on Linux, including debug details as above.

This was just a test, and I really dislike working with unsigned binary executables on systems like Windows, so I would really appreciate continuing the ticket in Linux and Mac OS terms, if possible.

best regards.

14

Please try executing dfu-programmer as root (sudo), as mentioned in the instructions.

15

Hi!

  1. Have you tried running without specifying the device bus and device numbers? E.g.:
dfu-programmer at32uc3a3256s flash --suppress-bootloader-mem firmware_V0.47.0.hex
  1. What is your dfu-programmer version? Mine is 0.7.2.
16

That, finally resolved the bricked device issue. The device is now operational on firmware version 0.47.

That, however, only solved the technical problem created by the downgrade of the firmware from 0.48 to 0.47, as proposed by Alex to a request by fernando in Lots of issues with encrypted storage (and password safe) on Mac

However, the majority of the multiple issues described by fernando in that post are unresolved by the downgrade to 0.47 .

Namely:

  • Clicking the Eject button or using other GUI means in the Finder to eject disks always result in the volumes (encrypted or unencrypted) reappearing, meaning that one cannot remove the key or lock the encrypted volume safely; the only way one is able to get the volumes to stay unmounted is by ejecting the “Nitrokey Nitrokey Storage Media” entries from Disk Utility – but this only works sometimes; ejecting works fine on Linux – this behavior is unacceptable is unchanged in 0.47.
  • Data corruption happens between sessions of locking and unlocking the encrypted volume, and appears unrecoverable. It is unsure if this is due to the inevitable unsafe removals described above, or to otherwise faulty software, or both.
  • The device (the app) reports frequent disconnections and reconnections despite a healthy appearing USB connection (not experienced in other operating systems running on the same hardware, so assumed to be due to flaky coding).
  • On a good note, the GnuPG integration (on the Mac, using the Suite) appears unaffected by these problems, though I will need to run more tests before permanantly committing keys to this apparently very unreliable device, with a very fragile software implementation.

I will continue the Mac OS testing further and report issues, but I am sorry to report that the App 1.1 and firmwares 0.47 and 0.48 barely qualify as alpha software on Mac OS.

We can continue the discussion in Lots of issues with encrypted storage (and password safe) on Mac - where it’s more appropriate.

best regards,

17

Are you using Secure Input in Terminal or password dialogs?

PS Could you copy your post there?

18

szszszsz: thanks for the comments.

  • Yes, I had tried running the command w/o the bus.device parameters.
  • I used dfu-programmer 0.7.2 in all three environments.
  • only executing it as root (use sudo -i to start a bash as root) appeared resolve the problem, with seems a little extreme.

best regards,
marky

19

I just did. - We should continue there.

password dialogs pop up. I have not tried to modify that behaviour in gpg.

20

I might get accustomed to this, but working with devices on low-level usually need root privileges. On Ubuntu one could configure udev to grant the privileges to user automatically - perhaps similar mechanism is available on MacOS but I am not aware of it (yet).

To take a conclusion from this discussion, which one would suit you:

  1. Provided a signed dfu-programmer binary for MacOS (run with root privileges),
  2. A way to run the programmer without sudo on MacOS,
  3. Other (your solution here).