Re: Exposing bssid information

James Hanley <[email protected]>
Newsgroups dev.linux.lists.iwd
Message-ID <CAF++6AMYxXJZg_im3z_4PDgUj0tr7t4Ag0KFetoTu-SKuYcYVQ@mail.gmail.com>
Thanks - this is really helpful for direction. I was going to
initially brute force load all the attributes into a new interface,
but it seems the preferred course from your suggestion is to gather
the ESSID information and query each node individually for the BSSID
information and populate that method with the associated details?

One point that I'm stumbling on in testing the pristine codebase is
accessing the ExtendedServiceSet property:
test-wifi/test# dbus-send --system --type=method_call --print-reply
--dest=net.connman.iwd /net/connman/iwd/0/2/53-elided-53_psk
net.connman.iwd.Network.ExtendedServiceSet
Error org.freedesktop.DBus.Error.NotFound: No matching method found

When I query for the available interfaces and methods, I am able to see:
test-wifi/test# dbus-send --system --type=method_call --print-reply
--dest=net.connman.iwd /net/connman/iwd/0/2/53-elided-53_psk
org.freedesktop.DBus.Introspectable.Introspect
method return time=1739996534.609643 sender=:1.1090 ->
destination=:1.1474 serial=2631 reply_serial=2
   string "<!DOCTYPE node PUBLIC "-//freedesktop//DTD D-BUS Object
Introspection 1.0//EN"
"http://www.freedesktop.org/standards/dbus/1.0/introspect.dtd">
<node>
        <interface name="org.freedesktop.DBus.Introspectable">
                <method name="Introspect">
                        <arg name="xml" type="s" direction="out"/>
                </method>
        </interface>
        <interface name="net.connman.iwd.Network">
                <method name="Connect">
                </method>
                <property name="Name" type="s" access="read"/>
                <property name="Connected" type="b" access="read"/>
                <property name="Device" type="o" access="read"/>
                <property name="Type" type="s" access="read"/>
                <property name="KnownNetwork" type="o" access="read"/>
                <property name="ExtendedServiceSet" type="ao" access="read"/>
        </interface>
        <interface name="org.freedesktop.DBus.Properties">
                <method name="Get">
                        <arg name="interface_name" type="s" direction="in"/>
                        <arg name="property_name" type="s" direction="in"/>
                        <arg name="value" type="v" direction="out"/>
                </method>
                <method name="Set">
                        <arg name="interface_name" type="s" direction="in"/>
                        <arg name="property_name" type="s" direction="in"/>
                        <arg name="value" type="v" direction="in"/>
                </method>
                <method name="GetAll">
                        <arg name="interface_name" type="s" direction="in"/>
                        <arg name="props" type="a{sv}" direction="out"/>
                </method>
                <signal name="PropertiesChanged">
                        <arg name="interface_name" type="s"/>
                        <arg name="changed_properties" type="a{sv}"/>
                        <arg name="invalidated_properties" type="as"/>
                </signal>
        </interface>
        <node name="d8-elided-95"/>
        <node name="d8-elided-55"/>
        <node name="d8-elided-15"/>
        <node name="d8-elided-95"/>
        <node name="d8-elided-55"/>
        <node name="d8-elided-95"/>
</node>
"

Is there something I'm missing in attempting to access this detail
from dbus-send?  Ultimately this is only for testing, but I do plan on
using the DBusConnection c-api and getting it right with dbus-send
will help me in defining the code flow.

-Jim

On Sat, Feb 15, 2025 at 3:29 PM James Prestwood <[email protected]> wrote:
>
> Hi Jim,
>
> On 2/15/25 12:10 PM, James Hanley wrote:
> > Hi,
> > I’m looking to access (and/or expose) via dbus scanned information on
> > bssid. Specifically, information as follows:
> >
> > {
> >    "wifiAccessPoints": [
> >   {
> >    "macAddress": "f0:d5:bf:fd:12:ae",
> >    "signalStrength": -43,
> >    "signalToNoiseRatio": 0,
> >    "channel": 11,
> >    "age": 0
> > },
> > {
> >    "macAddress": "3c:37:86:5d:75:d4",
> >    "signalStrength": -35,
> >    "signalToNoiseRatio": 0
> > },
> > {
> >    "macAddress": "30:86:2d:c4:29:d0",
> >    "signalStrength": -35,
> >    "signalToNoiseRatio": 0
> > }
> >   ]
> > }
> >
> > This would be for geolocation services such as skyhook or google
> > https://developers.google.com/maps/documentation/geolocation/requests-geolocation
> > to allow a device to estimate its location. It seems that what is
> > exposed is ESSID information with the strongest AP, or does is this
> > information already exposed in iwd and which module/interface should
> > be used? If not exposed, which model would be the most appropriate to
> > add this to - scan, station, or another - and what interface for dbus
> > should the method be exposed through?
>
> Take a look at the ExtendedServiceSet property [1] on the network
> objects. This contains a list of BasicServiceSet object [2] paths. At
> the moment the BasicServiceSet objects only contain the BSSID as this
> was all I really needed for the affinity functionality, but I'm not
> opposed to additional info being added such as signal strength/channel
> etc. If you need any pointers for this let me know, but it should be
> relatively straight forward to add extra properties in the interface
> setup [3].
>
> iwctl also supports showing the BSS object paths/properties via:
>
> "station wlan0 get-bsses"
>
> [1]
> https://git.kernel.org/pub/scm/network/wireless/iwd.git/tree/doc/network-api.txt#n54
> [2]
> https://git.kernel.org/pub/scm/network/wireless/iwd.git/tree/doc/basic-service-set.txt
> [3]
> https://git.kernel.org/pub/scm/network/wireless/iwd.git/tree/src/network.c#n2196
> >
> > -Jim
> >
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.