Just unable to get this to work (macOS Monterey)

[raspberrycoulis]

Where to start? I'm trying to install this to test out my new Solo V2 keys, but I have not been able to get it to work.

I appreciate this is still in development, but it would be great if the installation instructions could be updated for a fresh install as it seems that things aren't fully explained to relatively inexperienced people (like myself I guess).

After some initial problems, I had to install Rust by running (as outlined here):

curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh

Then I managed to get solo2 to install by running:

cargo install solo2

However, when I run the following command:

solo2 app admin uuid

I get:

Error: Empty list of smartcards

Revisiting the README file, it mentions something about Solo 2 is supported by Ludovic Rousseau's CCID driver, but there has not been a release. The included Info.plist works.

Ok, so what does that actually mean to somebody who isn't very familiar with all this? I've tried to install Ludovic Rousseau's CCID driver by running:

wget https://ccid.apdu.fr/files/ccid-1.4.34.tar.bz2
tar xzvf ccid-1.4.34.tar.bz2
cd ccid-1.4.34.tar.bz2
./configure
make
make install

As outlined here, I've also tried:

./MacOSX/configure
make
sudo make install

But the first command (./MacOSX/configure) results in:

/usr/local/Cellar/libusb/1.0.24/lib/libusb-1.0.0.dylib	/usr/local/Cellar/libusb/1.0.24/lib/libusb-1.0.dylib
*****************************
Dynamic library libusb found in /usr/local/Cellar/libusb/1.0.24/lib
*****************************
Rename it to force a static link

I have tried removing libusb (brew uninstall --ignore-dependencies libusb --force) and trying again, which seems to progress further, but then results in:

configure: error: libusb.h not found, install libusb or use ./configure LIBUSB_CFLAGS=...

I have no idea what that means or what else to do on that so that runs into other problems and the rabbit hole deepens... Should I be doing something with the included Info.plist and if so, what and where?

In an ideal world, it would be great if the installation instructions were looked at again from a fresh installation point of view, so that any dependencies are detailed as it seems something isn't quite right here and I do not know what else to do to get this to work.

I'm running this on macOS Monterey (version 12.0.1) with cargo version 1.56.0 and solo2 version 0.1.0.

[nickray]

It should not be necessary to install Rust / compile the solo2 binary, as each release has assets built in GitHub Actions and uploaded to the release page: https://github.com/solokeys/solo2-cli/releases.

Regarding the "old" Info.plist, I unfortunately don't have a Mac currently. If you can locate the existing Info.plist and replace it with the one included here (https://github.com/solokeys/solo2-cli/blob/main/Info.plist), I'm somewhat hopeful it might work. Would be great if some knowledgeable Mac users could chime in.

[theerror]

Hmm, ok, there are two options - it's not actually related or I still missing something.... :/

~  ❯ /opt/homebrew/Cellar/kc-solo2-cli/0.2.1/bin/solo2 app ndef capabilities
thread 'main' panicked at 'explicit panic', src/transport/ctap.rs:90:18
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

could it be actually, that maybe list show CTAP only? Or those mentioned pcscd daemon needs to be running?

sad, but I think, this might be some kind of different issue. The device itself is actually recognised, what was the main problem in past I think. I've hope, that it may could fix this as well. :/

It's just failures :(

~  ✖101 ❯ solo2 -vvv app oath list
 INFO  solo2::transport > using CTAP as minimal transport
 INFO  solo2::transport > using CTAP as minimal transport
 INFO  solo2::transport > using CTAP as minimal transport
thread 'main' panicked at 'explicit panic', /Users/therror/.cargo/registry/src/github.com-1ecc6299db9ec823/solo2-0.2.1/src/transport/ctap.rs:90:18
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
~  ✖101 ❯ solo2 -vvv app oath totp test
 INFO  solo2::transport > using CTAP as minimal transport
 INFO  solo2::transport > using CTAP as minimal transport
 DEBUG solo2::apps::oath > credential ID: test
Error: p1/p2 parameters not supported on this transport

But based on second, my tip is the forced CTAP.

Is this suppose looks like this (connecting token)? Those POWER_STATE_UNPOWERED is weird....
/opt/homebrew/Cellar/kc-pcsc-lite/1.9.5/sbin/pcscd --foreground --apdu --color --debug

