Comment 1 for bug 353746

Revision history for this message
TJ (tj) wrote : Re: There was an error during the CUPS operation: 'client-error-not-possible'

After reading the bluez-cups source it seems the required format for device URIs is:

bluetooth://<MAC-address>/[spp | hcrp]

The same failure occurs using the "/spp" suffix.

The printer supports SPP (and works fine on Hardy):

sdptool records 00:04:76:BB:2D:03
Service Name: Serial Port
Service RecHandle: 0x10000
Service Class ID List:
  "Serial Port" (0x00001101)
Protocol Descriptor List:
  "L2CAP" (0x00000100)
  "RFCOMM" (0x00000003)
    Channel: 1

I'm not entirely clear if the following test is related to this issue. I tried directly invoking the bluez-cups backend to see if something might happen... it did - a failure. Whether this is the cause of the cups issue I do not know.

sudo -i
DEVICE_URI="bluetooth://00:04:76:BB:2D:03/spp" /usr/lib/cups/backend/bluetooth 1 tj Test 1 options

DEBUG: /usr/lib/cups/backend/bluetooth device 00:BA:0C:0E:0D:0B service auto fd 0 copies 1 class (none)
STATE: +connecting-to-device
ERROR: Can't open Bluetooth connection

That failure occurs in bluez/cups/main.c::main():

service_search:
 sdp = sdp_connect(BDADDR_ANY, &bdaddr, SDP_RETRY_IF_BUSY);
 if (!sdp) {
  fprintf(stderr, "ERROR: Can't open Bluetooth connection\n");
  return CUPS_BACKEND_FAILED;
 }