* obexd OPP pull problem @ 2010-04-26 23:12 Daniel Abraham 2010-04-27 7:20 ` Luiz Augusto von Dentz 0 siblings, 1 reply; 6+ messages in thread From: Daniel Abraham @ 2010-04-26 23:12 UTC (permalink / raw) To: linux-bluetooth [-- Attachment #1: Type: text/plain, Size: 1342 bytes --] I'm trying to write a Python script that pulls a business card via OPP (almost the same as the obexd test script "pull-business-card", except it also handles pairing). My problem is that when I call the method "PullBusinessCard", it returns almost immediately, withtout a D-Bus exception (i.e. should be successful), but no output file can be found. Here's what I see in /var/log/messages: Apr 27 01:20:54 dabraham-mobl bluetoothd[1529]: link_key_request (sba=00:21:86:7A:E7:67, dba=00:1C:26:FC:15:AF) Apr 27 01:20:54 dabraham-mobl obex-client[3067]: Transfer(0xd4cb40) Error: Method not allowed Apr 27 01:20:58 dabraham-mobl kernel: btusb_intr_complete: hci0 urb ffff880045f54d80 failed to resubmit (1) Apr 27 01:20:58 dabraham-mobl kernel: btusb_bulk_complete: hci0 urb ffff880045f54cc0 failed to resubmit (1) Apr 27 01:20:58 dabraham-mobl kernel: btusb_bulk_complete: hci0 urb ffff880045f54540 failed to resubmit (1) Both computers list the other side as visible & paired, both have OPP enabled, other types/directions of OBEX traffic work well, so I'm baffled... By the way, I'm using obexd 0.23, bluez 4.63, and the other side is an recent IVT stack (with a configured default vCard of course). Also attaching hcidump file. Any ideas? Also, a second question: is there any way to define in BlueZ a default vCard to serve? Thanks [-- Attachment #2: opp-pull.hcidump --] [-- Type: application/octet-stream, Size: 5537 bytes --] ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: obexd OPP pull problem 2010-04-26 23:12 obexd OPP pull problem Daniel Abraham @ 2010-04-27 7:20 ` Luiz Augusto von Dentz 2010-04-27 8:33 ` Luiz Augusto von Dentz 0 siblings, 1 reply; 6+ messages in thread From: Luiz Augusto von Dentz @ 2010-04-27 7:20 UTC (permalink / raw) To: Daniel Abraham; +Cc: linux-bluetooth Hi, On Tue, Apr 27, 2010 at 2:12 AM, Daniel Abraham <daniel.shrugged@gmail.com> wrote: > I'm trying to write a Python script that pulls a business card via OPP > (almost the same as the obexd test script "pull-business-card", except > it also handles pairing). > > My problem is that when I call the method "PullBusinessCard", it > returns almost immediately, withtout a D-Bus exception (i.e. should be > successful), but no output file can be found. > > Here's what I see in /var/log/messages: > > Apr 27 01:20:54 dabraham-mobl bluetoothd[1529]: link_key_request > (sba=00:21:86:7A:E7:67, dba=00:1C:26:FC:15:AF) > Apr 27 01:20:54 dabraham-mobl obex-client[3067]: Transfer(0xd4cb40) > Error: Method not allowed It should return a D-Bus error due to transfer error, which is why it doesn't complete the transfer, so it might be a bug in vcard pull logic, but why the transfer is failing I don't know it shouldn't matter if you are paring or not. -- Luiz Augusto von Dentz Computer Engineer ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: obexd OPP pull problem 2010-04-27 7:20 ` Luiz Augusto von Dentz @ 2010-04-27 8:33 ` Luiz Augusto von Dentz 2010-04-27 11:51 ` Daniel Abraham 0 siblings, 1 reply; 6+ messages in thread From: Luiz Augusto von Dentz @ 2010-04-27 8:33 UTC (permalink / raw) To: Daniel Abraham; +Cc: linux-bluetooth Hi, On Tue, Apr 27, 2010 at 10:20 AM, Luiz Augusto von Dentz <luiz.dentz@gmail.com> wrote: > Hi, > > On Tue, Apr 27, 2010 at 2:12 AM, Daniel Abraham > <daniel.shrugged@gmail.com> wrote: >> I'm trying to write a Python script that pulls a business card via OPP >> (almost the same as the obexd test script "pull-business-card", except >> it also handles pairing). >> >> My problem is that when I call the method "PullBusinessCard", it >> returns almost immediately, withtout a D-Bus exception (i.e. should be >> successful), but no output file can be found. >> >> Here's what I see in /var/log/messages: >> >> Apr 27 01:20:54 dabraham-mobl bluetoothd[1529]: link_key_request >> (sba=00:21:86:7A:E7:67, dba=00:1C:26:FC:15:AF) >> Apr 27 01:20:54 dabraham-mobl obex-client[3067]: Transfer(0xd4cb40) >> Error: Method not allowed > > It should return a D-Bus error due to transfer error, which is why it > doesn't complete the transfer, so it might be a bug in vcard pull > logic, but why the transfer is failing I don't know it shouldn't > matter if you are paring or not. This should fix at least the D-Bus error: http://gitorious.org/obexd/vudentzs-clone/commit/32e48446b6b8cd72e15988c673a60c7fb47b0862 -- Luiz Augusto von Dentz Computer Engineer ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: obexd OPP pull problem 2010-04-27 8:33 ` Luiz Augusto von Dentz @ 2010-04-27 11:51 ` Daniel Abraham 2010-05-12 21:21 ` Daniel Abraham 0 siblings, 1 reply; 6+ messages in thread From: Daniel Abraham @ 2010-04-27 11:51 UTC (permalink / raw) To: Luiz Augusto von Dentz; +Cc: linux-bluetooth On Tue, Apr 27, 2010 at 11:33 AM, Luiz Augusto von Dentz <luiz.dentz@gmail.com> wrote: > > This should fix at least the D-Bus error: > > http://gitorious.org/obexd/vudentzs-clone/commit/32e48446b6b8cd72e15988c673a60c7fb47b0862 Actually, that's not what I see. I'm using the "pull-business-card" script (which doesn't use any try-except block), and it doesn't crash with an exception, even though "dbus-monitor --session" shows the error (below). Is it lost somehow before it reaches Python's D-Bus caller object? method call sender=:1.147 -> dest=:1.142 serial=4 path=/; interface=org.openobex.Client; member=PullBusinessCard array [ dict entry( string "Destination" variant string "00:1C:26:FC:15:AF" ) ] string "d.vcf" method call sender=:1.142 -> dest=org.freedesktop.DBus serial=18 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=AddMatch string "type='signal',interface='org.freedesktop.DBus',member='NameOwnerChanged',arg0=':1.147'" method return sender=:1.142 -> dest=:1.147 reply_serial=4 error sender=:1.142 -> dest=:1.147 error_name=org.openobex.Error.Failed reply_serial=4 string "Method not allowed" method call sender=:1.142 -> dest=org.freedesktop.DBus serial=21 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=RemoveMatch string "type='signal',interface='org.freedesktop.DBus',member='NameOwnerChanged',arg0=':1.147'" signal sender=org.freedesktop.DBus -> dest=(null destination) serial=10 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=NameOwnerChanged string ":1.147" string ":1.147" string "" ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: obexd OPP pull problem 2010-04-27 11:51 ` Daniel Abraham @ 2010-05-12 21:21 ` Daniel Abraham 2010-05-13 1:00 ` Vinicius Gomes 0 siblings, 1 reply; 6+ messages in thread From: Daniel Abraham @ 2010-05-12 21:21 UTC (permalink / raw) To: Luiz Augusto von Dentz; +Cc: linux-bluetooth [-- Attachment #1: Type: text/plain, Size: 3003 bytes --] On Tue, Apr 27, 2010 at 2:51 PM, Daniel Abraham <daniel.shrugged@gmail.com> wrote: > On Tue, Apr 27, 2010 at 11:33 AM, Luiz Augusto von Dentz > <luiz.dentz@gmail.com> wrote: >> >> This should fix at least the D-Bus error: >> >> http://gitorious.org/obexd/vudentzs-clone/commit/32e48446b6b8cd72e15988c673a60c7fb47b0862 > > Actually, that's not what I see. I'm using the "pull-business-card" > script (which doesn't use any try-except block), and it doesn't crash > with an exception, even though "dbus-monitor --session" shows the > error (below). Is it lost somehow before it reaches Python's D-Bus > caller object? > > method call sender=:1.147 -> dest=:1.142 serial=4 path=/; > interface=org.openobex.Client; member=PullBusinessCard > array [ > dict entry( > string "Destination" > variant string "00:1C:26:FC:15:AF" > ) > ] > string "d.vcf" > method call sender=:1.142 -> dest=org.freedesktop.DBus serial=18 > path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; > member=AddMatch > string "type='signal',interface='org.freedesktop.DBus',member='NameOwnerChanged',arg0=':1.147'" > method return sender=:1.142 -> dest=:1.147 reply_serial=4 > error sender=:1.142 -> dest=:1.147 > error_name=org.openobex.Error.Failed reply_serial=4 > string "Method not allowed" > method call sender=:1.142 -> dest=org.freedesktop.DBus serial=21 > path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; > member=RemoveMatch > string "type='signal',interface='org.freedesktop.DBus',member='NameOwnerChanged',arg0=':1.147'" > signal sender=org.freedesktop.DBus -> dest=(null destination) > serial=10 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; > member=NameOwnerChanged > string ":1.147" > string ":1.147" > string "" I revisited the issue above, and a problem still reproduces, sorta... I use the following setup: Fedora 12, BlueZ 4.64, obexd 0.23 on both sides. And after a while "PullBusinessCard" started to work, i.e. I pull the default vcard (of 50 bytes) from 1 side to the other. But... Even though the HCI dump shows that the text passed through, the vCard file isn't found anywhere. Also, it looks as if there's some timing issue: 1. If I pull a 50-byte card, the remote computer recognize successful completion event 2. If I pull a 20-KB card, the remote computer doesn't recognize any completion event Either way, the local computer claims to be successful, even though there's no saved vcard file. Another thing I noticed is that the remote host from which I try to pull the vcard (also BlueZ 4.64 + obexd 0.23) writes this in "/var/log/messages": obexd[...] New connection from: <BD address>, channel <...> (and immediately, with the same timestamp:) obexd[...] obexd_handle_input: poll event HUP ERR I'm also attaching 2 hcidumps (saved on the local computer trying to do the pulling). Any idea how to work around these failures? Thanks [-- Attachment #2: opp-pull-fail.hcidump --] [-- Type: application/octet-stream, Size: 6616 bytes --] [-- Attachment #3: opp-pull-success.hcidump --] [-- Type: application/octet-stream, Size: 2533 bytes --] ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: obexd OPP pull problem 2010-05-12 21:21 ` Daniel Abraham @ 2010-05-13 1:00 ` Vinicius Gomes 0 siblings, 0 replies; 6+ messages in thread From: Vinicius Gomes @ 2010-05-13 1:00 UTC (permalink / raw) To: Daniel Abraham; +Cc: Luiz Augusto von Dentz, linux-bluetooth Hi Daniel, First, thanks for the interesting bug report. On Wed, May 12, 2010 at 6:21 PM, Daniel Abraham <daniel.shrugged@gmail.com> wrote: > On Tue, Apr 27, 2010 at 2:51 PM, Daniel Abraham > <daniel.shrugged@gmail.com> wrote: >> On Tue, Apr 27, 2010 at 11:33 AM, Luiz Augusto von Dentz >> <luiz.dentz@gmail.com> wrote: >>> >>> This should fix at least the D-Bus error: >>> >>> http://gitorious.org/obexd/vudentzs-clone/commit/32e48446b6b8cd72e15988c673a60c7fb47b0862 >> >> Actually, that's not what I see. I'm using the "pull-business-card" >> script (which doesn't use any try-except block), and it doesn't crash >> with an exception, even though "dbus-monitor --session" shows the >> error (below). Is it lost somehow before it reaches Python's D-Bus >> caller object? >> >> method call sender=:1.147 -> dest=:1.142 serial=4 path=/; >> interface=org.openobex.Client; member=PullBusinessCard >> array [ >> dict entry( >> string "Destination" >> variant string "00:1C:26:FC:15:AF" >> ) >> ] >> string "d.vcf" >> method call sender=:1.142 -> dest=org.freedesktop.DBus serial=18 >> path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; >> member=AddMatch >> string "type='signal',interface='org.freedesktop.DBus',member='NameOwnerChanged',arg0=':1.147'" >> method return sender=:1.142 -> dest=:1.147 reply_serial=4 >> error sender=:1.142 -> dest=:1.147 >> error_name=org.openobex.Error.Failed reply_serial=4 >> string "Method not allowed" >> method call sender=:1.142 -> dest=org.freedesktop.DBus serial=21 >> path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; >> member=RemoveMatch >> string "type='signal',interface='org.freedesktop.DBus',member='NameOwnerChanged',arg0=':1.147'" >> signal sender=org.freedesktop.DBus -> dest=(null destination) >> serial=10 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; >> member=NameOwnerChanged >> string ":1.147" >> string ":1.147" >> string "" > > I revisited the issue above, and a problem still reproduces, sorta... > > I use the following setup: Fedora 12, BlueZ 4.64, obexd 0.23 on both sides. > And after a while "PullBusinessCard" started to work, i.e. I pull the > default vcard (of 50 bytes) from 1 side to the other. > > But... Even though the HCI dump shows that the text passed through, > the vCard file isn't found anywhere. > > Also, it looks as if there's some timing issue: > 1. If I pull a 50-byte card, the remote computer recognize successful > completion event > 2. If I pull a 20-KB card, the remote computer doesn't recognize any > completion event > > Either way, the local computer claims to be successful, even though > there's no saved vcard file. > > Another thing I noticed is that the remote host from which I try to > pull the vcard (also BlueZ 4.64 + obexd 0.23) writes this in > "/var/log/messages": > > obexd[...] New connection from: <BD address>, channel <...> > (and immediately, with the same timestamp:) > obexd[...] obexd_handle_input: poll event HUP ERR > > I'm also attaching 2 hcidumps (saved on the local computer trying to > do the pulling). > > Any idea how to work around these failures? I requested a proposed fix to be merged upstream, it is here[1] on the for-upstream branch. I also set up a 0.23-patched branch that has those fixes on top of the 0.23 tag, if it makes your life any easier. But this last option is not even compile tested ;-) > > Thanks > Cheers, -- Vinicius [1] http://git.infradead.org/users/vcgomes/obexd.git ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2010-05-13 1:00 UTC | newest] Thread overview: 6+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2010-04-26 23:12 obexd OPP pull problem Daniel Abraham 2010-04-27 7:20 ` Luiz Augusto von Dentz 2010-04-27 8:33 ` Luiz Augusto von Dentz 2010-04-27 11:51 ` Daniel Abraham 2010-05-12 21:21 ` Daniel Abraham 2010-05-13 1:00 ` Vinicius Gomes
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).