* Bluetooth printer connection error @ 2020-12-08 21:25 Laurent Vivier 2020-12-09 11:00 ` Bastien Nocera 0 siblings, 1 reply; 9+ messages in thread From: Laurent Vivier @ 2020-12-08 21:25 UTC (permalink / raw) To: linux-bluetooth Hi, TL;DR: I can pair my bluetooth printer but it fails to connect: $ bluetoothctl connect DC:0D:30:90:23:C7 Attempting to connect to DC:0D:30:90:23:C7 [CHG] Device DC:0D:30:90:23:C7 Connected: yes [CHG] Device DC:0D:30:90:23:C7 ServicesResolved: yes Failed to connect: org.bluez.Error.NotAvailable What do I need to add to my system to have this working? ---------------------------------------------------------------------- The full story: I cannot connect my bluetooth printer using "bluetoothctl connect" (I'm testing with git commitid b446ed8e8). 1. Start the bluetooth printer 2. bluetoothctl devices Device DC:0D:30:90:23:C7 Mr.in_M02 ... 3. bluetoothctl info DC:0D:30:90:23:C7 Device DC:0D:30:90:23:C7 (public) Name: Mr.in_M02 Alias: Mr.in_M02 Class: 0x00040680 Icon: printer Paired: no Trusted: no Blocked: no Connected: no LegacyPairing: yes RSSI: -81 4. bluetoothctl pair DC:0D:30:90:23:C7 Attempting to pair with DC:0D:30:90:23:C7 [CHG] Device DC:0D:30:90:23:C7 Connected: yes [CHG] Device DC:0D:30:90:23:C7 UUIDs: 00001101-0000-1000-8000-00805f9b34fb [CHG] Device DC:0D:30:90:23:C7 ServicesResolved: yes [CHG] Device DC:0D:30:90:23:C7 Paired: yes Pairing successful 5. bluetoothctl info DC:0D:30:90:23:C7 Device DC:0D:30:90:23:C7 (public) Name: Mr.in_M02 Alias: Mr.in_M02 Class: 0x00040680 Icon: printer Paired: yes Trusted: no Blocked: no Connected: no LegacyPairing: yes UUID: Serial Port (00001101-0000-1000-8000-00805f9b34fb) 6. bluetoothctl paired-devices Device DC:0D:30:90:23:C7 Mr.in_M02 7. bluetoothctl connect DC:0D:30:90:23:C7 Attempting to connect to DC:0D:30:90:23:C7 [CHG] Device DC:0D:30:90:23:C7 Connected: yes [CHG] Device DC:0D:30:90:23:C7 ServicesResolved: yes Failed to connect: org.bluez.Error.NotAvailable If I use hcitool/rfcomm I can send data to the printer. It works fine in this case. $ hcitool scan Scanning ... DC:0D:30:90:23:C7 Mr.in_M02 $ sdptool browse DC:0D:30:90:23:C7 Browsing DC:0D:30:90:23:C7 ... $ sdptool records DC:0D:30:90:23:C7 Service Name: SPP Dev Service RecHandle: 0x10001 Service Class ID List: "Serial Port" (0x1101) Protocol Descriptor List: "L2CAP" (0x0100) "RFCOMM" (0x0003) Channel: 1 Language Base Attr List: code_ISO639: 0x656e encoding: 0x6a base_offset: 0x100 ^C [the command hangs here] $ sudo rfcomm connect 0 DC:0D:30:90:23:C7 Connected /dev/rfcomm0 to DC:0D:30:90:23:C7 on channel 1 Press CTRL-C for hangup Thanks, Lauren ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Bluetooth printer connection error 2020-12-08 21:25 Bluetooth printer connection error Laurent Vivier @ 2020-12-09 11:00 ` Bastien Nocera 2020-12-09 11:14 ` Laurent Vivier 0 siblings, 1 reply; 9+ messages in thread From: Bastien Nocera @ 2020-12-09 11:00 UTC (permalink / raw) To: Laurent Vivier, linux-bluetooth On Tue, 2020-12-08 at 22:25 +0100, Laurent Vivier wrote: > Hi, > > TL;DR: > > I can pair my bluetooth printer but it fails to connect: > > $ bluetoothctl connect DC:0D:30:90:23:C7 > > Attempting to connect to DC:0D:30:90:23:C7 > [CHG] Device DC:0D:30:90:23:C7 Connected: yes > [CHG] Device DC:0D:30:90:23:C7 ServicesResolved: yes > Failed to connect: org.bluez.Error.NotAvailable > > What do I need to add to my system to have this working? As I mentioned in the original bug: https://bugzilla.redhat.com/show_bug.cgi?id=1904686 I don't expect the "connect" command to do anything. There's nothing to "connect" to, as bluez doesn't create rfcomm device nodes automatically when "connecting" to devices with serial profiles (otherwise one couldn't connect to them with other applications without going through the device node...). If the printer has uses the SPP or HCRP printing profiles, you should see it when using: /usr/lib/cups/backend/bluetooth without any arguments. Otherwise any apps or driver that supports the printer should be able to create a serial link directly to the device without creating a device node in /dev. FWIW, looks like the printer uses a proprietary protocol between their own app and the printer, and that they don't provide Linux support. Short of reverse engineering that protocol, the printer is unlikely to work with Linux. Cheers ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Bluetooth printer connection error 2020-12-09 11:00 ` Bastien Nocera @ 2020-12-09 11:14 ` Laurent Vivier 2020-12-09 11:34 ` Bastien Nocera 0 siblings, 1 reply; 9+ messages in thread From: Laurent Vivier @ 2020-12-09 11:14 UTC (permalink / raw) To: Bastien Nocera, linux-bluetooth Le 09/12/2020 à 12:00, Bastien Nocera a écrit : > On Tue, 2020-12-08 at 22:25 +0100, Laurent Vivier wrote: >> Hi, >> >> TL;DR: >> >> I can pair my bluetooth printer but it fails to connect: >> >> $ bluetoothctl connect DC:0D:30:90:23:C7 >> >> Attempting to connect to DC:0D:30:90:23:C7 >> [CHG] Device DC:0D:30:90:23:C7 Connected: yes >> [CHG] Device DC:0D:30:90:23:C7 ServicesResolved: yes >> Failed to connect: org.bluez.Error.NotAvailable >> >> What do I need to add to my system to have this working? > > As I mentioned in the original bug: > https://bugzilla.redhat.com/show_bug.cgi?id=1904686 > > I don't expect the "connect" command to do anything. There's nothing to > "connect" to, as bluez doesn't create rfcomm device nodes automatically > when "connecting" to devices with serial profiles (otherwise one > couldn't connect to them with other applications without going through > the device node...). Yes, I didn't understand what you meant... My question is: what piece of code I need to write or modify to have the "connect" operation working? > If the printer has uses the SPP or HCRP printing profiles, you should > see it when using: > /usr/lib/cups/backend/bluetooth > without any arguments. As I don't see it once it is paired, I guess it is not using one of these profiles. > Otherwise any apps or driver that supports the printer should be able > to create a serial link directly to the device without creating a > device node in /dev. > > FWIW, looks like the printer uses a proprietary protocol between their > own app and the printer, and that they don't provide Linux support. > Short of reverse engineering that protocol, the printer is unlikely to > work with Linux. I've written the CUPS driver that works fine with the rfcomm device. In fact, it's not proprietary, it's ESC/POS protocol. https://github.com/vivier/phomemo-tools I'm working on my code to use python-escpos rather than my hack and I'd like to integrate smoothly the printer in the bluetooth stack. It works also with USB, but it's a shame not to use bluetooth with a printer that has an internal battery. Thanks, Laurent ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Bluetooth printer connection error 2020-12-09 11:14 ` Laurent Vivier @ 2020-12-09 11:34 ` Bastien Nocera 2020-12-09 19:04 ` Laurent Vivier 0 siblings, 1 reply; 9+ messages in thread From: Bastien Nocera @ 2020-12-09 11:34 UTC (permalink / raw) To: Laurent Vivier, linux-bluetooth On Wed, 2020-12-09 at 12:14 +0100, Laurent Vivier wrote: > Le 09/12/2020 à 12:00, Bastien Nocera a écrit : > > On Tue, 2020-12-08 at 22:25 +0100, Laurent Vivier wrote: > > > Hi, > > > > > > TL;DR: > > > > > > I can pair my bluetooth printer but it fails to connect: > > > > > > $ bluetoothctl connect DC:0D:30:90:23:C7 > > > > > > Attempting to connect to DC:0D:30:90:23:C7 > > > [CHG] Device DC:0D:30:90:23:C7 Connected: yes > > > [CHG] Device DC:0D:30:90:23:C7 ServicesResolved: yes > > > Failed to connect: org.bluez.Error.NotAvailable > > > > > > What do I need to add to my system to have this working? > > > > As I mentioned in the original bug: > > https://bugzilla.redhat.com/show_bug.cgi?id=1904686 > > > > I don't expect the "connect" command to do anything. There's > > nothing to > > "connect" to, as bluez doesn't create rfcomm device nodes > > automatically > > when "connecting" to devices with serial profiles (otherwise one > > couldn't connect to them with other applications without going > > through > > the device node...). > > Yes, I didn't understand what you meant... > > My question is: what piece of code I need to write or modify to have > the > "connect" operation working? Again, it's bluez' prerogative that serial profiles don't automatically get a serial device node attached. Either you need to create the rfcomm device node manually, or you need to jump through the same hoops many apps do, using SDP to find the RFCOMM port on the remote device, and connecting to that port using an AF_BLUETOOTH socket. The cups backend in the bluez sources does both of those things. > > > If the printer has uses the SPP or HCRP printing profiles, you > > should > > see it when using: > > /usr/lib/cups/backend/bluetooth > > without any arguments. > > As I don't see it once it is paired, I guess it is not using one of > these profiles. I don't remember how this used to work, but you'll probably only see something if the printer is visible. You might be able to get the printer to work by adding: bluetooth://DC0D309023C7 as a printer in the printer settings of your favourite desktop environment, if it actually uses SPP. running the cups backend with: /usr/lib/cups/backend/bluetooth --get-deviceid bluetooth://DC0D309023C7 should show you whether it can get autoconfigured for CUPS use. > > > Otherwise any apps or driver that supports the printer should be > > able > > to create a serial link directly to the device without creating a > > device node in /dev. > > > > FWIW, looks like the printer uses a proprietary protocol between > > their > > own app and the printer, and that they don't provide Linux support. > > Short of reverse engineering that protocol, the printer is unlikely > > to > > work with Linux. > > I've written the CUPS driver that works fine with the rfcomm device. > In fact, it's not proprietary, it's ESC/POS protocol. > > https://github.com/vivier/phomemo-tools > > I'm working on my code to use python-escpos rather than my hack and > I'd > like to integrate smoothly the printer in the bluetooth stack. > > It works also with USB, but it's a shame not to use bluetooth with a > printer that has an internal battery. ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Bluetooth printer connection error 2020-12-09 11:34 ` Bastien Nocera @ 2020-12-09 19:04 ` Laurent Vivier 2020-12-09 20:27 ` Bastien Nocera 0 siblings, 1 reply; 9+ messages in thread From: Laurent Vivier @ 2020-12-09 19:04 UTC (permalink / raw) To: Bastien Nocera, linux-bluetooth Le 09/12/2020 à 12:34, Bastien Nocera a écrit : > On Wed, 2020-12-09 at 12:14 +0100, Laurent Vivier wrote: ... >>> If the printer has uses the SPP or HCRP printing profiles, you >>> should >>> see it when using: >>> /usr/lib/cups/backend/bluetooth >>> without any arguments. >> >> As I don't see it once it is paired, I guess it is not using one of >> these profiles. > > I don't remember how this used to work, but you'll probably only see > something if the printer is visible. > > You might be able to get the printer to work by adding: > bluetooth://DC0D309023C7 > as a printer in the printer settings of your favourite desktop > environment, if it actually uses SPP. > > running the cups backend with: > /usr/lib/cups/backend/bluetooth --get-deviceid bluetooth://DC0D309023C7 > > should show you whether it can get autoconfigured for CUPS use. > Thank you Bastien, it's exactly what I needed to know. Correct me if I'm wrong but it seems there is a bug in the cups/bluetooth command: profiles/cups/main.c 602 static gboolean print_ieee1284(const char *bdaddr) ... 616 message = dbus_message_new_method_call("org.bluez", "/", 617 "org.bluez.Manager", 618 "DefaultAdapter"); 619 620 adapter_reply = dbus_connection_send_with_reply_and_block(conn, 621 message, -1, NULL); adapter_reply is always NULL. I can see following errors with dbus-monitor: method call time=1607536119.751900 sender=:1.194 -> destination=org.bluez serial=2 path=/; interface=org.bluez.Manager; member=DefaultAdapter error time=1607536119.752107 sender=:1.71 -> destination=:1.194 error_name=org.freedesktop.DBus.Error.UnknownMethod reply_serial=2 string "Method "DefaultAdapter" with signature "" on interface "org.bluez.Manager" doesn't exist " And I can find a commit removing calls to org.bluez.Manager: commit 86a7b07c22f3a595ba3c48092359287905bf0878 Author: Mikel Astiz <mikel.astiz@bmw-carit.de> Date: Wed Dec 5 13:51:34 2012 +0100 dbus: Remove org.bluez.Manager After the decision to drop the "default-adapter" feature in the D-Bus API, the org.bluez.Manager interface can be entirely dropped since it has been replaced by the ObjectManager. What did I miss? Thanks, Laurent ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Bluetooth printer connection error 2020-12-09 19:04 ` Laurent Vivier @ 2020-12-09 20:27 ` Bastien Nocera 2020-12-09 21:45 ` Laurent Vivier 0 siblings, 1 reply; 9+ messages in thread From: Bastien Nocera @ 2020-12-09 20:27 UTC (permalink / raw) To: Laurent Vivier, linux-bluetooth On Wed, 2020-12-09 at 20:04 +0100, Laurent Vivier wrote: > Le 09/12/2020 à 12:34, Bastien Nocera a écrit : > > On Wed, 2020-12-09 at 12:14 +0100, Laurent Vivier wrote: > ... > > > > If the printer has uses the SPP or HCRP printing profiles, you > > > > should > > > > see it when using: > > > > /usr/lib/cups/backend/bluetooth > > > > without any arguments. > > > > > > As I don't see it once it is paired, I guess it is not using one > > > of > > > these profiles. > > > > I don't remember how this used to work, but you'll probably only > > see > > something if the printer is visible. > > > > You might be able to get the printer to work by adding: > > bluetooth://DC0D309023C7 > > as a printer in the printer settings of your favourite desktop > > environment, if it actually uses SPP. > > > > running the cups backend with: > > /usr/lib/cups/backend/bluetooth --get-deviceid > > bluetooth://DC0D309023C7 > > > > should show you whether it can get autoconfigured for CUPS use. > > > > Thank you Bastien, it's exactly what I needed to know. > > Correct me if I'm wrong but it seems there is a bug in the > cups/bluetooth > command: Sigh. No, it's not a bug, it's just that the cups tool was never ported from the bluez 4.x to the current bluez 5.x API... Until that's ported (if ever, given the low number of Bluetooth printers around...), you could try to extract the IEEE1284 ID using: sdptool records DC:0D:30:90:23:C7 But I'm not certain that this working is necessary to actually try a print. Have you tested that? ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Bluetooth printer connection error 2020-12-09 20:27 ` Bastien Nocera @ 2020-12-09 21:45 ` Laurent Vivier 2020-12-10 9:35 ` Bastien Nocera 0 siblings, 1 reply; 9+ messages in thread From: Laurent Vivier @ 2020-12-09 21:45 UTC (permalink / raw) To: Bastien Nocera, linux-bluetooth Le 09/12/2020 à 21:27, Bastien Nocera a écrit : > On Wed, 2020-12-09 at 20:04 +0100, Laurent Vivier wrote: >> Le 09/12/2020 à 12:34, Bastien Nocera a écrit : >>> On Wed, 2020-12-09 at 12:14 +0100, Laurent Vivier wrote: >> ... >>>>> If the printer has uses the SPP or HCRP printing profiles, you >>>>> should >>>>> see it when using: >>>>> /usr/lib/cups/backend/bluetooth >>>>> without any arguments. >>>> >>>> As I don't see it once it is paired, I guess it is not using one >>>> of >>>> these profiles. >>> >>> I don't remember how this used to work, but you'll probably only >>> see >>> something if the printer is visible. >>> >>> You might be able to get the printer to work by adding: >>> bluetooth://DC0D309023C7 >>> as a printer in the printer settings of your favourite desktop >>> environment, if it actually uses SPP. >>> >>> running the cups backend with: >>> /usr/lib/cups/backend/bluetooth --get-deviceid >>> bluetooth://DC0D309023C7 >>> >>> should show you whether it can get autoconfigured for CUPS use. >>> >> >> Thank you Bastien, it's exactly what I needed to know. >> >> Correct me if I'm wrong but it seems there is a bug in the >> cups/bluetooth >> command: > > Sigh. No, it's not a bug, it's just that the cups tool was never ported > from the bluez 4.x to the current bluez 5.x API... > > Until that's ported (if ever, given the low number of Bluetooth > printers around...), you could try to extract the IEEE1284 ID using: > sdptool records DC:0D:30:90:23:C7 $ sdptool records DC:0D:30:90:23:C7 Service Name: SPP Dev Service RecHandle: 0x10001 Service Class ID List: "Serial Port" (0x1101) Protocol Descriptor List: "L2CAP" (0x0100) "RFCOMM" (0x0003) Channel: 1 Language Base Attr List: code_ISO639: 0x656e encoding: 0x6a base_offset: 0x100 It doesn't seem to provide an IEEE1284 ID. > > But I'm not certain that this working is necessary to actually try a > print. Have you tested that? > Not sure what to do... If I try to add the printer using the GUI, it doesn't appear in the list and I cannot add it manually (Fedora 33/GNOME 3.38.2) in GUI. If I add it with the following command line: lpadmin -p M02 -E -v bluetooth://DC0D309023C7 -P /usr/share/cups/model/Phomemo/Phomemo-M02.ppd.gz It doesn't print anything. But I had some selinux related error: setroubleshoot[13488]: SELinux interdit à bluetooth d'utiliser l'accès connect sur le bluetooth_socket Inconnu.Pour des messages SELinux exhaustifs, lancez sealert -l 965e2270-948f-4791-93f0-3b856c162cea setroubleshoot[13488]: SELinux interdit à bluetooth d'utiliser l'accès connect sur le bluetooth_socket Inconnu. ... So I ran: ausearch -c "bluetooth" --raw | audit2allow -M my-bluetooth semodule -X 300 -i my-bluetooth.pp And now what I have in the syslogs is: cupsd[1185]: REQUEST localhost - - "POST /printers/M02 HTTP/1.1" 200 499560 Print-Job successful-ok DC0D309023C7[14310]: sdp_send_req_w4_rsp: Error sending data:Permission denied DC0D309023C7[14310]: sdp_service_search_attr_req: Unexpected end of packet DC0D309023C7[14310]: sdp_send_req_w4_rsp: Error sending data:Permission denied DC0D309023C7[14310]: sdp_service_search_attr_req: Unexpected end of packet cupsd[1185]: Can\'t get service information DC0D309023C7[14310]: sdp_send_req_w4_rsp: Error sending data:Permission denied DC0D309023C7[14310]: sdp_service_search_attr_req: Unexpected end of packet Thanks, Laurent ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Bluetooth printer connection error 2020-12-09 21:45 ` Laurent Vivier @ 2020-12-10 9:35 ` Bastien Nocera 2020-12-10 9:41 ` Laurent Vivier 0 siblings, 1 reply; 9+ messages in thread From: Bastien Nocera @ 2020-12-10 9:35 UTC (permalink / raw) To: Laurent Vivier, linux-bluetooth On Wed, 2020-12-09 at 22:45 +0100, Laurent Vivier wrote: > Le 09/12/2020 à 21:27, Bastien Nocera a écrit : > > On Wed, 2020-12-09 at 20:04 +0100, Laurent Vivier wrote: > > > Le 09/12/2020 à 12:34, Bastien Nocera a écrit : > > > > On Wed, 2020-12-09 at 12:14 +0100, Laurent Vivier wrote: > > > ... > > > > > > If the printer has uses the SPP or HCRP printing profiles, > > > > > > you > > > > > > should > > > > > > see it when using: > > > > > > /usr/lib/cups/backend/bluetooth > > > > > > without any arguments. > > > > > > > > > > As I don't see it once it is paired, I guess it is not using > > > > > one > > > > > of > > > > > these profiles. > > > > > > > > I don't remember how this used to work, but you'll probably > > > > only > > > > see > > > > something if the printer is visible. > > > > > > > > You might be able to get the printer to work by adding: > > > > bluetooth://DC0D309023C7 > > > > as a printer in the printer settings of your favourite desktop > > > > environment, if it actually uses SPP. > > > > > > > > running the cups backend with: > > > > /usr/lib/cups/backend/bluetooth --get-deviceid > > > > bluetooth://DC0D309023C7 > > > > > > > > should show you whether it can get autoconfigured for CUPS use. > > > > > > > > > > Thank you Bastien, it's exactly what I needed to know. > > > > > > Correct me if I'm wrong but it seems there is a bug in the > > > cups/bluetooth > > > command: > > > > Sigh. No, it's not a bug, it's just that the cups tool was never > > ported > > from the bluez 4.x to the current bluez 5.x API... > > > > Until that's ported (if ever, given the low number of Bluetooth > > printers around...), you could try to extract the IEEE1284 ID > > using: > > sdptool records DC:0D:30:90:23:C7 > > $ sdptool records DC:0D:30:90:23:C7 > Service Name: SPP Dev > Service RecHandle: 0x10001 > Service Class ID List: > "Serial Port" (0x1101) > Protocol Descriptor List: > "L2CAP" (0x0100) > "RFCOMM" (0x0003) > Channel: 1 > Language Base Attr List: > code_ISO639: 0x656e > encoding: 0x6a > base_offset: 0x100 > > It doesn't seem to provide an IEEE1284 ID. > > > > > But I'm not certain that this working is necessary to actually try > > a > > print. Have you tested that? > > > > Not sure what to do... > > If I try to add the printer using the GUI, it doesn't appear in the > list and I cannot add it > manually (Fedora 33/GNOME 3.38.2) in GUI. > > If I add it with the following command line: > > lpadmin -p M02 -E -v bluetooth://DC0D309023C7 -P > /usr/share/cups/model/Phomemo/Phomemo-M02.ppd.gz > > It doesn't print anything. > > But I had some selinux related error: > > setroubleshoot[13488]: SELinux interdit à bluetooth d'utiliser > l'accès connect sur le > bluetooth_socket Inconnu.Pour des messages SELinux exhaustifs, lancez > sealert -l > 965e2270-948f-4791-93f0-3b856c162cea > setroubleshoot[13488]: SELinux interdit à bluetooth d'utiliser > l'accès connect sur le > bluetooth_socket Inconnu. > ... > > So I ran: > > ausearch -c "bluetooth" --raw | audit2allow -M my-bluetooth > semodule -X 300 -i my-bluetooth.pp > > And now what I have in the syslogs is: > > cupsd[1185]: REQUEST localhost - - "POST /printers/M02 HTTP/1.1" 200 > 499560 Print-Job successful-ok > DC0D309023C7[14310]: sdp_send_req_w4_rsp: Error sending > data:Permission denied Well, that's not going to work. I'm afraid that's about as far as I can help you. Ideally, you would port the bluez cups code to the current 5.x API, and then add support for your devices, but it's likely a difficult task without access to non-SPP/HCRP hardware. I'd recommend writing a new cups backend, replacing the bluetooth one for this case (see https://www.cups.org/doc/man-backend.html for the API). Launching without a command-line argument would list the paired phomemo printers, and printing would search the RFCOMM channel on the remote device (see bluez's sdp.c in the cups backend), and connect to it to send the data in the format you expect (see bluez's spp.c in the cups backend). There might be additional refinements I'm missing, but that should be able to get you started. Good luck. ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Bluetooth printer connection error 2020-12-10 9:35 ` Bastien Nocera @ 2020-12-10 9:41 ` Laurent Vivier 0 siblings, 0 replies; 9+ messages in thread From: Laurent Vivier @ 2020-12-10 9:41 UTC (permalink / raw) To: Bastien Nocera, linux-bluetooth Le 10/12/2020 à 10:35, Bastien Nocera a écrit : > On Wed, 2020-12-09 at 22:45 +0100, Laurent Vivier wrote: >> Le 09/12/2020 à 21:27, Bastien Nocera a écrit : >>> On Wed, 2020-12-09 at 20:04 +0100, Laurent Vivier wrote: >>>> Le 09/12/2020 à 12:34, Bastien Nocera a écrit : >>>>> On Wed, 2020-12-09 at 12:14 +0100, Laurent Vivier wrote: >>>> ... >>>>>>> If the printer has uses the SPP or HCRP printing profiles, >>>>>>> you >>>>>>> should >>>>>>> see it when using: >>>>>>> /usr/lib/cups/backend/bluetooth >>>>>>> without any arguments. >>>>>> >>>>>> As I don't see it once it is paired, I guess it is not using >>>>>> one >>>>>> of >>>>>> these profiles. >>>>> >>>>> I don't remember how this used to work, but you'll probably >>>>> only >>>>> see >>>>> something if the printer is visible. >>>>> >>>>> You might be able to get the printer to work by adding: >>>>> bluetooth://DC0D309023C7 >>>>> as a printer in the printer settings of your favourite desktop >>>>> environment, if it actually uses SPP. >>>>> >>>>> running the cups backend with: >>>>> /usr/lib/cups/backend/bluetooth --get-deviceid >>>>> bluetooth://DC0D309023C7 >>>>> >>>>> should show you whether it can get autoconfigured for CUPS use. >>>>> >>>> >>>> Thank you Bastien, it's exactly what I needed to know. >>>> >>>> Correct me if I'm wrong but it seems there is a bug in the >>>> cups/bluetooth >>>> command: >>> >>> Sigh. No, it's not a bug, it's just that the cups tool was never >>> ported >>> from the bluez 4.x to the current bluez 5.x API... >>> >>> Until that's ported (if ever, given the low number of Bluetooth >>> printers around...), you could try to extract the IEEE1284 ID >>> using: >>> sdptool records DC:0D:30:90:23:C7 >> >> $ sdptool records DC:0D:30:90:23:C7 >> Service Name: SPP Dev >> Service RecHandle: 0x10001 >> Service Class ID List: >> "Serial Port" (0x1101) >> Protocol Descriptor List: >> "L2CAP" (0x0100) >> "RFCOMM" (0x0003) >> Channel: 1 >> Language Base Attr List: >> code_ISO639: 0x656e >> encoding: 0x6a >> base_offset: 0x100 >> >> It doesn't seem to provide an IEEE1284 ID. >> >>> >>> But I'm not certain that this working is necessary to actually try >>> a >>> print. Have you tested that? >>> >> >> Not sure what to do... >> >> If I try to add the printer using the GUI, it doesn't appear in the >> list and I cannot add it >> manually (Fedora 33/GNOME 3.38.2) in GUI. >> >> If I add it with the following command line: >> >> lpadmin -p M02 -E -v bluetooth://DC0D309023C7 -P >> /usr/share/cups/model/Phomemo/Phomemo-M02.ppd.gz >> >> It doesn't print anything. >> >> But I had some selinux related error: >> >> setroubleshoot[13488]: SELinux interdit à bluetooth d'utiliser >> l'accès connect sur le >> bluetooth_socket Inconnu.Pour des messages SELinux exhaustifs, lancez >> sealert -l >> 965e2270-948f-4791-93f0-3b856c162cea >> setroubleshoot[13488]: SELinux interdit à bluetooth d'utiliser >> l'accès connect sur le >> bluetooth_socket Inconnu. >> ... >> >> So I ran: >> >> ausearch -c "bluetooth" --raw | audit2allow -M my-bluetooth >> semodule -X 300 -i my-bluetooth.pp >> >> And now what I have in the syslogs is: >> >> cupsd[1185]: REQUEST localhost - - "POST /printers/M02 HTTP/1.1" 200 >> 499560 Print-Job successful-ok >> DC0D309023C7[14310]: sdp_send_req_w4_rsp: Error sending >> data:Permission denied > > Well, that's not going to work. > > I'm afraid that's about as far as I can help you. Ideally, you would > port the bluez cups code to the current 5.x API, and then add support > for your devices, but it's likely a difficult task without access to > non-SPP/HCRP hardware. > > I'd recommend writing a new cups backend, replacing the bluetooth one > for this case (see https://www.cups.org/doc/man-backend.html for the > API). > > Launching without a command-line argument would list the paired phomemo > printers, and printing would search the RFCOMM channel on the remote > device (see bluez's sdp.c in the cups backend), and connect to it to > send the data in the format you expect (see bluez's spp.c in the cups > backend). > > There might be additional refinements I'm missing, but that should be > able to get you started. > > Good luck. > Thank you for your help. I will try to do that. Thanks, Laurent ^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2020-12-10 9:44 UTC | newest] Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2020-12-08 21:25 Bluetooth printer connection error Laurent Vivier 2020-12-09 11:00 ` Bastien Nocera 2020-12-09 11:14 ` Laurent Vivier 2020-12-09 11:34 ` Bastien Nocera 2020-12-09 19:04 ` Laurent Vivier 2020-12-09 20:27 ` Bastien Nocera 2020-12-09 21:45 ` Laurent Vivier 2020-12-10 9:35 ` Bastien Nocera 2020-12-10 9:41 ` Laurent Vivier
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.