07028787 [0x16d01f000] ifdhandler.c:389:IFDHGetCapabilities() tag: 0xFAF, SoloKeys Solo 2 (lun: 0)
00000026 [0x16d01f000] readerfactory.c:749:RFSetReaderName() Support 16 simultaneous readers
00000006 [0x16d01f000] ifdhandler.c:389:IFDHGetCapabilities() tag: 0xFAD, SoloKeys Solo 2 (lun: 0)
00000024 [0x16d01f000] readerfactory.c:1098:RFInitializeReader() Attempting startup of SoloKeys Solo 2 01 00 using /opt/homebrew/share/pcsc-drivers/ifd-ccid.bundle/
00000019 [0x16d01f000] readerfactory.c:886:RFLoadReader() Reusing already loaded driver for /opt/homebrew/share/pcsc-drivers/ifd-ccid.bundle/
00000029 [0x16d01f000] readerfactory.c:972:RFBindFunctions() Loading IFD Handler 3.0
00000012 [0x16d01f000] ifdhandler.c:110:CreateChannelByNameOrChannel() Lun: 10000, device: SoloKeys Solo 2
00000010 [0x16d01f000] ccid_usb.c:317:OpenUSBByName() Using: /opt/homebrew/Cellar/kc-ccid-driver/1.5.0/share/pcsc-drivers/ifd-ccid.bundle/Contents/Info.plist
00000802 [0x16d01f000] ccid_usb.c:335:OpenUSBByName() ifdManufacturerString: Ludovic Rousseau ([email protected])
00000010 [0x16d01f000] ccid_usb.c:336:OpenUSBByName() ifdProductString: Generic CCID driver
00000002 [0x16d01f000] ccid_usb.c:337:OpenUSBByName() Copyright: This driver is protected by terms of the GNU Lesser General Public License version 2.1, or (at your option) any later version.
00001281 [0x16d01f000] ccid_usb.c:567:OpenUSBByName() USB device 1/5 already in use. Checking next one.
00000023 [0x16d01f000] ccid_usb.c:807:OpenUSBByName() Wait after libusb: 9
00107405 [0x16d01f000] ccid_usb.c:680:OpenUSBByName() Found Vendor/Product: 1209/BEEE (SoloKeys Solo 2)
00000056 [0x16d01f000] ccid_usb.c:682:OpenUSBByName() Using USB bus/device: 2/1
00000005 [0x16d01f000] ccid_usb.c:744:OpenUSBByName() bNumDataRatesSupported is 0
00005775 [0x16d01f000] ifdhandler.c:389:IFDHGetCapabilities() tag: 0xFB3, SoloKeys Solo 2 (lun: 10000)
00000047 [0x16d01f000] readerfactory.c:395:RFAddReader() Using the pcscd polling thread
00001983 [0x16d01f000] ifdhandler.c:389:IFDHGetCapabilities() tag: 0xFAE, SoloKeys Solo 2 (lun: 10000)
00000031 [0x16d01f000] ifdhandler.c:484:IFDHGetCapabilities() Reader supports 1 slot(s)
00000534 [0x16d1c3000] ifdhandler.c:1217:IFDHPowerICC() action: PowerUp, SoloKeys Solo 2 (lun: 10000)
00000304 [0x16d1c3000] eventhandler.c:289:EHStatusHandlerThread() powerState: POWER_STATE_POWERED
00000007 [0x16d1c3000] Card ATR: 3B 88 01 80 56 53 6F 6C 6F 20 32 72
00406003 [0x16d1c3000] ifdhandler.c:1217:IFDHPowerICC() action: PowerDown, SoloKeys Solo 2 (lun: 10000)
00000605 [0x16d1c3000] eventhandler.c:482:EHStatusHandlerThread() powerState: POWER_STATE_UNPOWERED

[KizzyCode]

Yes, the PC/SC-service needs to be enabled with brew services start kc-pcsc-lite

[theerror]

looks it is somewhere in transport layer, but probably not related to this PC/SC server, I would say.

solo2 -vvv app oath list
 INFO  solo2::transport > using CTAP as minimal transport
 INFO  solo2::transport > using CTAP as minimal transport
 INFO  solo2::transport > using CTAP as minimal transport
