When I open bluetooth settings, rquickshare tells me "A device is sharing nearby"

[boswelja]

As per the title, if rquickshare is running in the background, when I open my device Bluetooth settings, I get a notification telling me "A device is sharing nearby". If I open rquickshare at that time, there are no devices in the list.

rquickshare version: 0.7.1 OS: Pop!_OS 22.04

Please let me know if you need any more information (and how to collect it, I'm relatively new to Linux :sweat_smile:)

[Martichou]

I think there is a misunderstanding there.

If an Android device is sharing nearby and that you're on "Hidden from everyone" mode, the notification will be displayed to allow you to pass to a temporary visible mode (as per the notification).

It's normal that you don't see any devices in the list as the Android device have not processed to sending the file to your computer.

So this is a non-issue, feel free to reopen if you think I misunderstood your problem.

[boswelja]

Hey @Martichou, thanks for the quick response! I think I might've worded it a bit poorly, when I say "device" I mean my PC.

Consistently when I open Bluetooth settings on my PC, when rquickshare is also running, I see "A device is sharing nearby". This happens without me ever touching my Android device.

Here's a screen recording to hopefully clarify the issue:

https://github.com/Martichou/rquickshare/assets/15526339/6255fbeb-22d3-4b72-8bbd-36a57be3d491

I don't see a reopen button, so if this is indeed an issue please reopen it :smiley:

[Martichou]

Can you send me the output of the following commands?

$ hciconfig -a
$ btmgmt info

[boswelja]

hciconfig -a:

hci0:   Type: Primary  Bus: USB
    BD Address: 74:97:79:D8:8A:D4  ACL MTU: 1021:6  SCO MTU: 240:8
    UP RUNNING PSCAN ISCAN 
    RX bytes:1289158 acl:0 sco:0 events:26562 errors:0
    TX bytes:549420 acl:0 sco:0 commands:3313 errors:0
    Features: 0xbf 0x3e 0x8d 0xfe 0xdb 0xff 0x7b 0x87
    Packet type: DM1 DM3 DM5 DH1 DH3 DH5 HV1 HV2 HV3 
    Link policy: RSWITCH SNIFF 
    Link mode: PERIPHERAL ACCEPT 
    Name: 'pop-os'
    Class: 0x7c0104
    Service Classes: Rendering, Capturing, Object Transfer, Audio, Telephony
    Device Class: Computer, Desktop workstation
    HCI Version: 5.2 (0xb)  Revision: 0x1910
    LMP Version: 5.2 (0xb)  Subversion: 0x2402
    Manufacturer: MediaTek, Inc. (70)

btmgmt info:

Index list with 1 item
hci0:   Primary controller
    addr 74:97:79:D8:8A:D4 version 11 manufacturer 70 class 0x7c0104
    supported settings: powered connectable fast-connectable discoverable bondable link-security ssp br/edr hs le advertising secure-conn debug-keys privacy configuration static-addr phy-configuration wide-band-speech 
    current settings: powered connectable discoverable ssp br/edr le secure-conn 
    name pop-os
    short name 
hci0:   Configuration options
    supported options: public-address 
    missing options: 

[Martichou]

Ok so this does not make any sense.

I initially though that your computer were detecting his own BLE advertisement, but this can't be as it's not making any advertisement unless you share a file.

Are you a 100% sure that no nearby devices are currently sharing anything?

Can you provide the ~/.config/dev.mandre.rquickshare/logs/RQuickShare.log file? I don't think there'll be anything useful, but just in case :)

[boswelja]

Are you a 100% sure that no nearby devices are currently sharing anything?

I'm fairly sure, yep. I can count the number of devices within Bluetooth range on one hand, and none of them are trying to share anything :stuck_out_tongue:

Here's the log file RQuickShare.log

[Martichou]

Can you run the following debug build https://github.com/Martichou/rquickshare/actions/runs/8936624822 ? (present in Artifacts). It's an AppImage, you just need to chmod +x it then ./appimagename. This should launch it and display the logs in the terminal.

I'd then need the logs of when the issue is occuring. You should see a line with something like that poping up:

