Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

AddMatch eventually stacks up and breaks limit #19

Open
5CoJL opened this issue Jan 9, 2024 · 3 comments
Open

AddMatch eventually stacks up and breaks limit #19

5CoJL opened this issue Jan 9, 2024 · 3 comments
Labels
needs-info Further information is requested question Questions and Answers

Comments

@5CoJL
Copy link

5CoJL commented Jan 9, 2024

Hello, and thanks for this useful repo.

I am currently having a problem and a hard time figuring out its source. I've dwelved in the Tmds.Dbus codebase as well as this libraries' to no avail.

I am using a Pi4 as a gateway to periodically scan for specific devices in its vicinity. Eventually however, my service crashes with the error message:

dbus-daemon[489]: [system] Connection ":1.37" is not allowed to add more match rules (increase limits in configuration file if required; max_match_rules_per_connection=2048)

There might be a couple hundred devices around me, with no new devices coming and going.

method call time=1704712160.531241 sender=:1.37 -> destination=org.freedesktop.DBus serial=278 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=AddMatch
   string "type='signal',interface='org.freedesktop.DBus.Properties',member='PropertiesChanged',path='/org/bluez/hci0/dev_3A_A9_CC_B9_8F_37'"

I have logged the first three scans, with the following results:

  • On my first couple of scans, I can see the AddMatch messages piling up, reduced at each 15s scan as all devices get eventually seen by the gateway.
  • At each new scan, I can see the InterfacesAdded messages piling up with each device being added.
  • At the end of each scan, I can see an equal amount of InterfacesRemoved messages piling up with each device being removed.

But after a couple of days, I get the crash with the aforementionned error message of max_match_rules_per_connection exceeded.

I'm suspecting there might be some sort of AddMatch leak somewhere...
Perhaps my devices eventually get a new name, somehow, and are given a new match rule ?

A simple workaround is to reboot the service automatically at each crash, but I'd be interested in finding an elegant solution to be able to RemoveMatch. Do you think this might be a problem in the library, or am I lost in bluetooth translation ?

Thank you greatly for any insight, and I remain at your disposal for any further information.

@DamianSuess
Copy link
Contributor

Thank you @5CoJL for using this library

From what I can tell, this issue may not be coming from this library and may be from either DBus or potentially from the implementation. Would you be able to provide a code snip to further assist?

References:

@DamianSuess DamianSuess added the question Questions and Answers label Jan 11, 2024
@DamianSuess
Copy link
Contributor

@5CoJL, just a heads up, I published the latest version of this package which uses Tmds.DBus v0.15.0.

Give that a shot and let me know

@DamianSuess DamianSuess added the needs-info Further information is requested label Jan 11, 2024
@5CoVK
Copy link

5CoVK commented Jan 15, 2024

Thank you @DamianSuess for your answer. I am working with @5CoJL, allow me to give you more details about our issue.

I was able to reproduce the error by running a simple scan function (below). I am using your Linux.Bluetooth nugget package with the latest 5.66 version.

using Linux.Bluetooth;

namespace Scan
{
    public class Program
    {
        static async Task Main()
        {
            MyEventHandler handler = new MyEventHandler();

            int scanSeconds = 15;       // scan for 15 seconds
            int waitSeconds = 5;      // wait for 5 minutes
            int scan_count = 0;

            Adapter adapter = await BlueZManager.GetAdapterAsync(adapterName: "hci0");

            adapter.DeviceFound += handler.adapter_DeviceFoundAsync;

            while (true)
            {
                scan_count++;

                await adapter.StartDiscoveryAsync();
                await Task.Delay(TimeSpan.FromSeconds(scanSeconds));
                await adapter.StopDiscoveryAsync();

                Console.WriteLine($"Scan #{scan_count} complete. Total: {handler.newDevices} device(s) found.");
                Console.WriteLine($"Waiting {TimeSpan.FromSeconds(waitSeconds)} until next scan.\n");
                await Task.Delay(TimeSpan.FromSeconds(waitSeconds));
            }
        }
    }

    public class MyEventHandler
    {
        public int newDevices = 0;

        public async Task adapter_DeviceFoundAsync(Adapter sender, DeviceFoundEventArgs eventArgs)
        {
            Console.WriteLine($"[NEW] device found: {(await eventArgs.Device.GetAddressAsync())}");
            newDevices++;
        }
    }
}

To give you some context, we are working in an environment with roughly 200-300 Bluetooth devices around us. Our hypothesis is that since our program runs continuously, with time it catches more and more new devices from people walking around, until reaching the max_match_rules_per_connection limit.

Or could it possibly be that we have multiple match rules for a single device ...?

Is there a way to remove the match rules over time (based on a timer or with a clean() function passing RemoveMatch to DBus) ?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
needs-info Further information is requested question Questions and Answers
Projects
None yet
Development

No branches or pull requests

3 participants