Il 17/03/23 19:27, Stakanov ha scritto:
In data venerdì 17 marzo 2023 23:10:59 CET, Marco Calistri ha scritto:
Il 17/03/23 13:35, Stakanov ha scritto:
11.27.40 ERROR Manager:223 error_handler: Authenti> mar 17 11:27:40 linux-turion64 blueman-sendto[13581]: blueman-sendto 11.27.40 ERROR Client:26 on_session_failed: D8:9A:34:> mar 17 11:27:40 linux-turion64 obexd[2888]: Unable to find service record this seems to be an error of authentication? Try to set you external (receiving) device to accept your incoming files without authorization. Does this work then? There is not such option here, my device is a Lenovo Zuk Z2 plus smartphone. I don't know if this setting is available/permitted, I never check it or being aware of this possibility.
If it is character based: I had a look at the thread in the link and on others, they had a problem with libiconv not being present others with the character encoding. Libiconv does not seem to exist for opensuse. iconv itself is meant for character conversion (where AFAIU, libiconv is based on it). I ignore which library for your desktop environment should do this function under opensuse. Do the filename have special characters like "è, é, à" etc.? No, in my file-transfer attempt, the filename was not containing special characters
Question: when you did pair the device, which direction did you take? Did you request pairing from the external device or from the pc to the device originally. I had cases were one of the two direction of pairing caused troubles with authentication although the devices appeared paired, the other paring direction instead worked. I would therefore also suggest (besides the authorization issue) to unpair and to try then the pairing in the opposite direction of what you originally did, and to see whether this changes things. I sincerely don't remember this particular, but I can try to delete the remote device and try pairing it again. Actually the not working direction is from computer to the remote device.
Anyway I remember that Bluetooth did worked in the past, may be that the subsequent updates both in BT stack and/or kernel, did broke the functionality.
Regards, Oh, I do not doubt that before it worked. BT had a lot of changes and some of them came as a blessing, some others not. To be precise: BT did work with you with THIS specific device? Or was it with a different device? Does your device supports OBEX? I found out today that apparently iOS does not support OBEX file transfers.
I am not really aware what phone or device that is, but if you go in the settings you can generally determine that incoming BT transactions are a) requiring a paired device and user interaction (authorization) b) not requiring a user authorization in case the device is known and trusted. c) accept all incoming BT transfers (which is unsafe, but would allow to exclude the authorization procedure as a source for your problem.
The sequence of pairing (first phone or first PC) was a problem with some specific devices. This seems to be also a question of BT used in the paired device.
The file-transfer now works! The main issues were: 1 - I had disabled the desktop notification on XFCE, then I was "blind" regarding auth request from the PC. 2 - The file you wish to transfer must have an extension: PNG, XLSX, TXT... otherwise the BT sends the error. I.E. "authy" file not transferred, "authy.txt" file transferred correctly! At the end the issue was caused by my improper usage of the Bluetooth and not by a system or kernel issue. Sorry for the noise raised so far! Best regards! -- Marco Calistri Build: openSUSE Tumbleweed 20230316 Kernel: 6.2.4-1-default - XFCE: (4.18.1)