[Pkg-utopia-maintainers] Bug#773525: Bug#773525: Randomly excludes available connections [when there are too many?]

[Dan Williams]

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 at 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