thread 'main' panicked at 'explicit panic', /Users/theerror/.cargo/registry/src/github.com-1ecc6299db9ec823/solo2-0.2.1/src/transport/ctap.rs:90:18
stack backtrace:
   0:        0x102e3302c - std::backtrace_rs::backtrace::libunwind::trace::h67adef0ee52f18a6
                               at /rustc/a55dd71d5fb0ec5a6a3a9e8c27b2127ba491ce52/library/std/src/../../backtrace/src/backtrace/libunwind.rs:93:5
   1:        0x102e3302c - std::backtrace_rs::backtrace::trace_unsynchronized::hfd058563be5f0141
                               at /rustc/a55dd71d5fb0ec5a6a3a9e8c27b2127ba491ce52/library/std/src/../../backtrace/src/backtrace/mod.rs:66:5
   2:        0x102e3302c - std::sys_common::backtrace::_print_fmt::h6e3037edf9476a2c
                               at /rustc/a55dd71d5fb0ec5a6a3a9e8c27b2127ba491ce52/library/std/src/sys_common/backtrace.rs:66:5
   3:        0x102e3302c - <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt::h1543c132bc4e188c
                               at /rustc/a55dd71d5fb0ec5a6a3a9e8c27b2127ba491ce52/library/std/src/sys_common/backtrace.rs:45:22
   4:        0x102e50000 - core::fmt::write::hda8e8eb84b49cbfc
                               at /rustc/a55dd71d5fb0ec5a6a3a9e8c27b2127ba491ce52/library/core/src/fmt/mod.rs:1198:17
   5:        0x102e2d770 - std::io::Write::write_fmt::hb84c8996aec7120c
                               at /rustc/a55dd71d5fb0ec5a6a3a9e8c27b2127ba491ce52/library/std/src/io/mod.rs:1672:15
   6:        0x102e3478c - std::sys_common::backtrace::_print::hf5f28b96760f1aab
                               at /rustc/a55dd71d5fb0ec5a6a3a9e8c27b2127ba491ce52/library/std/src/sys_common/backtrace.rs:48:5
   7:        0x102e3478c - std::sys_common::backtrace::print::h327d20a60b6bc910
                               at /rustc/a55dd71d5fb0ec5a6a3a9e8c27b2127ba491ce52/library/std/src/sys_common/backtrace.rs:35:9
   8:        0x102e3478c - std::panicking::default_hook::{{closure}}::hdf06011cb093de6a
                               at /rustc/a55dd71d5fb0ec5a6a3a9e8c27b2127ba491ce52/library/std/src/panicking.rs:295:22
   9:        0x102e344f0 - std::panicking::default_hook::hd7ceb942fff7b170
                               at /rustc/a55dd71d5fb0ec5a6a3a9e8c27b2127ba491ce52/library/std/src/panicking.rs:314:9
  10:        0x102e34c24 - std::panicking::rust_panic_with_hook::h053d4067a63a6fcb
                               at /rustc/a55dd71d5fb0ec5a6a3a9e8c27b2127ba491ce52/library/std/src/panicking.rs:698:17
  11:        0x102e34b20 - std::panicking::begin_panic_handler::{{closure}}::hea9e6c546a23e8ff
                               at /rustc/a55dd71d5fb0ec5a6a3a9e8c27b2127ba491ce52/library/std/src/panicking.rs:586:13
  12:        0x102e33508 - std::sys_common::backtrace::__rust_end_short_backtrace::hd64e012cf32134c6
                               at /rustc/a55dd71d5fb0ec5a6a3a9e8c27b2127ba491ce52/library/std/src/sys_common/backtrace.rs:138:18
  13:        0x102e348b0 - rust_begin_unwind
                               at /rustc/a55dd71d5fb0ec5a6a3a9e8c27b2127ba491ce52/library/std/src/panicking.rs:584:5
  14:        0x102e6487c - core::panicking::panic_fmt::hbfde5533e1c0592e
                               at /rustc/a55dd71d5fb0ec5a6a3a9e8c27b2127ba491ce52/library/core/src/panicking.rs:142:14
  15:        0x102e6479c - core::panicking::panic::h89917039f65f3f80
                               at /rustc/a55dd71d5fb0ec5a6a3a9e8c27b2127ba491ce52/library/core/src/panicking.rs:48:5
  16:        0x102c64094 - <solo2::device::ctap::Device as solo2::transport::Transport>::call::hfe98004d15f098bd
  17:        0x102c58050 - solo2::apps::oath::App::list::h915d7111f2d1b3e1
  18:        0x102c171fc - solo2::main::hf92e173b11cc76da
  19:        0x102c2034c - std::sys_common::backtrace::__rust_begin_short_backtrace::h6c2550b3db19215e
  20:        0x102c20364 - std::rt::lang_start::{{closure}}::h295aba33c2897b11
  21:        0x102e27914 - core::ops::function::impls::<impl core::ops::function::FnOnce<A> for &F>::call_once::h7cd8ae72620b0d1f
                               at /rustc/a55dd71d5fb0ec5a6a3a9e8c27b2127ba491ce52/library/core/src/ops/function.rs:280:13
  22:        0x102e27914 - std::panicking::try::do_call::h0bbb0f423dd9d86c
                               at /rustc/a55dd71d5fb0ec5a6a3a9e8c27b2127ba491ce52/library/std/src/panicking.rs:492:40
  23:        0x102e27914 - std::panicking::try::hdaabe7e5908702af
                               at /rustc/a55dd71d5fb0ec5a6a3a9e8c27b2127ba491ce52/library/std/src/panicking.rs:456:19
  24:        0x102e27914 - std::panic::catch_unwind::h7ee653eae81d0a43
                               at /rustc/a55dd71d5fb0ec5a6a3a9e8c27b2127ba491ce52/library/std/src/panic.rs:137:14
  25:        0x102e27914 - std::rt::lang_start_internal::{{closure}}::he727754da11a45c1
                               at /rustc/a55dd71d5fb0ec5a6a3a9e8c27b2127ba491ce52/library/std/src/rt.rs:128:48
  26:        0x102e27914 - std::panicking::try::do_call::h0171064c04d908b7
                               at /rustc/a55dd71d5fb0ec5a6a3a9e8c27b2127ba491ce52/library/std/src/panicking.rs:492:40
  27:        0x102e27914 - std::panicking::try::h9c521838fe914345
                               at /rustc/a55dd71d5fb0ec5a6a3a9e8c27b2127ba491ce52/library/std/src/panicking.rs:456:19
  28:        0x102e27914 - std::panic::catch_unwind::hac847f960377a9be
                               at /rustc/a55dd71d5fb0ec5a6a3a9e8c27b2127ba491ce52/library/std/src/panic.rs:137:14
  29:        0x102e27914 - std::rt::lang_start_internal::hef2161f9571a51d7
                               at /rustc/a55dd71d5fb0ec5a6a3a9e8c27b2127ba491ce52/library/std/src/rt.rs:128:20
  30:        0x102c19a94 - _main

