net-wireless/bluez-libs-3.11 net-wireless/bluez-utils-3.11-r2 (cups -debug -examples hal -old-daemons -test-programs usb) app-mobilephone/obexftp-0.21 (bluetooth -debug nls perl python -swig -tcl) net-wireless/kdebluetooth-1.0_beta3 (-arts -debug -elibc_FreeBSD -xinerama) sdp scan of other devices does not show any services, palm cannot connect to desktop via pand anymore, desktop doesn't accept files via obex, outgoing ppp via rfcomm is broken too. It seems that the only working thing is l2ping. Reproducible: Always Steps to Reproduce:
please try hcitool scan (for a few times), does it show you your devices? Could you please send us your rfcomm.conf? Have you restarted bluetooth, are no old daemons running anymore (like sdpd)?
hcitool scan works. sdptool too, and after scanning my mobile with it, I've got the recodrs in kdebluetooth browser (however clicking on ObexFTP results in "Unknown error -1344463800"). Here's my rfcomm: rfcomm0 { bind yes; device 00:**:**:**:**:CB; channel 1; comment "Mobile"; } I don't have any old daemons running, and I have already rebooted my pc several times.
okay, that rfcomm.conf looks right, is RFCOMM_ENABLE still enabled in /etc/conf.d/bluetooth? could you try to use obexftp -b 00:12:D1:88:XX:XX -l on your OBEX device? I'm not using the kdebluetooth daemon so it might be all related to kdebluetooth... PAND is replaced by a service, I haven't looked into it yet but it is described here: http://wiki.bluez.org/wiki/Network Try the examples...
RFCOMM_ENABLE=true # obexftp -b 00:**:**:**:**:CB -l Browsing 00:**:**:**:**:CB ... Channel: 5 Connecting...failed: connect Still trying to connect Connecting...failed: connect Still trying to connect ...
same thing |=>obexftp -b -p somefile.txt Scanning ... Using *** proger:/dev/mobile Browsing *** ... Channel: 7 Connecting...failed: connect Still trying to connect Connecting...failed: connect Still trying to connect Connecting...failed: connect Still trying to connect
you can try another bluetooth channel by specifying -B do you have a valid pin / authorization agent running? If it is possible you might want to try the applet from bluez-gnome. you can get some debugging information by sniffing with hcidump
After re-pairing PC with mobile (kbluetooth SIGSEGV'ed in the process) I was able to use obexftp. KDE's obex2:/ is working too. Outgoing rfcomm is magically fixed too. Still I can't transfer anything over obex to PC, dun and pan are not working.
quick update: sdptool browse shows no services on my Palm, and obexftp doesn't work. Still I can transfer files from mobile to palm.
(In reply to comment #8) > quick update: sdptool browse shows no services on my Palm, and obexftp doesn't > work. Still I can transfer files from mobile to palm. > Will commit 3.15 later today, could you please give a status update on if this is still an issue.
Currently running: net-wireless/bluez-libs-3.14 net-wireless/bluez-utils-3.14 net-wireless/kdebluetooth-1.0_beta3 dev-libs/openobex-1.3 obexftp transfers work correctly. I was able to browse my mobile from both KDE obex2:// and console obexftp. Outgoing ppp connection is working. Incoming ppp connection (aka dun) is working also, but I had to start dund by hand (that should be handled buy bluetooth runscript). Incoming file transfers do not work. Outgoing obex push transfers do not work.
Our kdebluetooth version is a couple releases behind so maybe upgrading it helps.
net-wireless/kdebluetooth-1.0_beta6 still lacks required functionality. net-wireless/kdebluetooth-1.0_beta2-r2 (with old obex://) seem to work ok with last bluez-{libs,utils}.
18:01 < dgollub> Betelgeuse: obex push is broken in the kdebleutooth beta releases... we dropped the obex push code which was a mix up of two different obex implenetation/wrappers - it's planned to make use of the obex transfer service... we didn't started yet on the implementation. kio_obex2 is also known to have some issues - again we plan to make use of the obex transfer serivce instead of a own implementation. Will have to wait for upstream to get it working.
*** This bug has been marked as a duplicate of bug 276455 ***