[0] 2024-05-03T08:59:32Z DEBUG rqs_lib::hdl::ble: BleListener: A device (hci0/dev_78_F4_D2_3E_55_F4) is sharing ({0000fe2c-0000-1000-8000-00805f9b34fb: [252, 18, 142, 5, 66, 0, 0, 0, 0, 0, 0, 0, 0, 0, 14, 187, 163, 97, 83, 202, 65, 159, 186, 0]}) nearby

[boswelja]

Unfortunately I didn't see any such logs in my terminal from that build

Screencast from 03-05-24 21:49:44.webm

[boswelja]

I also don't see any terminal output when a real device actually does start sharing, so I guess the log line is being skipped entirely somewhere

[Martichou]

Yeah indeed, logs are on another level for release build and ofc the CI built prod version. I've changed so that it now build debug and also added a ENV variable just in case we need it.

But TLDR, this https://github.com/Martichou/rquickshare/actions/runs/8938352661 build (once finished) should be better at giving logs. Could you try that? (takes about 10m to finish building)

[boswelja]

The logging output of that build appears to be the same as the last one, that is to say there are no additional logs :disappointed:

[Martichou]

Well get there.. it was my bad, I forgot to change paths in the CI as the builds are now debug (at least for CI).

This one should be ok: https://github.com/Martichou/rquickshare/actions/runs/8949058713

[boswelja]

No worries, workflows can be a pain to deal with sometimes :laughing:

This one gave the expected log output! I've reproduced the issue a handful of times, here's the full log output:

2024-05-05T04:53:45Z DEBUG rquickshare::logger: Finished setting up logging! yay!
2024-05-05T04:53:45Z DEBUG rquickshare: Starting setup of RQuickShare app
2024-05-05T04:53:45Z TRACE rquickshare: Begining of RQS start
2024-05-05T04:53:45Z  INFO rqs_lib: TcpListener on: 0.0.0.0:36473
2024-05-05T04:53:45Z  INFO rqs_lib::manager: TcpServer: service starting
2024-05-05T04:53:45Z  INFO rqs_lib::hdl::ble: BleListener: service starting
2024-05-05T04:53:45Z  INFO rqs_lib::hdl::mdns: Broadcasting with: pop-os
2024-05-05T04:53:45Z  INFO rqs_lib::hdl::mdns: MDnsServer: service starting
2024-05-05T04:53:45Z DEBUG rqs_lib::hdl::mdns: MDnsServer: visibility changed: Invisible
2024-05-05T04:53:45Z ERROR mdns_sd::service_daemon: unregister: cannot find such service i3r5dwr8n14aaa._fc9f5ed42c8a._tcp.local.
2024-05-05T04:53:51Z DEBUG rqs_lib::hdl::ble: BleListener: A device (hci0/dev_47_82_6B_69_70_F7) is sharing ({0000fef3-0000-1000-8000-00805f9b34fb: [74, 23, 35, 70, 72, 83, 71, 17, 50, 119, 115, 145, 5, 205, 246, 8, 173, 110, 140, 153, 68, 37, 158, 200, 11, 4, 185]}) nearby
2024-05-05T04:53:51Z TRACE rquickshare: Tauri: ble received: Invisible
2024-05-05T04:54:40Z DEBUG rqs_lib::hdl::ble: BleListener: A device (hci0/dev_54_15_89_A6_9B_B2) is sharing ({0000fddf-0000-1000-8000-00805f9b34fb: []}) nearby
2024-05-05T04:54:40Z TRACE rquickshare: Tauri: ble received: Invisible
2024-05-05T04:55:07Z DEBUG rqs_lib::hdl::ble: BleListener: A device (hci0/dev_54_15_89_A6_9B_B2) is sharing ({0000fddf-0000-1000-8000-00805f9b34fb: []}) nearby
2024-05-05T04:55:07Z TRACE rquickshare: Tauri: ble received: Invisible
2024-05-05T04:55:31Z DEBUG rqs_lib::hdl::ble: BleListener: A device (hci0/dev_54_15_89_A6_9B_B2) is sharing ({0000fddf-0000-1000-8000-00805f9b34fb: []}) nearby
2024-05-05T04:55:31Z TRACE rquickshare: Tauri: ble received: Invisible

