Hi Yury, On Tue, Dec 17, 2019 at 7:47 AM Yury Galustov <yury@xxxxxxxxxxxxxxxxx> wrote: > > Hi, > I’m trying to use BlueZ 5.52 installed on Raspberry Pi 4 to provision mesh network. > > The initial provisioning works fine and I’m able to provision and control device, but if I close meshctl and then open it again then all commands related to data transmission fail with ‘Failed to AcquireWrite’ error here gatt.c:367 > > I’ve googled a lot and checked the source code and see that the problem might be somehow related to the OS itself and file descriptor lock, but I haven’t found any solution yet. > Currently digging into g_dbus_proxy_call with no luck … > > Steps to reproduce: > > 1. run meshctl > 2. discover-unprovisioned on > 3. provision <uuid> > 4. menu config > 5. target 0101 (newly added device unicast address) > 6. ttl-get > Steps 1-6 work fine > > 7. exit meshctl and launch it again > 8. connect <newly added device unicast address> > 9. target <newly added device unicast address> > 10. ttl-get (or any command that transmits data) fails with ‘Failed to AcquireWrite’ > > I've also tried the latest code from master branch but got the same error. > Any ideas where I need to look )? 2 things that might help, closing the all fds when exiting, though the kernel should have done that already if the process is really terminated properly, perhaps it is not which is why the daemon still things there is a process holding on the fd, the second thing is to check if there is code in place to monitor if process disconnects from D-Bus and cleanup the socket pairs, though if the process is not really exiting that would have the same result since the D-Bus connection may still remain as well. > Thanks, > Yury > > -- Luiz Augusto von Dentz
