[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: CUPS on Bullseye and Bookworm



On Sun 14 May 2023 at 14:04:51 -0600, Charles Curley wrote:

> On Sun, 14 May 2023 19:48:07 +0200
> john doe <johndoe65534@mail.com> wrote:
> 
> > On 5/14/23 19:29, Charles Curley wrote:
> >  [...]  
> > 
> > The below, is what I would try:
> > 
> > - On the non-working client, Are you restricting outbound traffic at
> > all
> 
> Not that I know of.

Blocking port 5353 (mdns) is not unknown.
 
> > or for testing  purposes can you disable the FW?
> 
> I shut the firewall down ("systemctl stop firewalld"), ran test pages.
> Same non-results, except that system-control-printer now reports:
> 
> Idle - Print job canceled at printer.
> 
> 
> I tried increasing the logging, which involved stopping and restarting
> the cups service. In the process of doing that, the client and server
> both managed to forget the printer. I re-installed it. On the server, I
> have one instance of the printer, protocol:
> 
> hp:/usb/HP_LaserJet_MFP_M232-M237?serial=VNB4J02590

Consider: the printer can be discovered via mDNS/DNS-SD by all machines
on the network. ideapc does this and hasn't any difficulty printing. So
why set up a server when hawk will see the printer as ideapc does? 

Additionally, assuming the printer provides the IPP-over-USB protocol,
the USB queue will not work. See

  https://wiki.debian.org/CUPSDriverlessPrinting

> On the non-working client, cups discovered two versions of the printer:
> 
> dnssd://HP%20LaserJet%20MFP%20M234sdw%20(C0FB67)._ipp._tcp.local/?uuid=d532fa73-f559-43ca-9f8e-1eef16972345
> 
> ipps://HP%20LaserJet%20MFP%20M234sdw%20(C0FB67)._ipps._tcp.local/
> 
> I have been testing both and getting the same results.

The two URIs are equivalent.

> > - How are the working clients connected to the printer (protocol
> > wise)?
> 
> implicitclass://HP_LaserJet_MFP_M234sdw_C0FB67_/

cups-browsed has automatically set up a queue. Unless it is having an off-day,
it should do the same on hawk and dragon.
 
> > - Is the non-working client using that same protocol?
> 
> Clearly not.
> 
> So I had the working client discover the printer again. It offered the
> same two as I have on the non-working client. Both printed test pages.
> 
> ipps://HP%20LaserJet%20MFP%20M234sdw%20(C0FB67)._ipps._tcp.local/
> 
> dnssd://HP%20LaserJet%20MFP%20M234sdw%20(C0FB67)._ipp._tcp.local/?uuid=d532fa73-f559-43ca-9f8e-1eef16972345
> 
> 
> > - If you do not use MDNS and point manually to the server, does it
> > work any better?
>  
> I tried setting up a printer manually on the non-working client.
> 
> ipp://hawk.localdomain/printers/HP_LaserJet_MFP_M232-M237

hawk.local would be the correct hostname.

> No test page, and I got:
> 
> Processing - The printer may not exist or is unavailable at this time.
> 
> However, I checked the CUPS on-line documentation, and did not find any
> documentation on how to set up a URI, so it's possible I did that
> incorrectly.
> 
> I also enabled "port 9100" printing on the printer, and went directly to
> it:

That had to be explicitly done?
 
> socket://hpm234ethernet.localdomain:9100

hpm234ethernet.local?

-- 
Brian.


Reply to: