Hi Christian,
On Tue, Jul 1, 2025 at 12:38 PM Christian Eggers <ceggers@xxxxxxx> wrote:
>
> 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 :-).
Yep
> 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.
Yeah, we should probably integrate all the roles into mesh, now about
mesh-cfgclient I wonder if we wouldn't be better off integrating it
into bluetoothctl directly though, so one can control all daemon with
that instead of resorting to different clients.
> 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.
Yeah, that is intentional so we don't have to replicate the GATT and
LE advertisement handling on meshd.
> >
> > > 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.
> > >
>
>
--
Luiz Augusto von Dentz
