dnesting
Repos
22
Followers
32

Events

opened issue
No ability to target a specific Yubikey with more than one Yubikey connected.

Opening a new request per #287 for my use case. I also have situations where I need to work with multiple YubiKeys simultaneously. The recommended option in the linked issue is to use list-readers, however this is my situation:

$ yubico-piv-tool -a list-readers
Yubico YubiKey FIDO+CCID 01
Yubico YubiKey FIDO+CCID

The 01 appears to be added to give some way of disambiguating, but it doesn't actually work. Both strings above connect to the same Yubikey (maybe it's just doing a prefix match?) and even if it worked, it won't be stable since it depends on what order keys are found in, and whether the second Yubikey uses the same string as the first.

Is it possible to select based on serial number? This is an obvious unique identifier that's printed on the side of my Yubikeys and would be easy for me to incorporate into my workflow. I could even have my automation validate the right Yubikey was inserted and eliminate one type of issue caused by human error.

Created at 4 weeks ago
Created at 1 month ago
issue comment
delegate communicates scan results via channels

I adapted my test case from issue #73 and can't reproduce the original problem with this change applied.

1.147988583s: 11 calls, no problem
1.1488545s: 11 calls, no problem
1.147610291s: 11 calls, no problem
1.1499915s: 11 calls, no problem
1.145267s: 7 calls, no problem
1.146460209s: 11 calls, no problem
1.149309167s: 9 calls, no problem
1.138770625s: 11 calls, no problem
1.1639775s: 11 calls, no problem
1.144412334s: 11 calls, no problem
Created at 2 months ago
pull request opened
delegate communicates scan results via channels

This fixes https://github.com/go-ble/ble/issues/73 for Darwin. The problem here is that the OS may deliver scan results to d.advHandler even after the Scan call has returned. This violates the usual contract for callbacks and makes it hard to implement common callback patterns since callbacks can occur long after the code that called Scan has moved on to other things.

I'm not thrilled with the complexity of this solution but I think it reliably fixes the issue. It works by communicating results from the delegate to the Scan call through channels.

I believe the Linux version of the code has the same problem and a similar fix could be applied there, but didn't want to do too much in one MR.

Created at 2 months ago
create branch
dnesting create branch dnesting/scan-chan
Created at 2 months ago
Created at 2 months ago
create branch
dnesting create branch dnesting/scan-chan
Created at 2 months ago

linux/add: fix duplicated switch case error

The rsp[0] == ErrorResponseCode && len(rsp) == 5 case was duplicated. Surrounding code uses rsp[0] == ErrorResponseCode && len(rsp) != 5 (note "not equal") for the second case, so probably this is probably what we want there as well.

Corrected ioctl on mips (#52)

fix go vet warning for unkeyed field in composite literal

Mojave / Catalina support

This commit replaces the use of XPC services with the "cbgo" library (CoreBluetooth Go).

Fix hang when cmgr/pmgr initialize early

This fixes what seems to be a Catalina-specific issue.

Pre-Catalina: The DidUpdateState delegate callbacks get called after the delegate properties gets assigned.

Catalina: DidUpdateState gets called immediately upon construction of the manager objects (CBCentralManager and CBPeripheralManager).

Prior to this commit, the code assumed it could assign the delegate properties and then listen for the transition to the powered-on state. This works for older versions of macOS, but with Catalina the code blocks forever, waiting for an event that has already occurred.

The fix is to use the following procedure:

(for each manager object):

  1. Assign the delegate.
  2. Check the state. If the state is not "unknown" then the procedure is done.
  3. Else, wait up to one second for a state change event.

Added support for reading RSSI of a connected peripheral

Client should also support incoming MTU exchanges

Don't try to handle canceled connections

Currently the check to see if a connection was canceled happens after newConn() is called, leaking a goroutine waiting to receive on chInPkt. Move the check up.

Merge pull request #64 from mfiumara/fix-unkeyed-field

fix go vet warning for unkeyed field in composite literal

Merge pull request #67 from ccollins476ad/mojave

Mojave / Catalina support

Merge pull request #72 from abferm/master

Added support for reading RSSI of a connected peripheral

Merge pull request #79 from markdrayton/issue-77-leak-goroutine

Don't try to handle canceled connections

Merge pull request #53 from amarkee/mips_ioctl

Corrected ioctl on mips (#52)

Merge pull request #39 from quasilyte/patch-1

linux/att: fix duplicated switch case error

Fix Linux local name handling and manf support

Race condition in Send fixed

Locked h.send with a mutex

darwin: ReadRSSI added to conn as required by interface

bump "golang.org/x/sys" to properly handle isTerminal in latest macOS

ref https://github.com/sirupsen/logrus/issues/1275

Fix infinite loop

Behavior before fix: getUUIDsByType loops infinite when field length is zero. I don't know why the field length can be zero.

Merge pull request #88 from orangenpresse/master

Race condition in Send fixed

Created at 2 months ago

ts

Created at 2 months ago

kubernetes, gpus

Created at 2 months ago

resume update for rd

Created at 2 months ago