If I'm reading it right, it looks like the hardware address of the very first time it happens is different from the rest, which is interesting :thinking: Based on that, I killed rquickshare and ran it again, which netted me this:

2024-05-05T04:57:00Z DEBUG rquickshare::logger: Finished setting up logging! yay!
2024-05-05T04:57:00Z DEBUG rquickshare: Starting setup of RQuickShare app
2024-05-05T04:57:00Z TRACE rquickshare: Begining of RQS start
2024-05-05T04:57:00Z  INFO rqs_lib: TcpListener on: 0.0.0.0:40623
2024-05-05T04:57:00Z  INFO rqs_lib::manager: TcpServer: service starting
2024-05-05T04:57:00Z  INFO rqs_lib::hdl::ble: BleListener: service starting
2024-05-05T04:57:00Z  INFO rqs_lib::hdl::mdns: Broadcasting with: pop-os
2024-05-05T04:57:00Z  INFO rqs_lib::hdl::mdns: MDnsServer: service starting
2024-05-05T04:57:00Z DEBUG rqs_lib::hdl::mdns: MDnsServer: visibility changed: Invisible
2024-05-05T04:57:00Z ERROR mdns_sd::service_daemon: unregister: cannot find such service izhezhj8n14aaa._fc9f5ed42c8a._tcp.local.
2024-05-05T04:57:05Z DEBUG rqs_lib::hdl::ble: BleListener: A device (hci0/dev_66_24_87_99_D9_03) is sharing ({0000fef3-0000-1000-8000-00805f9b34fb: [74, 23, 35, 70, 72, 83, 71, 17, 50, 119, 115, 145, 5, 205, 246, 8, 173, 110, 140, 153, 68, 37, 158, 200, 11, 4, 185]}) nearby
2024-05-05T04:57:05Z TRACE rquickshare: Tauri: ble received: Invisible
2024-05-05T04:57:23Z DEBUG rqs_lib::hdl::ble: BleListener: A device (hci0/dev_66_24_87_99_D9_03) is sharing ({0000fef3-0000-1000-8000-00805f9b34fb: [74, 23, 35, 70, 72, 83, 71, 17, 50, 119, 115, 145, 5, 205, 246, 8, 173, 110, 140, 153, 68, 37, 158, 200, 11, 4, 185]}) nearby
2024-05-05T04:57:23Z TRACE rquickshare: Tauri: ble received: Invisible
2024-05-05T04:57:52Z DEBUG rqs_lib::hdl::ble: BleListener: A device (hci0/dev_70_89_76_03_63_88) is sharing ({0000a201-0000-1000-8000-00805f9b34fb: [0]}) nearby
2024-05-05T04:57:52Z TRACE rquickshare: Tauri: ble received: Invisible
2024-05-05T04:58:08Z DEBUG rqs_lib::hdl::ble: BleListener: A device (hci0/dev_54_15_89_A6_9B_B2) is sharing ({0000fddf-0000-1000-8000-00805f9b34fb: []}) nearby
2024-05-05T04:58:08Z TRACE rquickshare: Tauri: ble received: Invisible

Which has different hardware addresses yet again! Very strange.

[Martichou]

Ok so there's definitely a bug. In theory the BleListener is configured to filter out any service that isn't as SERVICE_UUID_SHARING (as per https://github.com/Martichou/rquickshare/blob/master/core_lib/src/hdl/ble.rs#L40). But this filtering is delegated tu bluez through the btleplug crate.

In addition, it's clear that those are not Android Quickshare advertisement as the service_data are not what we expect. I'll add my own filtering on the service_data, it should resolve the issue, I'll link here the debug build so you can try :)

https://github.com/Martichou/rquickshare/actions/runs/8957270484 Could you confirm the issue is gone with this build?

[boswelja]

I've only tested it a couple of times, but that does seem to have fixed it! I'll check it a bit more thoroughly later to be sure, but it's probably fine

[Martichou]

Nice, I'll close this issue. If needed reply and we'll reopen :) (thanks for testing)