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
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
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
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.
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 <[email protected]>
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
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?
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
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.
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