[KizzyCode]

I would say, this is a CTAP-related error (the last non-std-function in the stacktrace is <solo2::device::ctap::Device as solo2::transport::Transport>::call), I would assume this is the same error (or related to it).
However I'm afraid that I'm not really able to help you there, since I'm on Ventura already and I'm not probably not doing a downgrade anymore :/

If you cannot make it work, I'd suggest to wait until Ventura gets released – we are currently at beta 11 (I'd expect that we'll have a release candidate very soon), so it probably won't be long (2-3 weeks?) anymore.

Sorry that I cannot help you there :/

[theerror]

I would say, this is a CTAP-related error (the last non-std-function in the stacktrace is <solo2::device::ctap::Device as solo2::transport::Transport>::call), I would assume this is the same error (or related to it). However I'm afraid that I'm not really able to help you there, since I'm on Monterey already and I'm not probably not doing a downgrade anymore :/

Yes, to me, it looks the same.

If you cannot make it work, I'd suggest to wait until Monterey gets released – we are currently at beta 11 (I'd expect that we'll have a release candidate very soon), so it probably won't be long (2-3 weeks?) anymore.

I'll play with in mean-time and will see.

Sorry that I cannot help you there :/

It's fine, you helped a lot anyway ;)

[nickray]

Quick update: Been working on the CTAP interface to get into the bootloader without requiring PCSC. Should be able to test on a Mac VM end of week and cut a release.

[nickray]

Would anybody like to test the macOS artifact on https://github.com/solokeys/solo2-cli/actions/runs/1639470266? That is, https://github.com/solokeys/solo2-cli/suites/4797767185/artifacts/134477432

[nickray]

