How to start/stop WLAN (instead of using binaries running as root)

Applications Others
#1

Hei Sailors!

I am trying to get an AARCH64 build of WiFiKilL3r. As it turns out, there are some pre-compiled 32bit binaries shipped with the original code to start and stop WLAN (as root)

I am wondering how these could be best replaced with some new code, since sources for the binaries are not available.

#2

Might be answering myself:
As it turns out, the binaries are copied from @schturman’s old Wifi On/Off app.
According to this old TJC question, WLAN can be turned off using DBUS:

dbus-send --system --print-reply --dest=net.connman /net/connman/technology/wifi net.connman.Technology.SetProperty string:"Powered" variant:boolean:false

Tested on SFOS 4.5.0.19. Still works :slight_smile:

1 Like
#3

Well, the DBus command works fine in terminal but not from within code (process is missing the permissions).

I could use some expertise on DBUS permissions for Python or the Nemo DBus QML API, if there someone knowledgeable around :wink:

1 Like
#4

I think granting the app the Internet permission would allow that call to work.

You can do that with placing an override in /etc/sailjail

2 Likes
#5

I had tried granting the Connman permission directly (see @poetaster’s list) inside the .Desktop file.
After your comment, I found out that this is actually included in Internet permission. Which - in turn - is part of the default permissions set in the default profile (/etc/sailjail/config/50-default-profile.conf).

Unfortunately neither of them yields the necessary DBus permissions. I am manually testing this with sailjail to see logs:

sailjail -v -p /usr/share/applications/WiFiKilL3r -- /usr/bin/WiFiKilL3r

Once tapping the WLAN button in the app, I get this error (code called by the UI is below):

[D] onError:81 - python error: Return value of PyObject call is NULL: Traceback (most recent call last):

  File "/usr/share/WiFiKilL3r/qml/python/WiFiKilL3r.py", line 194, in disable_wifi
    reply = wifi_interface.SetProperty("Powered", False)

  File "/usr/lib64/python3.8/site-packages/dbus/proxies.py", line 72, in __call__
    return self._proxy_method(*args, **keywords)

  File "/usr/lib64/python3.8/site-packages/dbus/proxies.py", line 141, in __call__
    return self._connection.call_blocking(self._named_service,

  File "/usr/lib64/python3.8/site-packages/dbus/connection.py", line 652, in call_blocking
    reply_message = self.send_message_with_reply_and_block(

dbus.exceptions.DBusException: net.connman.Error.PermissionDenied: Permission denied

What I have come up with in Python so far (modified from @theyosh’s original sources):

def disable_wifi():
  bus = dbus.SystemBus()
  # connect to connman over dbus
  connman = bus.get_object("net.connman", "/net/connman/technology/wifi")
  wifi_interface = dbus.Interface(connman, "net.connman.Technology")
  reply = wifi_interface.SetProperty("Powered", False)
  logger('Disable wifi with DBUS')
  logger(reply)

def enable_wifi():
  if not is_wifi_enabled():
    bus = dbus.SystemBus()
    connman = bus.get_object("net.connman", "/net/connman/technology/wifi")
    wifi_interface = dbus.Interface(connman, "net.connman.Technology")
    reply = wifi_interface.SetProperty("Powered", True)
    logger.info('Enable wifi with DBUS')
    logger.info(reply)
1 Like
#6

From my limited understanding though that means talking to the relevant dbus interface works fine (so the sailjail permissions do work), but then the command/call is denied by policy.

How to pierce a hole in that I don’t know, but i’ts for sure in one of the dbus config XML files (/etc/dbus-1??).

https://dbus.freedesktop.org/doc/dbus-daemon.1.html

(And like with everything coming out of F.D.O., likely, overengineered, hacker-unfriendly, probably deprecated, hard to understand, and hard to use.)

#7

I had one, faintly hopeful, idea. What about the internet and compatibility permissions?

#8

Thanks for your suggestions, guys.
Ill look into the compatibility permission.

When reading up a bit about the Nemo Dbus API, I noticed @direc85’s Battery Buddy is using it to control charging.
possibly WLAN can be, too.

of course, as always time is a scarce resource so might take some time until I get to play around with it.
just leaving this here so anyone interested can follow up

1 Like