Hello Luiz!
I noticed a problem in obexd and/or Bluez 5.21 (Debian Testing):
- PullAll from Samsung Galaxy S3
- Suspend
- kill the process who called obexd
- try to pull again from a different process
=> GDBus.Error:org.bluez.obex.Error.Failed: Unable to find service
record
obexd notices that its client died (there is a InterfacesRemoved signal
for the transfer and session path), but the cleanup seems to leave the
device or the local side in an unusable state.
Killing obexd and restarting it makes it possible to access the phone
again.
I've not been able to reproduce this without suspending first.
--
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.
Hi Patrick, Luiz
On Tue, Aug 26, 2014 at 2:39 PM, Patrick Ohly <[email protected]> wrote:
> I noticed a problem in obexd and/or Bluez 5.21 (Debian Testing):
>
> - PullAll from Samsung Galaxy S3
> - Suspend
> - kill the process who called obexd
> - try to pull again from a different process
> => GDBus.Error:org.bluez.obex.Error.Failed: Unable to find service
> record
I also was able to reproduce the issue with Bluez 5.21 and Motorola
RAZRi/HTC Desire Z using steps described by Patrick.
> obexd notices that its client died (there is a InterfacesRemoved signal
> for the transfer and session path), but the cleanup seems to leave the
> device or the local side in an unusable state.
What I noticed is that after killing client process, phone still seems
to see active session - Bluetooth icon on the phone is still blue (it
turns blue when there is an active session), so that may indicate that
phone is left in unusable state.
> Killing obexd and restarting it makes it possible to access the phone
> again.
For me also switching phone Bluetooth off and on makes it possible to
create new session form different process, without need to restart
obexd.
Regards,
Mateusz Półrola
On Tue, 2014-08-26 at 16:52 +0300, Von Dentz, Luiz wrote:
> Hi Patrick,
>
> On Tue, Aug 26, 2014 at 4:39 PM, Patrick Ohly <[email protected]> wrote:
> > Hello Luiz!
> >
> > I noticed a problem in obexd and/or Bluez 5.21 (Debian Testing):
> >
> > - PullAll from Samsung Galaxy S3
> > - Suspend
> > - kill the process who called obexd
> > - try to pull again from a different process
> > => GDBus.Error:org.bluez.obex.Error.Failed: Unable to find service
> > record
> >
> > obexd notices that its client died (there is a InterfacesRemoved signal
> > for the transfer and session path), but the cleanup seems to leave the
> > device or the local side in an unusable state.
> >
> > Killing obexd and restarting it makes it possible to access the phone
> > again.
> >
> > I've not been able to reproduce this without suspending first.
>
> It might be related to the patch Ive just sent, there is a bug where
> Transfer.Cancel would not work in case it is suspended.
Beware that Transfer.Cancel was not involved in the steps above. The
client which might have canceled the transfer just got killed instead.
Perhaps it leads to the same code path, so this might still be the same
issue.
--
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.
Hi Patrick,
On Tue, Aug 26, 2014 at 4:39 PM, Patrick Ohly <[email protected]> wrote:
> Hello Luiz!
>
> I noticed a problem in obexd and/or Bluez 5.21 (Debian Testing):
>
> - PullAll from Samsung Galaxy S3
> - Suspend
> - kill the process who called obexd
> - try to pull again from a different process
> => GDBus.Error:org.bluez.obex.Error.Failed: Unable to find service
> record
>
> obexd notices that its client died (there is a InterfacesRemoved signal
> for the transfer and session path), but the cleanup seems to leave the
> device or the local side in an unusable state.
>
> Killing obexd and restarting it makes it possible to access the phone
> again.
>
> I've not been able to reproduce this without suspending first.
It might be related to the patch Ive just sent, there is a bug where
Transfer.Cancel would not work in case it is suspended.