Hi Luiz,
On Tuesday, 1 July 2025, 18:07:06 CEST, Luiz Augusto von Dentz wrote:
> Hi Christian,
>
> On Tue, Jul 1, 2025 at 10:47 AM Christian Eggers <ceggers@xxxxxxx> wrote:
> >
> > This series adds initial support for the GATT Proxy Service feature.
> > This allows provision and management of MESH devices from mobile phones.
> >
> > Before continuing, I would be happy to get some feedback about this initial
> > part (and about what has to be done in order to mainline it). Any help for
> > doing the missing features (e.g. relaying between GATT and ADV) would be
> > highly appreciated.
> >
> > What seems to work:
> > - Provisioning from another Linux computer via meshctl (sometimes I need
> > to repeatedly enter 'discover-unprovisioned on' and 'provision <uuid>'
> > if it doesn't work on the first try).
> > - Reading the composition (composition-get in meshctl). It looks like
> > meshctl tries to connect to the GATT Proxy Service automatically after
> > provisioning, but I have to enter 'connect' several times in order to
> > get a connection. You also need to manually set the target unicast
> > address ('target' command in 'config' menu).
> > - Adding extra network keys (Advertising for GATT Proxy Service cycles
> > between different network ids every 3 seconds).
> > - Transferring and binding of application keys.
> > - Using the OnOff client in meshctl (you again have to set the unicast
> > address in the 'onoff' menu).
> > - Provisioning and configuration of an OnOff device from iOS (using
> > the SMART+ app from Ledvance). This app requires at least basic
> > support for proxy configuration messages (patch 4/4).
>
> Meshctl is sort of considered deprecated by meshd, it was created
> because at the time bluetoothd and meshd couldn't operate in the same
> controller so we need the GATT client to be used against bluetoothd,
> which is why the whole tools/mesh-gatt is sort of duplicated from
> mesh/ portion, but now that there is possible to have both bluetoothd
> and meshd we should probably move meshctl to be a client of meshd
> directly and then remove the whole tools/mesh-gatt/ directory.
<Not sure whether I understand you correctly>
I am working on the GATT Proxy Server (in bluetooth-meshd), whilst meshctl
implements the GATT Proxy Client. Having a deprecated test program is much
better than having nothing :-).
Although I haven't checked for this, I guess that meshctl could become completely
obsolete if GATT Proxy Client support was added to bluetooth-meshd. In this
case, provision would be done by mesh-cfgclient regardless whether the
link established by bluetooth-meshd is using ADV or GATT.
My patch series mainly makes bluetooth-meshd a client of bluetoothd (which
normally operate independently). As bluetoothd is (exclusively?) responsible
for GATT and LE advertising, using these technologies in meshd requires it
to use the D-Bus interfaces provided by bluetoothd.
>
> > What maybe added later:
> > - Proper selection of the output interface (GATT vs. ADV) when sending
> > messages.
> > - Relaying of network messages / beacons between GATT and ADV
> > interfaces (in order to access further devices via the proxy).
>
> Afaik the tools/mesh-gatt does already relay messages, but since it
> has been a long time I don't deal with mesh perhaps I don't remember
> it correctly so please have a look.
I only had a short look, but I think that tools/mesh-gatt can only perform
configuration of the 'relay' feature on a GATT Proxy Server (switch
relaying on/off on a remote system). But probably I haven't got the big
picture yet.
>
> > Note: I don't use the test-join script, because python3-pygobject is
> > (currently) not available on my (embedded) system. Instead, I use a
> > custom C++ program for the 'Join' and 'Attach' D-Bus calls.
> >