If you have a moment, can you retry with https://github.com/solokeys/solo2-cli/actions/runs/1641427701? What you ran into parses as a "keepalive" message, which is weird to me because I don't get any (with latest official firmware). So if you can reproduce that, would be interested in what the included info!("received keepalive, status {:?}", status); reports.

[felix-gohla]

Yep, works fine now. 😊
I unfortunately cannot use the official firmware, as I changed the version number in my own firmware to 1.0.9 and now the lpc55's rollback protection kicks in. At least until a >=1.0.9 is released.

btw: Happy new year! 🥳

[philipmw]

Hello! I tested https://github.com/solokeys/solo2-cli/actions/runs/1641427701 on my Mac M1 with a USB-C Solo 2.

% ./solo2 list
Solo 2 F2E1AD0E8FAA0B57A5C9B2E6D940BCAC (CTAP only, firmware 1:20200101.8)

% ./solo2 update
Downloading latest release from https://github.com/solokeys/solo2/
Fetched firmware version 1:20200101.8
Tap button on key to confirm, or replug to abort...
LPC55 Bootloader detected. The LED should be off.
Writing new firmware...
Done. Rebooting key.  The LED should turn back on.

Now here it got stuck. The LED was back on, but the program wouldn't terminate even after several minutes. I had to kill it. The key continues to work.

[nickray]

Also thanks for the feedback :) Here's a new candidate: https://github.com/solokeys/solo2-cli/actions/runs/1646076327

The issue is that hidapi-rs keeps a global lock that is a bit iffy about being released (relevant when switching between Solo2 CTAP and Lpc55 Bootloader interfaces, which are both HID).

[philipmw]

This worked beautifully.

% SOLO2_LOG=info ./solo2 ls
 INFO  solo2::transport > using CTAP as minimal transport
Solo 2 F2E1AD0E8FAA0B57A5C9B2E6D940BCAC (CTAP only, firmware 1:20200101.8)

% SOLO2_LOG=info ./solo2 update
Downloading latest release from https://github.com/solokeys/solo2/
Fetched firmware version 1:20200101.8
 INFO  solo2::transport > using CTAP as minimal transport
 INFO  solo2::device    > device fw version: 1:20200101.8
 INFO  solo2::device    > new fw version: 1:20200101.8
Tap button on key to confirm, or replug to abort...
 INFO  solo2::transport > using CTAP as minimal transport
LPC55 Bootloader detected. The LED should be off.
Writing new firmware...
Done. Rebooting key.  The LED should turn back on.
 INFO  lpc55::bootloader > calling Command::Reset
 INFO  solo2::transport  > using CTAP as minimal transport

[lumaxis]

Hey @nickray, sorry to tag in on this discussion but I've been wondering about the state of the provision app on macOS to e.g. generate an Ed25519 key. I've installed solo2 from master and was able to update my key's firmware without problems.
Trying to run solo2 app provision generate-ed255-key for example, I get this stacktrace:

thread 'main' panicked at 'explicit panic', src/transport/ctap.rs:90:18
stack backtrace:
   0:        0x102cb52c4 - <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt::h3f81cb057e3d3879
   1:        0x102cdc934 - core::fmt::write::h02801d0504bdfd0d
   2:        0x102caf3ec - std::io::Write::write_fmt::h1960c73e53fec16b
   3:        0x102cb1fcc - std::panicking::default_hook::{{closure}}::h65e61ea78aba2e0b
   4:        0x102cb1b90 - std::panicking::default_hook::hfdcd50ee13b550c9
   5:        0x102cb2510 - std::panicking::rust_panic_with_hook::hb76cdf9da9a25546
   6:        0x102cb58c4 - std::panicking::begin_panic_handler::{{closure}}::hb6f8c2ba59a6ee34
   7:        0x102cb540c - std::sys_common::backtrace::__rust_end_short_backtrace::hb1a429aa8e338456
   8:        0x102cb20b8 - _rust_begin_unwind
   9:        0x102cee43c - core::panicking::panic_fmt::h268d6eeb5a73ef26
  10:        0x102cee3c0 - core::panicking::panic::hfe6a957aa1ee7637
  11:        0x102ad8e18 - <solo2::device::ctap::Device as solo2::transport::Transport>::call::h3ea324ce27516335
  12:        0x102ac3540 - solo2::apps::provision::App::generate_trussed_ed255_attestation_key::ha65b7b70637a3447
  13:        0x102a9d700 - solo2::try_main::h2c4d3268e28a16c8
  14:        0x102a997f8 - solo2::main::h01c22b54ac744723
  15:        0x102aa0000 - std::sys_common::backtrace::__rust_begin_short_backtrace::hde76137393187d68
  16:        0x102a9fa04 - std::rt::lang_start::{{closure}}::h80eac7689f94b3d0
  17:        0x102ca17f4 - std::rt::lang_start_internal::hd9bf753dce38cbd9
  18:        0x102a9ee1c - _main

