GNOME Bugzilla – Bug 545229
Copy files from bluetooth device: Error in stream protocol: end of stream"
Last modified: 2015-03-04 15:39:32 UTC
Please describe the problem: Binary package hint: bluez-gnome 1) In bluetooth manager (bluez bluetooth applet 0.25), right-click - browse device. 2) I choose my Windows Mobile 5 smartphone 3) I see my smartphone's shared folder 4) If I try to copy a file bigger than 5k FROM the device TO my Ubuntu Hardy, I get the message: Error in stream protocol: end of stream Small, 1k files are transfered without a problem Steps to reproduce: 1) In bluetooth manager (bluez bluetooth applet 0.25), right-click - browse device. 2) I choose my Windows Mobile 5 smartphone 3) I see my smartphone's shared folder 4) Try to copy a file bigger than 5k FROM the device TO the desktop Actual results: Error message - Error in stream protocol: end of stream Expected results: File copied without a problem Does this happen every time? Yes Other information:
Created attachment 115458 [details] /usr/lib/gvfs/gvfsd -r > output. Log file is the command line information This is the command line information when I perform: /usr/lib/gvfs/gvfsd -r > output And 1) Browse device in Bluetooth applet 2) dowload a file bigger than 5k
Created attachment 115459 [details] /usr/lib/gvfs/gvfsd -r > output This is the output file of the same command when trying to copy a file bigger than 5k
I'd need the output of: /usr/libexec/gvfsd-obexftp 'host=[AA:BB:CC:DD:EE:FF]' actually (replace AA:BB:CC:DD:EE:FF with the Bluetooth address of your phone). This is most likely a problem with obex-data-server, but we should see better debug from that output. Which version of gvfs and obex-data-server as well?
$ /usr/lib/gvfs/gvfsd-obexftp 'host=[00:17:83:01:43:97]' setting 'host' to '[00:17:83:01:43:97]' Added new job source 0x8075808 (GVfsBackendObexftp) Queued new job 0x8077c18 (GVfsJobMount) + do_mount send_reply, failed: 1 Mount failed: Connect failed Obex-data-server version - 0.3.1ubuntu1 gvfs - 0.2.5ubuntu1
Make sure you unmount the original mount you created through the bluetooth applet...
(In reply to comment #5) > Make sure you unmount the original mount you created through the bluetooth > applet... > I'm sorry, how do I do that?
"killall gvfsd-obexftp" or select "unmount" in the share's right-click menu.
Might this be the info you need then? :~$ /usr/lib/gvfs/gvfsd-obexftp 'host=[00:17:83:01:43:97]' setting 'host' to '[00:17:83:01:43:97]' Added new job source 0x8075808 (GVfsBackendObexftp) Queued new job 0x8077c18 (GVfsJobMount) + do_mount do_mount: 00:17:83:01:43:97 mounted send_reply, failed: 0 - do_mount register_mount_callback, mount_reply: 0x807c538, error: (nil)
(In reply to comment #8) > Might this be the info you need then? Yes, but you need to reproduce the problem as well. There should be more output when you browse and then copy that bigger file to the disk.
Sorry for the delay in replying. The relevant output when I try to download a 10kB file is: Queued new job 0x8080db0 (GVfsJobQueryInfo) + do_query_info, filename: /consumos.XLS + _query_file_info_helper, filename: /consumos.XLS - _query_file_info_helper send_reply(0x8080db0), failed=0 () - do_query_info backend_dbus_handler org.gtk.vfs.Mount:QueryInfo Queued new job 0x8080e00 (GVfsJobQueryInfo) + do_query_info, filename: /consumos.XLS + _query_file_info_helper, filename: /consumos.XLS - _query_file_info_helper send_reply(0x8080e00), failed=0 () - do_query_info backend_dbus_handler org.gtk.vfs.Mount:OpenForRead Queued new job 0x8082d38 (GVfsJobOpenForRead) + do_open_for_read, filename: /consumos.XLS + _query_file_info_helper, filename: /consumos.XLS - _query_file_info_helper ** Message: transfer of consumos.XLS to /tmp/gvfsobexftp-tmp-BNSYFU started ** Message: filename: /consumos.XLS (consumos.XLS) copying to /tmp/gvfsobexftp-tmp-BNSYFU (retval 1) - do_open_for_read, filename: /consumos.XLS send_reply(0x8082d38), failed=0 () Added new job source 0x8075e80 (GVfsReadChannel) backend_dbus_handler org.gtk.vfs.Mount:QueryInfo Queued new job 0x8080e50 (GVfsJobQueryInfo) + do_query_info, filename: /consumos.XLS + _query_file_info_helper, filename: /consumos.XLS - _query_file_info_helper send_reply(0x8080e50), failed=0 () - do_query_info Queued new job 0x8082d80 (GVfsJobRead) job_read send reply, 4090 bytes Queued new job 0x8082dc8 (GVfsJobRead) ** Message: ErrorOccurred ** Message: Error name: org.openobex.Error.Failed ** Message: Error message: Operation failed (unexpected response) ** Message: Unhandled error, file a bug
Created attachment 116439 [details] Entire Output Entire output of the following actions: 1) $ /usr/lib/gvfs/gvfsd-obexftp 'host=[00:17:83:01:43:97]' 2) Browse device in bluetooth manager 3) Copy a 10kB file and paste it into my desktop
Created attachment 130009 [details] Whilst browsing a Windows Mobile phone over bluetooth the connection dies I am also seeing this on Fedora 10 browsing to a Windows Mobile phone. kernel 2.6.29-0.148.rc6.fc11.i586 GNOME 2.24.2 Log attached if it helps.
On Ubuntu 9.04 the limit grows to about 50k: a 100k file cannot be transferred. Although smaller files can be transferred, the problem persists.
Same thing here. I'm using a HTC mobile with WindowsMobile on it. The funny thing is that it's possible to send huge files from the desktop to the phone. The error only occurs when sending big files from the phone to the desktop, in the "browse device" option.
Obexftp backend has been obsoleted in GNOME 3.10, because it is incompatible with Bluez 5, however limited bluetooth support is currently built-in in GNOME desktop.