GAN i3 not recognized

[anicolao]

To Reproduce Steps to reproduce the behavior:

1. Use alpha.twizzle.net's editor with a GAN bluetooth cube as the input method.
2. Check the console in Chrome's inspector to observe:

TwistyStreamSource.ts:112 Uncaught (in promise) DOMException: No Services matching UUID 0000fff0-0000-1000-8000-00805f9b34fb found in Device.

Expected behavior The devices services should be recognized.

Browser: All platforms, but tested with

Chrome	104.0.5112.101 (Official Build) (arm64)
Revision	0a2e5078088fc9f9a29247aaa40af9e7ada8b79f-refs/branch-heads/5112@{#1477}
OS	macOS Version 12.3.1 (Build 21E258)

[anicolao]

The root cause of this issue is that the protocol has changed for the i3. It advertises new services and there is a new way of discovering what the correct encryption key is.

The existing source code boasts being a clean room implementation so I was hesitant to just put up a patch that fixes this. My approach would be to look at existing OSS libraries and fix this problem.

Also I would do the communication with the GATT services totally differently than it is currently done. In the existing codebase, anyone can send a request to the GATT server but the server can only handle one request at a time, often causing requests to fail unexpectedly. I'd have an I/O queue wrapped around the bluetooth stack so that requests are processed in a FIFO order and serially, with performance stats per request (e.g. getting the last 6 moves takes 30ms, but in the current codebase that is hard to know).

If someone can clarify what the rules are for editing this code, both in terms of 'clean room'-ness and in terms of how big a patchset you are prepared to accept, I will make the corresponding modifications. I currently only own the i3 and the prior gen GAN cubes, but if we're happy with how it is coming out I'd consider supporting other bluetooth cubes as well.

[lgarron]

The clean room implementation is important. I'm also definitely open to refactoring the code (and have taken a stab or two at it, but not all of it worked).

If you're specifically looking for i3 support, could I suggest this?

• You help get me clean-room documentation for the i3, whether it's just characteristic or encoding/encryption changes.
• I implement changes for support. (I have a physical i3 for testing.)
• After those, we tackle general refactoring.

How does that sound?

[anicolao]

I probably interpret clean room too strictly to be of any use to you. While I am interested in i3 support, I have already read code that explains how the device works and whose provenance I am unaware of, and therefore couldn’t make the claim that information I provide was acquired in a ‘clean room’ way, which I’d interpret to be me directly doing the reverse engineering without reference to other people’s work or results.

So unfortunately in my way of thinking about it, I am already ‘tainted’ with potentially unfair knowledge, and can’t contribute to any i3 effort. Sorry about that.

[lgarron]

I probably interpret clean room too strictly to be of any use to you.

Yeah, I understand. But it wouldn't necessarily have to be you.

I'll take a look at the changes to the BLE characteristics when I get a chance, though. If they haven't changed the encoding too much, I may just need to know the latest encryption key.

[anicolao]

I will refrain from more commentary on this issue, other than to say that I know it to be more complicated than you describe. So possibly refactoring the code so that I can plug in my own implementation for the protocol is something I can do to the library codebase, and have my i3 implementation in my application. I am not in a hurry for this though, so I'll wait and see if this gets done before that by you or someone else ... I am much more anxious to see the other pull requests I have landing so that I can finish off with the library work and work on my intended application instead.

[malfurion]

hey there i'm also interessted in an i3 implementation i've already checked the ble services but couldn't find anything helpful but my knowledge about ble is a bit rudimental so perhaps you have some more luke with it XD

please let me know if i can help you guys testing something

[ghost]

Hi @lgarron

I've been able to work out the encryption and encoding of the i3, but I've had to modify your unsafe-raw-aes.ts implementation slightly. The changes are backwards compatible (I think) so shouldn't affect the other use cases. I'll open a PR with the crypto related changes shortly, it would be good to have your eyes on it. Still working out some efficiency in the gani3 implementation before I can post the rest.

While I'm still testing out a few things, I'm wondering if you could help me understand how to set the initial state into twisty when the device connects. The only way I've found to set the state in twisty, is to pass twisty an Alg, but all I have is the KState state of the cube. I noticed there was a experimentalSetStartStateOverride but that seems to be gone, and dependent upon the cursor implementation that's no longer around.

For now, I'm just using the SVG visualizer, but it would be good to know if there's a 3D way.

[lgarron]

@nagytech Glad to hear it!

While I'm still testing out a few things, I'm wondering if you could help me understand how to set the initial state into twisty when the device connects. The only way I've found to set the state in twisty, is to pass twisty an Alg, but all I have is the KState state of the cube. I noticed there was a experimentalSetStartStateOverride but that seems to be gone, and dependent upon the cursor implementation that's no longer around.

I'm not entirely sure. Are you talking about tracking the current puzzle state in a variable? You should be able to store the KState directly.

[ghost]

Are you talking about tracking the current puzzle state in a variable?

I'm trying to load the current state of the cube into TwistyPlayer. Using the src/sites/experiments.cubing.net/cubing.js/bluetooth/index.ts page as a reference, we have this... https://github.com/cubing/cubing.js/blob/b7256caa14ceb9136c2330352a70cf6a9a63d847/src/sites/experiments.cubing.net/cubing.js/bluetooth/index.ts#L27-L37

and this...

https://github.com/cubing/cubing.js/blob/b7256caa14ceb9136c2330352a70cf6a9a63d847/src/sites/experiments.cubing.net/cubing.js/bluetooth/index.ts#L46-L56

The commented out code would be exactly what I need, but your experimentalSetStartStateOverride method doesn't exist anymore. And, as far as I can see, there's no way to set the state of the cube in twisty, other than to pass in an Alg().

I'm beginning to think that TwistyPlayer might not be the right visualizer as it's only meant to record and play back an Alg sequence, and I probably need to go down a few layers to the more primitive stuff.

Anyway, I've added the i3 stuff in #282. It's not 100% complete, but available for anyone else who wants to make it better.