[nickray]

provision is for factory use (and hacker keys). not expected to work. the ed255 key is a trussed identity key (leaf cert in this partial doc). needs more docs and maybe i should just completely hide it in cli for now...

[lumaxis]

Ah yes, that makes sense of course, thanks 😅 Yea, it's been a bit tricky to figure out how to best use the Solo2 with the small amount of docs today.
Specifically, I'm looking for a way to use it for SSH without having to install OpenSSH and libfido2 from Homebrew. I was looking at projects like https://github.com/FiloSottile/yubikey-agent instead but they seem to only support Yubikeys.

[bturner-bw]

Hello, I'm having the same issue the OP was having (SoloKey not found). I have followed all the suggestions listed so far, including the detailed steps @felix-gohla provided. So far, nothing has worked to get solo2-cli to recognize the key.

I'm using a MacBook Pro (Intel), Monterey 12.2.1, with a Solo2 Hacker v2.3.0

The key is visible in the System Report:

Solo Hacker 2.3.0:

  Product ID:	0xa2ca
  Vendor ID:	0x0483  (STMicroelectronics)
  Version:	1.00
  Serial Number:	208F32903141
  Speed:	Up to 12 Mb/s
  Manufacturer:	SoloKeys
  Location ID:	0x14200000 / 7
  Current Available (mA):	500
  Current Required (mA):	100
  Extra Operating Current (mA):	0

I start the PCSC daemon, then type "solo2 list" which gives the following output in the daemon's log:

% sudo LIBCCID_ifdLogLevel=0x000F /opt/pcsc/sbin/pcscd --foreground --apdu --color --debug
Password:
00000000 [0x111954600] ../../src/debuglog.c:297:DebugLogSetLevel() debug level=debug
00000105 [0x111954600] ../../src/configfile.l:369:DBGetReaderList() Parsing conf file: /opt/pcsc/etc/reader.conf.d
00000008 [0x111954600] ../../src/pcscdaemon.c:666:main() pcsc-lite 1.9.5 daemon ready.
00006328 [0x700009a73000] ../../src/hotplug_macosx.c:506:HPDriversMatchUSBDevices() error getting plugin interface from IOCreatePlugInInterfaceForService()
00000163 [0x700009a73000] ../../src/hotplug_macosx.c:506:HPDriversMatchUSBDevices() error getting plugin interface from IOCreatePlugInInterfaceForService()
00000129 [0x700009a73000] ../../src/hotplug_macosx.c:506:HPDriversMatchUSBDevices() error getting plugin interface from IOCreatePlugInInterfaceForService()
00000185 [0x700009a73000] ../../src/hotplug_macosx.c:506:HPDriversMatchUSBDevices() error getting plugin interface from IOCreatePlugInInterfaceForService()
..... (many of these)
17604305 [0x111954600] ../../src/winscard_msg_srv.c:256:ProcessEventsServer() Common channel packet arrival
00000017 [0x111954600] ../../src/winscard_msg_srv.c:268:ProcessEventsServer() ProcessCommonChannelRequest detects: 6
00000004 [0x111954600] ../../src/pcscdaemon.c:133:SVCServiceRunLoop() A new context thread creation is requested: 6
00000039 [0x700009af6000] ../../src/winscard_svc.c:340:ContextThread() Authorized PC/SC client
00000004 [0x700009af6000] ../../src/winscard_svc.c:344:ContextThread() Thread is started: dwClientID=6, threadContext @0x600000308000
00000010 [0x700009af6000] ../../src/winscard_svc.c:362:ContextThread() Received command: CMD_VERSION from client 6
00000011 [0x700009af6000] ../../src/winscard_svc.c:374:ContextThread() Client is protocol version 4:4
00000003 [0x700009af6000] ../../src/winscard_svc.c:396:ContextThread() CMD_VERSION rv=0x0 for client 6
00000044 [0x700009af6000] ../../src/winscard_svc.c:362:ContextThread() Received command: ESTABLISH_CONTEXT from client 6
00000010 [0x700009af6000] ../../src/winscard.c:215:SCardEstablishContext() Establishing Context: 0x2E66B618
00000004 [0x700009af6000] ../../src/winscard_svc.c:465:ContextThread() ESTABLISH_CONTEXT rv=0x0 for client 6
00000114 [0x700009af6000] ../../src/winscard_svc.c:362:ContextThread() Received command: CMD_GET_READERS_STATE from client 6
00000066 [0x700009af6000] ../../src/winscard_svc.c:362:ContextThread() Received command: CMD_GET_READERS_STATE from client 6
00000065 [0x700009af6000] ../../src/winscard_svc.c:362:ContextThread() Received command: RELEASE_CONTEXT from client 6
00000013 [0x700009af6000] ../../src/winscard.c:229:SCardReleaseContext() Releasing Context: 0x2E66B618
00000003 [0x700009af6000] ../../src/winscard_svc.c:480:ContextThread() RELEASE_CONTEXT rv=0x0 for client 6
00000088 [0x700009af6000] ../../src/winscard_svc.c:354:ContextThread() Client die: 6
00000009 [0x700009af6000] ../../src/winscard_svc.c:1067:MSGCleanupClient() Thread is stopping: dwClientID=6, threadContext @0x600000308000
00000003 [0x700009af6000] ../../src/winscard_svc.c:1073:MSGCleanupClient() Freeing SCONTEXT @0x600000308000

