![](https://seccdn.libravatar.org/avatar/a895f78a81a109471893519443e4d933.jpg?s=120&d=mm&r=g)
https://bugzilla.suse.com/show_bug.cgi?id=1225837 Bug ID: 1225837 Summary: bluetooth obex does not respect the active user sessions and always transfers files only in the first tty active session (first user session on the system to be opened at boot) Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: x86-64 OS: openSUSE Tumbleweed Status: NEW Severity: Normal Priority: P5 - None Component: Network Assignee: screening-team-bugs@suse.de Reporter: stakanov@disroot.org QA Contact: qa-bugs@suse.de Target Milestone: --- Found By: --- Blocker: --- This is a curious thing in deed: open one user A (with BT support) in plasma open another user B (with BT support in plasma. User A is bound to tty2 User B is bound to tty3 (or if you do some error it shifts to tty7 as the new behavior is like this if you use alt+cntrl+Fn to shift to another tty (and forget that it is not yet open). Long story short, go to the second user session. It will connect problem free to the BT phone or whatever you wish to do a file transfer. Start the sending of the file on the e.g. Android phone. It will fail silently. Now shift with alt+cntr+Fn to the first(!) opened user session. Now the transfer if it is still active on the phone will suddenly start, transferring the file to the wrong user session. I also tried the following to avoid this: switch off BT in the first user (A)session, switch to the second user session (B), switch there BT on, try to transfer the file, fails silently, then go back to the first user session. BT will be active as expected and here it will receive immediately the files. Hence this is a focus stealing issue. And when you look at dmesg it complains of anything and lists only: [17822.836978] [ T1445] input: Pan Galactic Gargle Blaster (AVRCP) as /devices/virtual/input/input31 [17862.458018] [ T1445] input: Pan Galactic Gargle Blaster (AVRCP) as /devices/virtual/input/input32 [17910.817347] [ T1445] input: Pan Galactic Gargle Blaster (AVRCP) as /devices/virtual/input/input33 [18020.812264] [ T1445] input: Pan Galactic Gargle Blaster (AVRCP) as /devices/virtual/input/input34 where Pan Galactic Gargle Blaster is the name of the phone (Poco X3 Pro). In journalctl you find the following (very few) lines: giu 03 14:21:00 silversurfer bluetoothd[1445]: src/profile.c:ext_io_disconnected() Unable to get io data for Object Push: getpeername: Transport endpoint is not connected (107) giu 03 14:21:00 silversurfer obexd[2731]: disconnected: Transport got disconnected giu 03 14:21:00 silversurfer obexd[2731]: DISCONNECT(0x1), Success(0x20) giu 03 14:21:00 silversurfer obexd[2731]: DISCONNECT(0x1), <unknown>(0xff) giu 03 14:20:55 silversurfer bluetoothd[1445]: /org/bluez/hci0/dev_8C_D9_D6_3B_1E_4F/fd3: fd(42) ready giu 03 14:20:55 silversurfer systemd-logind[1504]: Watching system buttons on /dev/input/event26 (Pan Galactic Gargle Blaster (AVRCP)) before there is only one line that speaks about a problem: giu 03 14:19:33 silversurfer wireplumber[6733]: org.bluez.GattManager1.RegisterApplication() failed: GDBus.Error:org.bluez.Error.AlreadyExists: Already Exists (end of excerpt from journal). You find this combination of errors for all aborted transfers. What the software does: getting an incoming file from a BT sender, the active session should be the receiver, and NOT the first tty user session that was opened that day. What the software does: aborts transfers to the user session if it is not the first in chronological line of log in (first active tty for GUI). Software involved Bluez, bluetoothd and obex -- You are receiving this mail because: You are on the CC list for the bug.