On Thu, 2015-07-16 at 19:16 +0200, Michael Biebl wrote: > Am 19.12.2014 um 15:32 schrieb Pietro Battiston: > > Package: network-manager > > Version: 0.9.10.0-4 > > Severity: grave > > > > Copypasted from a shell: > > > > pietro@debiousci:~$ for i in `seq 1 10`; do nmcli c | wc; done > > 127 637 12827 > > 127 637 12827 > > 127 627 12827 > > 126 628 12726 > > 127 629 12573 > > 127 634 12828 > > 127 629 12827 > > 127 630 12319 > > 127 631 12827 > > 127 627 12827 > > > > > > I am clearly not changing my list of available connections (so quick!). So > > what > > is happening is that network-manager is dropping some of my registered > > connections, in a random way. Initially I though "it is unable to handle > > more > > than 127", but then I saw that sometimes it only lists 126. The output of > > "nmcli c" is otherwise almost sane (see below). > > Seeing the latest upstream release, it noticed the following commit [1]: > > > dbus: increase 'max_replies_per_connection' limit in D-Bus configuration > > D-Bus default limit of replies per connection has been lowered to 128 due to > > CVE-2014-3638, see: > > http://cgit.freedesktop.org/dbus/dbus/commit/?id=5bc7f9519ebc6117ba300c704794b36b87c2194b > > https://bugs.freedesktop.org/show_bug.cgi?id=81053 > > > > The limit seems to be too low and causes problems in libnm-glib, that will > > not > > return all NetworkManager connection profiles if there are too many of them > > (roughly more than the limit). As a consequence, libnm-glib based clients > > will > > not work properly. > > This looks like it could be the reason for the problem you are seeing. > > That said, I'm not sure if individual daemon packages overriding the > dbus policy in that regard is a good idea (and a proper fix). > > I've CCed the upstream maintainers of NM and dbus. Maybe we can find a > solution for this.
There really isn't any solution that I can think of, except serializing the requests in the client libraries. Unfortunately, that's not a great way to go about it and it simply complicates the code on the client side. For example, say you have perhaps 40 saved connections and you're in a large city and so can see 30 or 40 access points. When some client starts up, it may request all of these initially, and also request properties on the objects when some of the initial replies come back. Obviously all of this happens asynchronously because blocking in a UI is bad. It's quite easy to run over 128 pending replies. Attempting to serialize these in libnm-glib (or libnm for that matter) would likely result in a bunch of code that's just a wrapper over dbus-glib and one more layer of suck-itude. We do have the 'libnm' library with NM 1.0+ that uses GDBus all the way through, so if GDBus somehow manages to avoid this problem then great. Otherwise, we'll have the same problem in libnm too... Simon, any thoughts here? Dan _______________________________________________ Pkg-utopia-maintainers mailing list [email protected] http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-utopia-maintainers
