Wat-now It looks like my system is really out of luck:) but would it make sense to try dbus-launch instead of dbus-run-session?
Connman-gtk shows blank
wastelander You may have to downgrade back to dbus-1.14.10-2, something is up with the permissions somewhere I suspect.
- Edited
Wat-now yes, I uninstalled dbus, wiped out the /usr/share/dbus-1 , downgraded to 1.14 and now its working. Wondering if we should patch connman to work with dbus 1.16 or the opposite.I also guess it's a permission issue, connman-gtk always works with sudo.
- Edited
This is a permission issue
** (connman-gtk:7668): CRITICAL **: 14:20:26.840: Failed to connect to connman: GDBus.Error:org.freedesktop.DBus.Error.AccessDenied: Rejected send message, 3 matched rules; type="method_call", sender=":1.2349" (uid=1000 pid=7668 comm="connman-gtk") interface="net.connman.Manager" member="GetTechnologies" error name="(unset)" requested_reply="0" destination=":1.451" (uid=0 pid=3010 comm="/usr/bin/connmand -n --nobacktrace --nodnsproxy")For now, i don't found the fix.
As you can see, the connection with dbus is made perfectly.
Found it.
edit your /usr/share/dbus-1/system.d/connman.conf as the following
<!DOCTYPE busconfig PUBLIC "-//freedesktop//DTD D-BUS Bus Configuration 1.0//EN"
"http://www.freedesktop.org/standards/dbus/1.0/busconfig.dtd">
<busconfig>
<policy user="root">
<allow own="net.connman"/>
<allow send_interface="net.connman.Agent"/>
<allow send_interface="net.connman.Counter"/>
<allow send_interface="net.connman.Notification"/>
</policy>
<policy group="network">
<allow send_interface="net.connman.Manager"/>
<allow send_interface="net.connman.Agent"/>
</policy>
<policy context="default">
<allow send_destination="net.connman"/>
</policy>
</busconfig>Here, we add the <allow send_interface="net.connman.Manager"/> for the network group.
If it's work i will change the connman package to implement the fix.
- Edited
eric after this change I can only see my current network in the UI, no other ones. Indeed in the terminal I have the same error as before preceded by Failed to scan Wifi
UPDATE: I think I fixed it! (source: https://github.com/aldebaran/connman/blob/master/src/connman-dbus.conf). I edited connman.conf this way:
<!DOCTYPE busconfig PUBLIC "-//freedesktop//DTD D-BUS Bus Configuration 1.0//EN"
"http://www.freedesktop.org/standards/dbus/1.0/busconfig.dtd">
<busconfig>
<policy user="root">
<allow own="net.connman"/>
<allow send_destination="net.connman"/>
<allow send_interface="net.connman.Agent"/>
<allow send_interface="net.connman.Counter"/>
<allow send_interface="net.connman.Notification"/>
</policy>
<policy group="network">
<allow send_destination="net.connman"/>
</policy>
<policy context="default">
<allow send_destination="net.connman"/>
</policy>
</busconfig>It seems to work fine now. Can you try it on your side?
- Edited
@Wat-now can you also test this configuration but with the dbus Arch patch applied too? I have just downgraded dbus to 1.16.0-4 (the patched release) and it works fine, so I really think that the patch wasn't the offender.
wastelander You're right the patch wasnt the offender, but it really isnt important on a non-systemd system. It just removes some folders in /etc/dbus-1 and /run/dbus, plus changes the user id in sysusers that doesnt work in a build system without systemd- which is why Eric did it manualy in the PKGBUILD with release 1.16.0-4.
wastelander
For me it is working fine!
Thank you.
- Edited
igorka67 no prob, glad it worked for you too, now the fix can be safely applied to the package in the repos as long as it works:)
- Edited
Wat-now good, so the only needed commit is to patch that connman.conf file.
Btw I have seen that it's the same change that's present in the official Debian package, though they don't use a policy for a network group:
https://salsa.debian.org/debian/connman/-/blob/debian/sid/src/connman-dbus.conf?ref_type=heads
- Edited
@Wat-now my proposed configuration might work but is possibly incorrect. The debian configuration is not really theirs, it's simply the default upstream source configuration. Arch removed by purpose the allow send_destination line (that I reintroduced) from the root policy block and replaced the policy at_console block with a network group policy, the latter containing the allow send_interface line. So it's not that straightforward as it seemed and the changes that I made might not really make sense. I even tried the default source configuration but it didn't work, so far the only working configuration is the one that I posted before...
wastelander ok I will change send_interface to send_destination in the connman rebuild, thanks for clarifying.
- Edited
Wat-now no prob, thanks to you:) I don't know if the send_destination line is necessary for the root policy section too, in my test I had put it in both the root and network sections.
UPDATE:it looks like your change is enough, I only added send_interface to the network section and connman works after reloading
5 days later
- Edited
@Wat-now just an update, I opened an issue on the connman Arch gitlab asking for an opinion on my "fix". The packager has told me that I'm on my own with this change because connman works fine with their settings, and that connman-gtk is an AUR unsupported package based on an old version of connman. Issue closed.
So the choice is keep connman-gtk with this unsupported patch or switch to networkmanager by default.
9 days later
@Wat-now I went on with my research and I think that the actual change is indeed not the best one in terms of security. We are granting the network group total control over connman, a safer solution would be that one:
<policy group="network">
<allow send_destination="net.connman.Manager"/>
<allow send_interface="net.connman.Manager"/>
</policy>Reference: https://www.reddit.com/r/voidlinux/comments/oyqr6i/cmstconnman_not_working_on_lxqt/
Tested and working on my side.
wastelander does it workk just as well with <allow send_interface="net.connman.Manager"/> without <allow send_destination="net.connman.Manager"/> or does it need both?
- Edited
Wat-now as far as we're talking about wireless scan it looks like the line<allow send_destination="net.connman.Manager"/> is enough. I don't know about other functions though, it's possible that the other line <allow send_interface="net.connman.Manager"/> is useful for advanced options or Bluetooth or something. I have seen a line like that in different configurations, maybe it could be safe to keep it.
However, adding only <allow send_interface="net.connman.Manager"/> doesn't work for me. So I'd keep both the lines.
wastelander I'm a minimalist, so I lean toward only adding the necessary line until I know for sure the allow send_interface is needed for bluetooth or etc..
Wat-now it's fine, I'm a minimalist as well:) I think that adding that ". Manager" should be fine to restrict the network group to this specific task.