At some point in the past few weeks, the following command has started failing when creating virtual smart cards on a Surface Pro device:
tpmvscmgr create /generate /adminKey random /pin default /name Example /attestation AIK_AND_CERT
Requests fail with (0x80190190) Bad Request (400).
It is possible to create a virtual smart card without the /attestation flag (which is what I have typically done in the past). However virtual smart cards created this way fail when attempting to generate a certificate request including an attestation. Specifically, attempts to generate a certificate request using a CertificateRequestProperties structure with the AttestationCredentialCertificate field set fail with 0x80100022 - This smart card does not support the requested feature.
These errors occur on devices that previously worked. Any ideas why the behavior has changed or if it is temporary?
The issue was resolved by applying firmware patches to the Surface Pro 3 and Surface Pro 4 devices. The firmware update tool for Surface Pro 3 is here: https://www.microsoft.com/en-us/download/details.aspx?id=38826. The update for Surface Pro 4 is here: https://www.microsoft.com/en-us/download/details.aspx?id=49498. After updating the firmware, tpmvcsmgr was able to create virtual smart cards using the AIK_AND_CERT parameter and the UWP APIs to include attestations in CSRs worked. It seems like the 1803 update included a change that requires these firmware patches.
Related
I am having issues deploying to the Polygon Mainnet. I can deploy easily to Polygon Testnet but have yet to successfully deploy to mainnet. I have tried using Truffle, Hardhat and Remix without various errors. Most errors are receiving null back in the blocks in truffle or are gas related. I've increased gas and then I'll get the timeouts or null returns when querying block during deployment. I can't even deploy a 20 line tutorial contract.
Is anyone else having issues and is this a known issue. I find nothing on the web to tell me. I can provide additional information but I think this is a Polygon network issue and I'm trying to confirm.
Manualy Edit the gas fee to higher on the metamask wallet during the deployment and you will be able to deploy smart contract on polygon network.
Metamask gives you options so i chose to use higher priority gas fee and it worked. No more issues
I'm using the SwiftySensors CocoaPod to connect to a Wahoo Smart Trainer. It's advertising CyclingPowerService and DeviceInformationService. I've been able to get speed and power values without issue. Wahoo apparently extended the CyclingPowerService standard to allow setting resistance via that service instead of the Fitness Machine Control service.
https://github.com/codeinversion/sensors-swift links out to another Github page dealing with that extension, but that link is broken.
My question is: how should I go about setting the trainer's resistance? Wahoo's app can do it, so the machine is equipped for it. This is the only time I need to change the trainer's settings. Otherwise, I'm just reading sent information and SwiftySensors works great.
I've referenced the following post: Writing BLE to Cycling Control Point - Adding Resistance. Someone there said using CyclingPowerService to set resistance was possible without offering any guidance. I'm not very experienced with Bluetooth, so any information would be great!
Thank you Jordan. That was the answer. The broken link I referenced must have been pointing to the following repo: https://github.com/WahooFitness/sensors-swift-trainers
The following instructions assume that you're already able to connect to the trainer to receive data from it, like speed and power, using the SwiftySensors CocoaPod and the CyclingPowerService. Using the repo linked above, I was able to set the resistance to the Wahoo Snap trainer. Note that after you install that new repo, before you start scanning for sensors to connect to, you need to call
CyclingPowerService.WahooTrainer.activate()
From there, you set the resistance with
if let wahooTrainer = cyclingSpeedService.wahooTrainer {
wahooTrainer.setResistanceMode(resistance: 0.5)
}
The resistance is set using percentages. The value for resistance will be a Float, somewhere between 0 and 1.
I've been experimenting with some UEFI/Kernel code and am working on the various PCI-Express elements. I have obtained the MCFG ACPI table, Enumerated all PCI devices into my own structures and have access to all the devices MMIO regions and the full 4kb configuration space.
For this specific PCIe device which I have identified I have followed the configuration space as follows:
Test capability list bit, assuming it is set,
use offset 0x34, follow the pointers until I find a PCI Express configuration capability (ID = 0x10).
From here register 0x0c (Link capabilities) specifies the max link width as x16 and the max link speed as 3 (which is an index into the supported link speed vector and equates to 8.0 GT/s or Gen3 speed which the device is capable of).
The link status register is showing that the negotiated link width is x16, however the link speed is 1 (2.5 GT/s).
What I've tried is using the Link Control 2 Register to set the Target Speed to 3 then set Bit 5 on the Link Control Register to trigger a re-training. I also disable the autonomous link speed to ensure the device remains at the selected speed.
I then wait a small duration (1 second for testing) then poll the Link Status register checking for the Link Training bit to clear. This seems to clear immediately regardless of the above delay and when checking the Link Status register again the link speed is still 1.
I have checked several of the registers for error notifications and haven't spotted anything yet.
Clearly I need to find the correct process to establish a new link speed on the device, possibly configure de-emphasis values or apply the same link speed settings to upstream devices/bridges.
Any advice would be hugely appreciated.
Due to hardware restrictions, we are unable to retrieve the current status of many of our lights (their color/brightness/etc.).
In the QA test cases spreadsheet found here, at the bottom under Deploying, a number of QUERY intents are listed to be tested. Does this mean our Smart Home application will not be able to pass certification?
Thank you for reading.
There is some expectation from the user to know the status of your their house at any time. If you cannot retrieve the state directly from devices, you should be able to use your cloud provider to store a virtual equivalent of the device. Then instead of querying the device directly you can return the state of the virtual device.
If anything, just try to be honest with the review team and they will keep certain limitations in mind.
When submitting for review make sure you provide them with a perfectly working test environment. So if some of your lights don't function like you want them to and you can't get their info, don't provide them for testing.
I'm not familiar with the review process of Smart Home applications but if you provide the review team with the right information of which hardware is and isn't supported I'm sure they won't straight up reject your application for it.
For a student project, we're working on connecting a Bluetooth LE device (that both transmits and receives) to an iPhone or iPad in order to read data from it to display to the user in realtime. We have proof that this is doable by the company that made the device and we've actually managed to get a connection and get some data.. however it pings every 5-10 seconds and seems to be a random subset of numbers with minimal changes after changing something on the device which is making us none the wiser.
Now, of course, we went to the company that made the device and app first and we do have approval for us to use their hardware, but haven't been able to get a SDK / API from them to use with the application. So, our plan is to make our own way through it and find what we need.
This is where we're getting stuck. We have the following:
Connection based on Name or Bluetooth Device Address
Scan services (and cascading scan in case the services have services within them as specified in the CoreBluetooth documentation)
Read Characteristics from said services.
Decrypt value into 8bit UInt so we get some actual readable data.
This is an example of what we've got with the value still as it comes in.
Service: 0x1c0476440, is Primary = yes. UUID: 058d0001-ca72-4c8b-8084-25e049936b31
value <53636da1 7a616c74 73616c74 73616c74 73616c27>
Now, looking at this all, I presume the service here is some kind of 'staying alive' ping and it's giving some auxiliary info about the device's current state.
The question we have then boils down to this:
How can we further 'explore' the device? We don't seem to be getting any additional output aside from this however looking in the device manager from windows we get a couple of hits that look like this (Example):
{058d0001-ca72-4c8b-8084-25e049936b31}[6]
Which have values in either a hexidecimal value, boolean or datetime without clear identifiers. Is there a way for us to send a message to the device to change the value in that uuid using Swift, or is this impossible?
While solved now, I'm not accepting this as the answer. My solution? Try things. Stupid 'Needle in a haybale' things.
I changed the uuid from 058d0001-ca72-4c8b-8084-25e049936b31 to 058d0002-ca72-4c8b-8084-25e049936b31
and voila. I could do more. I tried 3, and again, a new result and a working data stream...
#Paulw11's comment is also a good way to solve this issue we found out.