Re-plugging the key only generates the "error getting plugin" messages.

But when I try any command that requires access to the key, it reports no keys:

% SOLO2_LOG=info cargo run update     
    Finished dev [unoptimized + debuginfo] target(s) in 0.15s
     Running `target/debug/solo2 update`
Downloading latest release from https://github.com/solokeys/solo2/
Fetched firmware version 1:20200101.9
Error: Empty list of Solo 2 devices

I was able to get the python script tests/basic.py to contact the key, display the device information, as well as set and reset the PIN, so I know the key is working!

{   <VERSIONS: 0x01>: ['U2F_V2', 'FIDO_2_0'],
    <EXTENSIONS: 0x02>: ['hmac-secret'],
    <AAGUID: 0x03>: b'\x88vc\x1b\xd4\xa0B\x7fWs\x0e\xc7\x1c\x9e\x02y', 
    <OPTIONS: 0x04>: {
        'rk': True, 
        'up': True, 
        'plat': False, 
        'clientPin': False
    }, 
    <MAX_MSG_SIZE: 0x05>: 1200, 
    <PIN_UV_PROTOCOLS: 0x06>: [1]
}

I have no other smart card readers (unless touch-id counts?).

Any help is appreciated!
Thanks,
--Bryan

[nickray]

This is a Solo 1 (from the STMicroelectronics above), so this discussion does not apply. Solo 1 and Solo 2 are separate products with separate CLIs.

[bturner-bw]

Hi Nick - Thanks, so the Solo Hacker keys purchased on the solokeys.com website are the V1 keys, not V2 keys?

That makes so much more sense! After reading all the V2 documentation I just grabbed a key of the site assuming it was the V2.

I'll see what I can do with the V1, and keep an eye out for the Hacker V2 keys to land..

[nickray]

Yes, sorry about that. Trying to consistently rebrand "old Solo" as Solo 1, vs "new Solo" as Solo 2 (or V2 in the crowdfunding campaigns). It will be a while before Solo 2 is available outside these campaigns (need a new machine at the factory first...).

Related misunderstanding is that "Solo hacker" is somehow a suitable devkit (for both versions), a better name would be "unlocked" (or even "unfinished"), as a) debugability is very limited (better to use vendor devkit for STM32L432 or LPC55S69 with integrated debuggers), very easy to "brick", and b) the core difference is that the SoloKeys PKI is missing (i.e. FIDO2 batch certificates, Trussed device unique key certificates, etc.), which one would want to swap out only if using custom firmware build with custom signing/PKI infrastructure (see limited documentation linked from https://s2pki.net/lookup/ for more info).

[theerror]

Just here to provide update - on new Ventura 13 it's now working as it should.