Bluetooth printer connection error

Bluetooth printer connection error

[Laurent Vivier]

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

Re: Bluetooth printer connection error

[Bastien Nocera]

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

Re: Bluetooth printer connection error

[Laurent Vivier]

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

Re: Bluetooth printer connection error

[Bastien Nocera]

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.

Re: Bluetooth printer connection error

[Laurent Vivier]

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

Re: Bluetooth printer connection error

[Bastien Nocera]

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?

Re: Bluetooth printer connection error

[Laurent Vivier]

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

Re: Bluetooth printer connection error

[Bastien Nocera]

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.

Re: Bluetooth printer connection error

[Laurent Vivier]

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