buttplugio / buttplug

Rust Implementation of the Buttplug Sex Toy Control Protocol
https://buttplug.io
Other
895 stars 65 forks source link

Specific Lovense LUSH3 causing exception (and Hush and Lapis) #601

Closed DavidNorman closed 1 week ago

DavidNorman commented 11 months ago

Describe the bug I have 2 Lovense Lush 3 devices. One works well with buttplug.io, but the other one causes an exception when it is scanned. Sadly I cannot remember which I bought recently. One has the device string LVS-Lush, and the other LVS-Lush352.

The one with 352 works with your system, the other one does not.

the 352 one has one service, starting 53300001 the non working one has two services, one as above, and one starting 984227f3. this one still only advertises the 53300001 service, but that service is the second in the enumerated list of services if that makes any difference.

Expected behavior Both should function identically.

Actual behavior When scanning one, an exception occurs in some worker thread and the system stops.

Additional context Add any other context about the problem here. Screenshot 2024-01-03 at 20 45 00

DavidNorman commented 11 months ago

the one which doesn't work also has a couple of extra generic type characteristics, like the manufacturer name

DavidNorman commented 11 months ago

the same issue happens with my relatively new Lapis toy. It has the same extra services and the same extra characteristics, although the error is very slightly different.

Screenshot 2024-01-03 at 21 05 23

DavidNorman commented 11 months ago

Maybe the "questionable assumptions" are not valid, although i don't know enough about Bluetooth to know:

    fn check_discovered(&mut self) {
        // It's time for QUESTIONABLE ASSUMPTIONS.
        //
        // For sake of being lazy, we don't want to fire device connection until
        // we have all of our services and characteristics. We assume that
        // set_characteristics should be called once for every entry in the
        // service map. Once that's done, we're filled out enough and can send
        // back a Connected reply to the waiting future with all of the
        // characteristic info in it.
        if !self.services.values().any(|service| !service.discovered) {
            if self.connected_future_state.is_none() {
                panic!("We should still have a future at this point!");
            }
DavidNorman commented 11 months ago

This is the log from before the error. This is actually the log from a relatively new Lovense Lapis.

Screenshot 2024-01-03 at 21 35 50

DavidNorman commented 11 months ago

I note that the required service is the right one (starting 553000001) and the characteristics that it finds are also the right ones.

DavidNorman commented 11 months ago

Now i've seen a similar thing happen with the one that works. I am on a MacBook Air 7.2, running MacOS 10.15.7

It seems unlikely but could the machine be failing to service something in time?

nevertheless, the newer toys (including my Hush as well) all cause the problem during connection, while the older one does not.

garryrot commented 8 months ago

I noticed the same issue for the Hush 2 on MacOS (11.7.10) on an old Macbook Air from (2013).

Intiface App Version 2.5.5. Device Config Version 2.25

1a51c3a70763375050be47797553487d06e267ee5654692ae35b71afafb77ebc

Seems to be MacOS specific, as it works on Windows.

qdot commented 8 months ago

Ok hmm. I guess we've got some sort of race issue down in btleplug. I'll try to check it out soon.

qdot commented 8 months ago

Not sure why this got closed? It's not fixed yet. I've at least made a followup on btleplug.

qdot commented 1 week ago

We completely overhauled the corebluetooth system in btleplug, so I'm going to mark this as closed for now, we can either file a new bug or re-open if it keeps popping up.