Re: CUPS - how to match autodetected printers to physical ones

[Brian]

On Sun 26 Feb 2023 at 17:09:51 +0300, Reco wrote:

>   Hi.
> 
> On Sat, Feb 25, 2023 at 11:26:21PM +, Brian wrote:
> > > It's interesting how you bring up DHCP, yet do not mention DHCP option 9
> > > (aka "option lpr-servers" in ISC lingo).
> > > A proper implementation of DHCP options would make DNS-SD (and other
> > > assorted kludges) completely redundant.
> > > But that would be in an ideal world, and in the real world DNS-SD
> > > serves its function (within its inherent limits of course).
> > > If it works, that is.
> > 
> > If the IP address changes, ipp://10.76.172.100/ipp/print as a
> > URI becomes useless. DNS-SD ensures a reachable URI. Got it?
> 
> There's no need to be rude.

Apologies if it came through like that. Note that rfc7472 says

 >...literal IPv4 or IPv6 addresses SHOULD NOT be used...

> Leaving aside changing printer's IP (the main question here is why would
> anyone would do it), how exactly DNS-SD helped Greg to print in that
> environment?

>From one of Greg Wooledge's previous mails:

  > +   eno1 IPv4 Canon LBP712Cdn (db:c0:d3)
  > +   eno1 IPv4 HP LaserJet P3010 Series [0FCDD7]
  > +   eno1 IPv4 hp LaserJet 4250 [621E13]
 
He did not want to use these printers, but they would be shown in
the print dialog of Evince (say), as would be the non-adverised
printer if it had been set up correctly. A click or two to print.

Alternatively, 'lpstat -l -e' and print with 'lp -d PRINTER FILE'.

> > > > It would also be hoped that port numbers and resource
> > > > paths are on the sheet of paper, otherwise a user will have a
> > > > lot of guessing to do.
> > > 
> > > Nope. RTFM would suffice, as always.
> > 
> > I do not think you understand my argument. A port for an IPP
> > printer need not be on 631 and the resource path need not be
> > ipp/print. RTFM hardly helps when there is an immediate need
> > to print.
> 
> I wish you good luck in "convincing" typical dumb printer firmware in
> performing such feats. Bonus points for "convincing" enterprise-grade
> printer firmware to do the same.

IPP printers need not be physical printers.
 
> The main question here, of course, is why complicate things without the
> need?
> 
> 
> > RTFM? Which ones would you recommend?
> 
> This one is good enough:
> 
> https://www.pwg.org/ipp/ippguide.html
> 
> 
> > Actually, CUPS performed splendidly.
> 
> If CUPS in that configuration did not allow a user to print certain
> amount of pages, then it cannot be called splendid.
 
CUPS did not stop a user from printing. It knew of three
printers (see above). The fourth was hidden from it.
 
> > The OP was on a badly set up, unco-operative network. That was (and
> > probably still is) the root of the issue.
> 
> And here it's you who seem to misunderstand the issue.
> It's a city hall, or something like it. People come there, some are in
> the need of printing.
> 
> We have a confirmed and documented case of CUPS failing to deliver the
> desired result (i.e. printing something) in that environment. Without
> additional user configuration, that is.
> 
> Last time I've checked, they did not provide CUPS on any Android phone
> out of the box, and probably it's the same for Apple phones.
> It's likely that some visitor would bring a laptop with them, and it's
> likely that said laptop would run M$ Windoze (or whatever that
> shovelware is called these days).
> If mobile users or M$ laptop users would encounter any trouble printing
> - surely someone would make something to fix it.
> 
> Yet is was not fixed (for a year at most), so it's likely *it works for
> the users*, so there's nothing to fix. Some user configuration on their
> device may be required, or not, it's not relevant here.
> 
> Does that mean that CUPS is in need of fixing? Of course not.
> Does that mean that DNS-SD is not needed? Of course not.
> Does that mean that the only way of printing something via CUPS is to
> use DNS-SD? You can guess it, it's also not.
> 
> 
> Moreover, printing something at a city hall is a rare (although
> periodic) task. If the printer's IP changes between Greg's vistits there
> - so what?

A few quotes from Greg Wooledge's first mail:
 
  > Whatever I managed to do last year... it's not working this
  > year.  I can only assume that my workplace's lovely IT
  > department...


  
  > When I tried to print this year's tax form to my local
  > printer, I learned that the default print queue I had
  > set up last year is no longer there.

  > This led to a complete rerun of everything from last
  > year...

You ask - "so what?" As can be seen, it hardly results in a happy
camper!
 
> > > > How would an ordinary user go on? "Give them a piece of paper" sounds
> > > > awfully like "Let them eat cake".
> > > 
> > > Easy, a user should RTFM. Failing that, a user can use a different
> > > device or OS, or *gasp* - just use ipptool. Given the environment, a
> > > creative use of samba

Re: CUPS - how to match autodetected printers to physical ones

[Reco]

Hi.

On Sat, Feb 25, 2023 at 11:26:21PM +, Brian wrote:
> > It's interesting how you bring up DHCP, yet do not mention DHCP option 9
> > (aka "option lpr-servers" in ISC lingo).
> > A proper implementation of DHCP options would make DNS-SD (and other
> > assorted kludges) completely redundant.
> > But that would be in an ideal world, and in the real world DNS-SD
> > serves its function (within its inherent limits of course).
> > If it works, that is.
> 
> If the IP address changes, ipp://10.76.172.100/ipp/print as a
> URI becomes useless. DNS-SD ensures a reachable URI. Got it?

There's no need to be rude.
Leaving aside changing printer's IP (the main question here is why would
anyone would do it), how exactly DNS-SD helped Greg to print in that
environment?


> > > It would also be hoped that port numbers and resource
> > > paths are on the sheet of paper, otherwise a user will have a
> > > lot of guessing to do.
> > 
> > Nope. RTFM would suffice, as always.
> 
> I do not think you understand my argument. A port for an IPP
> printer need not be on 631 and the resource path need not be
> ipp/print. RTFM hardly helps when there is an immediate need
> to print.

I wish you good luck in "convincing" typical dumb printer firmware in
performing such feats. Bonus points for "convincing" enterprise-grade
printer firmware to do the same.

The main question here, of course, is why complicate things without the
need?


> RTFM? Which ones would you recommend?

This one is good enough:

https://www.pwg.org/ipp/ippguide.html


> Actually, CUPS performed splendidly.

If CUPS in that configuration did not allow a user to print certain
amount of pages, then it cannot be called splendid.


> The OP was on a badly set up, unco-operative network. That was (and
> probably still is) the root of the issue.

And here it's you who seem to misunderstand the issue.
It's a city hall, or something like it. People come there, some are in
the need of printing.

We have a confirmed and documented case of CUPS failing to deliver the
desired result (i.e. printing something) in that environment. Without
additional user configuration, that is.

Last time I've checked, they did not provide CUPS on any Android phone
out of the box, and probably it's the same for Apple phones.
It's likely that some visitor would bring a laptop with them, and it's
likely that said laptop would run M$ Windoze (or whatever that
shovelware is called these days).
If mobile users or M$ laptop users would encounter any trouble printing
- surely someone would make something to fix it.

Yet is was not fixed (for a year at most), so it's likely *it works for
the users*, so there's nothing to fix. Some user configuration on their
device may be required, or not, it's not relevant here.

Does that mean that CUPS is in need of fixing? Of course not.
Does that mean that DNS-SD is not needed? Of course not.
Does that mean that the only way of printing something via CUPS is to
use DNS-SD? You can guess it, it's also not.


Moreover, printing something at a city hall is a rare (although
periodic) task. If the printer's IP changes between Greg's vistits there
- so what?


> > > How would an ordinary user go on? "Give them a piece of paper" sounds
> > > awfully like "Let them eat cake".
> > 
> > Easy, a user should RTFM. Failing that, a user can use a different
> > device or OS, or *gasp* - just use ipptool. Given the environment, a
> > creative use of samba suite would probably solve the problem too, but
> > let's not get into *that*.
> > And there's that last step - just ask somebody.
> 
> You welcome Big Boss into your office for a $100M deal.

Nope. Either it's the "ordinary user" or it's the "Big Boss".
Please choose one.

Reco

Re: CUPS - how to match autodetected printers to physical ones

[Brian]

On Sat 25 Feb 2023 at 22:22:55 +0300, Reco wrote:

> On Sat, Feb 25, 2023 at 06:30:28PM +, Brian wrote:
> > On Sat 25 Feb 2023 at 17:44:15 +0300, Reco wrote:
> > 
> > >   Hi.
> > > 
> > > On Fri, Feb 24, 2023 at 12:58:15PM -0500, Greg Wooledge wrote:
> > > > On Fri, Feb 17, 2023 at 05:35:11PM +0300, Reco wrote:
> > > > > Try this next time you're on site:
> > > > > 
> > > > > lpadmin -p D14841 -E -v ipp://10.76.172.100/ipp/print -m everywhere
> > > > 
> > > > This worked.  I printed two copies of the single-page PDF from Chrome
> > > > without any further problems.
> > > 
> > > Just as planned. CUPS autodiscovery is only good for something if you
> > > don't know printer's real IP. This little episode shows us that nothing
> > > beats IP-on-sheet-of-paper discovery.
> >  
> > 99% of users with tablets, smart phones, laptops etc would find
> > DNS-SD more to their liking, especially if DHCP assignment is
> > in place.
> 
> It's interesting how you bring up DHCP, yet do not mention DHCP option 9
> (aka "option lpr-servers" in ISC lingo).
> A proper implementation of DHCP options would make DNS-SD (and other
> assorted kludges) completely redundant.
> But that would be in an ideal world, and in the real world DNS-SD
> serves its function (within its inherent limits of course).
> If it works, that is.

If the IP address changes, ipp://10.76.172.100/ipp/print as a
URI becomes useless. DNS-SD ensures a reachable URI. Got it?

It's as simple as that. Why complicate it with what DHCP can
do or not do?
 
> > It would also be hoped that port numbers and resource
> > paths are on the sheet of paper, otherwise a user will have a
> > lot of guessing to do.
> 
> Nope. RTFM would suffice, as always.

I do not think you understand my argument. A port for an IPP
printer need not be on 631 and the resource path need not be
ipp/print. RTFM hardly helps when there is an immediate need
to print.

RTFM? Which ones would you recommend?

> > In this thread we see how a very experienced user reacted to
> > being denied mdns multicasting.
> 
> Allow me to quote that original e-mail for the sake of completeness:
> 
> > So the printer WORKS.  It is ON THE NETWORK.  I can print TEXT to it
> > using port 9100.
> > 
> > What I CANNOT do is find it in CUPS.  Or avahi-browse, or driverless, or
> > any of these other commands that are so allegedly wonderful.
> > 
> > Is there any way I can tell CUPS "Please set up a queue for a printer
> > whose IP address is 10.76.172.100 even though you can't discover it with
> > your fancy tools"?
> 
> The way I see it, Greg wrote about a CUPS configuration problem.
> The solution of said problem was (and still is btw) at lpadmin(8).
> Of course, to know that the solution just lies there, waiting to be
> implemented, that requires one to have a knowledge of CUPS administration.
> Luckily we have debian-user for last one.

Your interpretation of the OP's situation is misguided. He was
confused and, as such users do sometimes, lashed out at anything
in sight. There was not any CUPS missconfiguration.

Actually, CUPS performed splendidly. The OP was on a badly set
up, unco-operative network. That was (and probably still is) the
root of the issue.

> > How would an ordinary user go on? "Give them a piece of paper" sounds
> > awfully like "Let them eat cake".
> 
> Easy, a user should RTFM. Failing that, a user can use a different
> device or OS, or *gasp* - just use ipptool. Given the environment, a
> creative use of samba suite would probably solve the problem too, but
> let's not get into *that*.
> And there's that last step - just ask somebody.

You welcome Big Boss into your office for a $100M deal.

  Big Boss: Contract's on my phone. Let's print it and I'll sign.
What's the printer name?

  You: GimmeMoney

  Big Boss: Can't see it.

  You: Just let me read the manual and do a bit of network probing.

  Big Boss: (10 minutes later). Any joy?

  You: No. I'll go ask someone. Give me half an hour.

  Big Boss: I'm a busy woman with other options. Goodbye.

-- 
Brian.

Re: CUPS - how to match autodetected printers to physical ones

[Reco]

On Sat, Feb 25, 2023 at 06:30:28PM +, Brian wrote:
> On Sat 25 Feb 2023 at 17:44:15 +0300, Reco wrote:
> 
> > Hi.
> > 
> > On Fri, Feb 24, 2023 at 12:58:15PM -0500, Greg Wooledge wrote:
> > > On Fri, Feb 17, 2023 at 05:35:11PM +0300, Reco wrote:
> > > > Try this next time you're on site:
> > > > 
> > > > lpadmin -p D14841 -E -v ipp://10.76.172.100/ipp/print -m everywhere
> > > 
> > > This worked.  I printed two copies of the single-page PDF from Chrome
> > > without any further problems.
> > 
> > Just as planned. CUPS autodiscovery is only good for something if you
> > don't know printer's real IP. This little episode shows us that nothing
> > beats IP-on-sheet-of-paper discovery.
>  
> 99% of users with tablets, smart phones, laptops etc would find
> DNS-SD more to their liking, especially if DHCP assignment is
> in place.

It's interesting how you bring up DHCP, yet do not mention DHCP option 9
(aka "option lpr-servers" in ISC lingo).
A proper implementation of DHCP options would make DNS-SD (and other
assorted kludges) completely redundant.
But that would be in an ideal world, and in the real world DNS-SD
serves its function (within its inherent limits of course).
If it works, that is.


> It would also be hoped that port numbers and resource
> paths are on the sheet of paper, otherwise a user will have a
> lot of guessing to do.

Nope. RTFM would suffice, as always.


> In this thread we see how a very experienced user reacted to
> being denied mdns multicasting.

Allow me to quote that original e-mail for the sake of completeness:

> So the printer WORKS.  It is ON THE NETWORK.  I can print TEXT to it
> using port 9100.
> 
> What I CANNOT do is find it in CUPS.  Or avahi-browse, or driverless, or
> any of these other commands that are so allegedly wonderful.
> 
> Is there any way I can tell CUPS "Please set up a queue for a printer
> whose IP address is 10.76.172.100 even though you can't discover it with
> your fancy tools"?

The way I see it, Greg wrote about a CUPS configuration problem.
The solution of said problem was (and still is btw) at lpadmin(8).
Of course, to know that the solution just lies there, waiting to be
implemented, that requires one to have a knowledge of CUPS administration.
Luckily we have debian-user for last one.


> How would an ordinary user go on? "Give them a piece of paper" sounds
> awfully like "Let them eat cake".

Easy, a user should RTFM. Failing that, a user can use a different
device or OS, or *gasp* - just use ipptool. Given the environment, a
creative use of samba suite would probably solve the problem too, but
let's not get into *that*.
And there's that last step - just ask somebody.


> > > I've gotta say, though, this option is a disaster:
> > > 
> > >   -E  When specified before the -d, -p, or -x options, forces the use of
> > >   TLS encryption on the connection to the scheduler. Otherwise, 
> > > enables
> > >   the destination and accepts jobs; this is the same as running the
> > >   cupsaccept(8) and cupsenable(8) programs on the destination.
> > > 
> > > Whoever decided to overload that option in that way... yikes.
> > 
> > Back in the day Apple's slogan was "think different". The whole CUPS
> > suite is a living proof of that.
> 
> Wrong target! -E was there in its present form well before Apple
> acquired CUPS.

I stand corrected here.

Reco

Re: CUPS - how to match autodetected printers to physical ones

[Brian]

On Sat 25 Feb 2023 at 17:44:15 +0300, Reco wrote:

>   Hi.
> 
> On Fri, Feb 24, 2023 at 12:58:15PM -0500, Greg Wooledge wrote:
> > On Fri, Feb 17, 2023 at 05:35:11PM +0300, Reco wrote:
> > > Try this next time you're on site:
> > > 
> > > lpadmin -p D14841 -E -v ipp://10.76.172.100/ipp/print -m everywhere
> > 
> > This worked.  I printed two copies of the single-page PDF from Chrome
> > without any further problems.
> 
> Just as planned. CUPS autodiscovery is only good for something if you
> don't know printer's real IP. This little episode shows us that nothing
> beats IP-on-sheet-of-paper discovery.
 
99% of users with tablets, smart phones, laptops etc would find
DNS-SD more to their liking, especially if DHCP assignment is
in place. It would also be hoped that port numbers and resource
paths are on the sheet of paper, otherwise a user will have a
lot of guessing to do.

In this thread we see how a very experienced user reacted to
being denied mdns multicasting. How would an ordinary user go
on? "Give them a piece of paper" sounds awfully like "Let them
eat cake".
 
> > I've gotta say, though, this option is a disaster:
> > 
> >   -E  When specified before the -d, -p, or -x options, forces the use of
> >   TLS encryption on the connection to the scheduler. Otherwise, enables
> >   the destination and accepts jobs; this is the same as running the
> >   cupsaccept(8) and cupsenable(8) programs on the destination.
> > 
> > Whoever decided to overload that option in that way... yikes.
> 
> Back in the day Apple's slogan was "think different". The whole CUPS
> suite is a living proof of that.

Wrong target! -E was there in its present form well before Apple
acquired CUPS.

-- 
Brian.

Re: CUPS - how to match autodetected printers to physical ones

[Reco]

Hi.

On Fri, Feb 24, 2023 at 12:58:15PM -0500, Greg Wooledge wrote:
> On Fri, Feb 17, 2023 at 05:35:11PM +0300, Reco wrote:
> > Try this next time you're on site:
> > 
> > lpadmin -p D14841 -E -v ipp://10.76.172.100/ipp/print -m everywhere
> 
> This worked.  I printed two copies of the single-page PDF from Chrome
> without any further problems.

Just as planned. CUPS autodiscovery is only good for something if you
don't know printer's real IP. This little episode shows us that nothing
beats IP-on-sheet-of-paper discovery.


> I've gotta say, though, this option is a disaster:
> 
>   -E  When specified before the -d, -p, or -x options, forces the use of
>   TLS encryption on the connection to the scheduler. Otherwise, enables
>   the destination and accepts jobs; this is the same as running the
>   cupsaccept(8) and cupsenable(8) programs on the destination.
> 
> Whoever decided to overload that option in that way... yikes.

Back in the day Apple's slogan was "think different". The whole CUPS
suite is a living proof of that.

Reco

Re: CUPS - how to match autodetected printers to physical ones

[Brian]

On Fri 24 Feb 2023 at 12:58:15 -0500, Greg Wooledge wrote:

> On Fri, Feb 17, 2023 at 05:35:11PM +0300, Reco wrote:
> > Try this next time you're on site:
> > 
> > lpadmin -p D14841 -E -v ipp://10.76.172.100/ipp/print -m everywhere
> 
> This worked.  I printed two copies of the single-page PDF from Chrome
> without any further problems.

Good.

As I have previous indicated, this works because the vendor
has not used ipp/canon as the resource, which it is at
liberty to do so.

A previous off-target comment was

  > My burning hatred of printers and this printing system
  > remains unquenched.

Your hatred is aimed at completely the wrong target. How
is it expected to have CUPS discover a printer when mdns
multicasting is turned off on the printer by an incompetent
sysadmin?

> I've gotta say, though, this option is a disaster:
> 
>   -E  When specified before the -d, -p, or -x options, forces the use of
>   TLS encryption on the connection to the scheduler. Otherwise, enables
>   the destination and accepts jobs; this is the same as running the
>   cupsaccept(8) and cupsenable(8) programs on the destination.
> 
> Whoever decided to overload that option in that way... yikes.

I could tell you, but perthaps you might want to find out for
yourself instead of griping. Reporting (or searching) an issue
at

  https://github.com/OpenPrinting/cups/issues

might be easier than tackling the staff of your Help Desk.

-- 
Brian.

Re: CUPS - how to match autodetected printers to physical ones

[Greg Wooledge]

On Fri, Feb 17, 2023 at 05:35:11PM +0300, Reco wrote:
> Try this next time you're on site:
> 
> lpadmin -p D14841 -E -v ipp://10.76.172.100/ipp/print -m everywhere

This worked.  I printed two copies of the single-page PDF from Chrome
without any further problems.

I've gotta say, though, this option is a disaster:

  -E  When specified before the -d, -p, or -x options, forces the use of
  TLS encryption on the connection to the scheduler. Otherwise, enables
  the destination and accepts jobs; this is the same as running the
  cupsaccept(8) and cupsenable(8) programs on the destination.

Whoever decided to overload that option in that way... yikes.

Re: CUPS - how to match autodetected printers to physical ones

[Max Nikulin]

On 16/02/2023 22:41, Greg Wooledge wrote:


2) Also suggested: avahi-browse -rt _ipp._tcp
This year, the output of that command no longer contains my printer's
IP address.  Last year, it did.  I have no idea why this has changed.


Avahi was mentioned in the ipv6 thread, so I decided to read links on 
the Debian wiki page


https://en.wikipedia.org/wiki/Avahi_%28software%29

Avahi's performance resembles that of Bonjour, sometimes exceeding it;
however Avahi can lose services when managing large numbers of requests
simultaneously.[3]
3. Analysis of Peer-to-Peer Protocols Performance for Establishing a
Decentralized Desktop Grid Middleware
http://lipn.fr/~cerin/documents/PresentationSGS08heithem.pdf


Unsure if it is relevant


4) Also mentioned: port 9100.
For grins, I did "telnet 10.76.172.100 9100" and after that connected
I typed "HELLO WORLD", then pressed Enter, then Ctrl-] q Enter to
close the telnet session.


I am curious if there is some tool convenient to get report concerning 
various service service discovery protocols provided at some ip 
(mDNS-SD, uPnP, etc.).



Queue \\SPS\S010NEURD14841M


Does anyone know what technology is used by windows nowadays (Simple 
Service Discovery Protocol, SSDP?) and which tools can be used in Linux 
to get list of services?

Re: CUPS - how to match autodetected printers to physical ones

[Brian]

On Fri 17 Feb 2023 at 09:05:39 -0500, Greg Wooledge wrote:

> On Fri, Feb 17, 2023 at 11:18:32AM +, Brian wrote:

[...]

> >   avahi-browse -rt _ipp._tcp
> >   avahi-browse -rt _uscan._tcp
> > 
> > (I would find that data useful for my records).
> 
> wooledg:~$ avahi-browse -rt _ipp._tcp 2>&1 | grep -A5 db:c0:d3
> +   eno1 IPv4 Canon LBP712Cdn (db:c0:d3)Internet Printer  
>local
> +   eno1 IPv4 HP LaserJet P3010 Series [0FCDD7] Internet Printer  
>local
> +   eno1 IPv4 hp LaserJet 4250 [621E13] Internet Printer  
>local
> =   eno1 IPv4 Canon LBP712Cdn (db:c0:d3)Internet Printer  
>local
>hostname = [dhcp-10-76-173-174.local]
>address = [10.76.173.174]
>port = [631]
>txt = ["mopria-certified=1.2" "print_wfds=T" 
> "kind=document,envelope,postcard" 
> "URF=ADOBERGB24,CP255,DM1,FN3,IS1-4,OB10,PQ4,RS300,SRGB24,V1.4,W8-16" "Fax=F" 
> "Scan=F" "TLS=1.2" "usb_CMD=LIPSLX" 
> "UUID=15904ba4-fe8c-3bee-5d53-cb5f72ea86b2" "PaperMax=legal-A4" "Punch=0" 
> "Staple=F" "Sort=T" "Collate=T" "Bind=F" "PaperCustom=T" "Duplex=T" 
> "Copies=T" "Color=T" "TBCP=F" "Binary=F" "Transparent=F" "usb_MDL=LBP712C UFR 
> II" "usb_MFG=Canon" "adminurl=https://dhcp-10-76-173-174.local/airprint.html"; 
> "pdl=application/octet-stream,image/urf,image/pwg-raster,image/jpeg,application/pdf"
>  "product=(CNLBP712C)" "ty=Canon LBP712C" "priority=10" "qtotal=1" "note=" 
> "rp=ipp/print" "txtvers=1"]
> =   eno1 IPv4 hp LaserJet 4250 [621E13] Internet Printer  
>local

Assuming the machine at 10.76.172.100 is identical with this one
at 10.76.173.174, it too will have a TXT record with

  
pdl=application/octet-stream,image/urf,image/pwg-raster,image/jpeg,application/pdf

A PDF sent directly to it should print if an open port 9100 exists
on the printer:

  netcat 10.76.172.100 9100 < taxform.pdf

> wooledg:~$ time avahi-browse -rt _uscan._tcp
> real 1.023  user 0.004  sys 0.004
> 
> (No other output.)

No prolem here. The LBP712Cdn does not have a scanner.

It looks like mdns multcasting has been disabled on the printer
at 10.76.172.100. This is unfortunate and unnecessary. Perhaps
someone should inform your helpful Help Desk that its Bonjour
name can be changed to distinguish it from similare devices on
the network.

-- 
Brian.

Re: CUPS - how to match autodetected printers to physical ones

[Reco]

Hi.

On Thu, Feb 16, 2023 at 10:41:33AM -0500, Greg Wooledge wrote:
> So the printer WORKS.  It is ON THE NETWORK.  I can print TEXT to it
> using port 9100.
> 
> What I CANNOT do is find it in CUPS.  Or avahi-browse, or driverless, or
> any of these other commands that are so allegedly wonderful.
> 
> Is there any way I can tell CUPS "Please set up a queue for a printer
> whose IP address is 10.76.172.100 even though you can't discover it with
> your fancy tools"?

Try this next time you're on site:

lpadmin -p D14841 -E -v ipp://10.76.172.100/ipp/print -m everywhere

Reco

Re: CUPS - how to match autodetected printers to physical ones

[Greg Wooledge]

On Fri, Feb 17, 2023 at 11:18:32AM +, Brian wrote:
> On Thu 16 Feb 2023 at 15:32:47 -0500, Greg Wooledge wrote:
> 
> > wooledg:~$ cat /etc/debian_version 
> > 11.6
> > wooledg:~$ lpstat -l -e
> > Canon_LBP712C_UFR_II_ permanent 
> > ipp://localhost/printers/Canon_LBP712C_UFR_II_ 
> > ipp://Canon%20LBP712Cdn%20(db%3Ac0%3Ad3)._ipp._tcp.local/
> 
> This is a print queue, set up using Canon drivers.
> 
> > Canon_LBP712Cdn_db_c0_d3_ network none 
> > ipp://Canon%20LBP712Cdn%20(db%3Ac0%3Ad3)._ipp._tcp.local/
> 
> This is not a print queue. CUPS has discovered the printer via
> mdns/DNS-SD and enumetated it. It should be seen with
> 
>   avahi-browse -rt _ipp._tcp
>   avahi-browse -rt _uscan._tcp
> 
> (I would find that data useful for my records).

wooledg:~$ avahi-browse -rt _ipp._tcp 2>&1 | grep -A5 db:c0:d3
+   eno1 IPv4 Canon LBP712Cdn (db:c0:d3)Internet Printer
 local
+   eno1 IPv4 HP LaserJet P3010 Series [0FCDD7] Internet Printer
 local
+   eno1 IPv4 hp LaserJet 4250 [621E13] Internet Printer
 local
=   eno1 IPv4 Canon LBP712Cdn (db:c0:d3)Internet Printer
 local
   hostname = [dhcp-10-76-173-174.local]
   address = [10.76.173.174]
   port = [631]
   txt = ["mopria-certified=1.2" "print_wfds=T" 
"kind=document,envelope,postcard" 
"URF=ADOBERGB24,CP255,DM1,FN3,IS1-4,OB10,PQ4,RS300,SRGB24,V1.4,W8-16" "Fax=F" 
"Scan=F" "TLS=1.2" "usb_CMD=LIPSLX" "UUID=15904ba4-fe8c-3bee-5d53-cb5f72ea86b2" 
"PaperMax=legal-A4" "Punch=0" "Staple=F" "Sort=T" "Collate=T" "Bind=F" 
"PaperCustom=T" "Duplex=T" "Copies=T" "Color=T" "TBCP=F" "Binary=F" 
"Transparent=F" "usb_MDL=LBP712C UFR II" "usb_MFG=Canon" 
"adminurl=https://dhcp-10-76-173-174.local/airprint.html"; 
"pdl=application/octet-stream,image/urf,image/pwg-raster,image/jpeg,application/pdf"
 "product=(CNLBP712C)" "ty=Canon LBP712C" "priority=10" "qtotal=1" "note=" 
"rp=ipp/print" "txtvers=1"]
=   eno1 IPv4 hp LaserJet 4250 [621E13] Internet Printer
 local

wooledg:~$ time avahi-browse -rt _uscan._tcp
real 1.023  user 0.004  sys 0.004

(No other output.)

> Its URI will be
> 
>   ipp://10.76.172.100/ipp/print
> 
> Execute
> 
>   lpadmin -p mycanonprinter -v URI -E -m everywhere
> 
> Test printing with
> 
>   lp -d mycanonprinter /etc/nsswitch.conf

Any physical tests will have to wait, at least a week.

Oh, one other thing in case you were confused: the netmask there is
/23 not /24.  10.76.172.x and 10.76.173.x are both on that subnet.
Each subnet is assigned to one physical floor of a building.  That
particular subnet covers the 10th floor of building S, which is...
not an enormous space, but not small either.  At full capacity, there
could be a few dozen people working there, and the space is divided into
separate sections, each behind its own locked door(s).

Re: CUPS - how to match autodetected printers to physical ones

[Brian]

On Thu 16 Feb 2023 at 15:32:47 -0500, Greg Wooledge wrote:

> wooledg:~$ cat /etc/debian_version 
> 11.6
> wooledg:~$ lpstat -l -e
> Canon_LBP712C_UFR_II_ permanent 
> ipp://localhost/printers/Canon_LBP712C_UFR_II_ 
> ipp://Canon%20LBP712Cdn%20(db%3Ac0%3Ad3)._ipp._tcp.local/

This is a print queue, set up using Canon drivers.

> Canon_LBP712Cdn_db_c0_d3_ network none 
> ipp://Canon%20LBP712Cdn%20(db%3Ac0%3Ad3)._ipp._tcp.local/

This is not a print queue. CUPS has discovered the printer via
mdns/DNS-SD and enumetated it. It should be seen with

  avahi-browse -rt _ipp._tcp
  avahi-browse -rt _uscan._tcp

(I would find that data useful for my records).

It can be printed to with

  lp -d "Canon_LBP712Cdn_db_c0_d3_" FILE

Where the job  physically ends up is outside the scope of
CUPS.

Let's assume the printer you ar interested in is not being
multicast. It exists at 10.76.172.100. Let us guess that
the resource to access on the printer is ipp/print. This is
a pretty good guess because most vendors use it nowadays.

Its URI will be

  ipp://10.76.172.100/ipp/print

Execute

  lpadmin -p mycanonprinter -v URI -E -m everywhere

Test printing with

  lp -d mycanonprinter /etc/nsswitch.conf

-- 
Brian.

Re: CUPS - how to match autodetected printers to physical ones

[Greg Wooledge]

On Thu, Feb 16, 2023 at 03:51:47PM -0500, gene heskett wrote:
> I hate to ask the obvious, but is the net cable plugged into that printer?

See below.

On Thu, Feb 16, 2023 at 10:41:33AM -0500, Greg Wooledge wrote:
> 4) Also mentioned: port 9100.
>For grins, I did "telnet 10.76.172.100 9100" and after that connected
>I typed "HELLO WORLD", then pressed Enter, then Ctrl-] q Enter to
>close the telnet session.
> 
>That actually printed the words HELLO WORLD on a sheet of paper.
> 
> So the printer WORKS.  It is ON THE NETWORK.  I can print TEXT to it
> using port 9100.

Re: CUPS - how to match autodetected printers to physical ones

[gene heskett]

On 2/16/23 16:09, Bob McGowan wrote:

On 2/16/23 12:01 PM, Brian wrote:

On Thu 16 Feb 2023 at 11:27:25 -0800, Bob McGowan wrote:


On 2/16/23 11:14 AM, Brian wrote:

On Thu 16 Feb 2023 at 11:52:21 -0500, Stefan Monnier wrote:


[1]to...@tuxteam.de  [2023-02-16 16:53:02] wrote:

Just for kicks: have you tried sending a PS (or *gasp* PDF) file
down that alley (e.g. with socat)?

For That One Form in the Year this might be just sufficient...

Hint: start with a small one :)

I don't think "a small one" can be small enough in case it misfires.
Instead, I usually make sure there's only 1 sheet of paper in the tray
when I send the test (usually a sheet that I already used :-)

Producind a PDF with the line "This is a test" in it is
incredibly easy. Jumping through hoops is not needed.


However, the PDF file created (I used LibreOffice 'cause its fast and
easy) was 7,335 characters long, according to 'wc', which also reported
367 "words" and 139 "lines".

Given that a standard US letter size sheet (8.5 by 11 inches) has 66
lines per page, that is just over 2 pages.

So putting only one used sheet of paper in the printer would save a
couple of sheets of paper. ;)

Not much but why waste paper for a simple test?

I have no desire or intention to investigate how LibreOffice
deals with a single line text file converted to a PDF. This
works to not waste paper when fileout.pdf is printed:

  /usr/lib/cups/filter/texttopdf 1 1 1 1 1 filein.txt > fileout.pdf


The point is that conversion to PDF results in a larger file than some 
might expect.


Depends on the content. recent activity in adding gfx content to it has 
expanded it quite a bit this file is now 1316 pages long on dead tree:


rw-r--r-- 1 root root 25471049 Feb 14 09:50 LinuxCNC_Documentation.pdf

But for whats in it gfx-wise today, just over 25 megabytes is really 
good compression.


And we don't know if the printer actually does understands PDF 
directly.  If it does not, it would attempt to print the entire contents 
of the file as plain text.  At least, this is how I understood the 
comment I was responding to.


In the case of your command (which, by the way, requires some "esoteric" 
knowledge of CUPS), the resulting file, according to 'wc', is: 85  181 
1020 fileout.pdf


Not as big as the LibreOffice file, but still more than one page of 
output if printed as plain text.


And 99% of that "small" file is non-printed mode commands to the 
printer, telling it how to present that one line of text. 25+ years ago 
when ghostscript tried to be all, both ps v1.3 and v1.2 pdf at about 
v5.1, I'm the one who compiled it for the amiga's, even devising a 
couple bash scripts that made a simplex printer do duplex. I tried to 
wear out a xerox 1650-ro, the fastest daisy wheel ever, failed, it still 
works but no ribbons today.


Cheers, Gene Heskett.
--
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page 

Re: CUPS - how to match autodetected printers to physical ones

[Bob McGowan]

On 2/16/23 12:01 PM, Brian wrote:

On Thu 16 Feb 2023 at 11:27:25 -0800, Bob McGowan wrote:


On 2/16/23 11:14 AM, Brian wrote:

On Thu 16 Feb 2023 at 11:52:21 -0500, Stefan Monnier wrote:


[1]to...@tuxteam.de  [2023-02-16 16:53:02] wrote:

Just for kicks: have you tried sending a PS (or *gasp* PDF) file
down that alley (e.g. with socat)?

For That One Form in the Year this might be just sufficient...

Hint: start with a small one :)

I don't think "a small one" can be small enough in case it misfires.
Instead, I usually make sure there's only 1 sheet of paper in the tray
when I send the test (usually a sheet that I already used :-)

Producind a PDF with the line "This is a test" in it is
incredibly easy. Jumping through hoops is not needed.


However, the PDF file created (I used LibreOffice 'cause its fast and
easy) was 7,335 characters long, according to 'wc', which also reported
367 "words" and 139 "lines".

Given that a standard US letter size sheet (8.5 by 11 inches) has 66
lines per page, that is just over 2 pages.

So putting only one used sheet of paper in the printer would save a
couple of sheets of paper. ;)

Not much but why waste paper for a simple test?

I have no desire or intention to investigate how LibreOffice
deals with a single line text file converted to a PDF. This
works to not waste paper when fileout.pdf is printed:

  /usr/lib/cups/filter/texttopdf 1 1 1 1 1 filein.txt > fileout.pdf


The point is that conversion to PDF results in a larger file than some 
might expect.


And we don't know if the printer actually does understands PDF 
directly.  If it does not, it would attempt to print the entire contents 
of the file as plain text.  At least, this is how I understood the 
comment I was responding to.


In the case of your command (which, by the way, requires some "esoteric" 
knowledge of CUPS), the resulting file, according to 'wc', is: 85  181 
1020 fileout.pdf


Not as big as the LibreOffice file, but still more than one page of 
output if printed as plain text.

Re: CUPS - how to match autodetected printers to physical ones

[gene heskett]

On 2/16/23 15:33, Greg Wooledge wrote:

On Thu, Feb 16, 2023 at 06:57:46PM +0200, Teemu Likonen wrote:

Here is my version which I suggest turning into a shell alias, function
or script:

 avahi-browse -atrp 2>/dev/null | awk -F\; \
 '$1 == "=" { printf "%-23s %-26s %5s %s\n",$7,$8,$9,$5 }'

It should print lines like these:

 SEC00159939FFD2.local   192.168.0.11 631 Internet Printer
 mithlond.local  192.168.0.2  631 Internet Printer


wooledg:~$ avahi-browse -atrp 2>/dev/null | awk -F\; '$1 == "=" { printf "%-23s 
%-26s %5s %s\n",$7,$8,$9,$5 }'
dhcp-10-76-173-174.local 10.76.173.174631 Internet Printer
wooledg.local   fe80::9e7b:efff:fe24:4213445 Microsoft Windows 
Network
wooledg.local   fe80::9e7b:efff:fe24:4213  0 Device Info
wooledg.local   10.76.172.189445 Microsoft Windows 
Network
wooledg.local   10.76.172.189  0 Device Info
wooledg.local   127.0.0.1445 Microsoft Windows 
Network
wooledg.local   127.0.0.1  0 Device Info
NPI0FCDD7.local 10.76.173.60 631 Internet Printer
NPI0FCDD7.local 10.76.173.60 515 UNIX Printer
NPI0FCDD7.local 10.76.173.60 631 Internet Printer
NPI0FCDD7.local 10.76.173.60 515 UNIX Printer
A09-LBT2-HPLJ4250-01.local 10.76.172.120631 Internet Printer
A09-LBT2-HPLJ4250-01.local 10.76.172.120515 UNIX Printer
dhcp-10-76-173-174.local 10.76.173.174515 UNIX Printer
dhcp-10-76-173-174.local 10.76.173.174 80 Web Site
dhcp-10-76-173-174.local 10.76.173.174   9100 PDL Printer
NPI0FCDD7.local 10.76.173.609100 PDL Printer
NPI0FCDD7.local 10.76.173.60  80 Web Site
NPI0FCDD7.local 10.76.173.60  21 FTP File Transfer
NPI0FCDD7.local 10.76.173.60  23 Telnet Remote Terminal
NPI0FCDD7.local 10.76.173.609100 PDL Printer
NPI0FCDD7.local 10.76.173.60  80 Web Site
NPI0FCDD7.local 10.76.173.60  21 FTP File Transfer
NPI0FCDD7.local 10.76.173.60  23 Telnet Remote Terminal
A09-LBT2-HPLJ4250-01.local 10.76.172.120   9100 PDL Printer
A09-LBT2-HPLJ4250-01.local 10.76.172.120 80 Web Site
A09-LBT2-HPLJ4250-01.local 10.76.172.120 21 FTP File Transfer
A09-LBT2-HPLJ4250-01.local 10.76.172.120 23 Telnet Remote 
Terminal

It does not report the printer at 10.76.172.100.  I imagine that it would
have reported it a year ago.  I don't know what changed.


I would try to add manually one of these connection addresses:

 http://10.76.172.100:631
 ipp://10.76.172.100:631


I can try that next time I'm physically there, usually once a week.

On Thu, Feb 16, 2023 at 06:54:18PM +, Brian wrote:

On Thu 16 Feb 2023 at 10:41:33 -0500, Greg Wooledge wrote:

[...]


3) Also suggested: driverless
Here's what I get this year:

wooledg:~$ driverless
ipp://Canon%20LBP712Cdn%20(db%3Ac0%3Ad3)._ipp._tcp.local/

That's all.  And no, that's not the right printer.  That's the one
that has the right model number, but isn't *mine*.  I can only imagine
it's somewhere else on this floor, and that someone is very confused
upon seeing income tax forms coming out of it.


How do you know it it does not point to the right printer?


It's got that "db:c0:d3" suffix.  The printer with that suffix in CUPS
is the black hole where whatever I send doesn't get printed by my printer.
I assume it's another Canon LBP712Cdn somewhere else on the 10th floor,
or at least something claiming to be a Canon LBP712Cdn.

I still have no idea what the db:c0:d3 means.


Your machine has bullseye, we suppose? Give what you gat for

   lpstat -l -e


wooledg:~$ cat /etc/debian_version
11.6
wooledg:~$ lpstat -l -e
Canon_LBP712C_UFR_II_ permanent ipp://localhost/printers/Canon_LBP712C_UFR_II_ 
ipp://Canon%20LBP712Cdn%20(db%3Ac0%3Ad3)._ipp._tcp.local/
Canon_LBP712Cdn_db_c0_d3_ network none 
ipp://Canon%20LBP712Cdn%20(db%3Ac0%3Ad3)._ipp._tcp.local/
Cups_PDF_oc3261540276 permanent ipp://localhost/printers/Cups_PDF_oc3261540276 
file:///dev/null
hp_LaserJet_4250_621E13_ permanent 
ipp://localhost/printers/hp_LaserJet_4250_621E13_ 
implicitclass://hp_LaserJet_4250_621E13_/
HP_LaserJet_P3010_Series_0FCDD7_ permanent 
ipp://localhost/printers/HP_LaserJet_P3010_Series_0FCDD7_ 
implicitclass://HP_LaserJet_P3010_Series_0FCDD7_/
PostScript_oc3261540276 permanent 
ipp://localhost/printers/PostScript_oc3261540276 file:///dev/null


Is there any way I can tell CUPS "Please set up a queue for a printer
whose IP address is 10.76.172.100 even though you can't discover it with
your fancy tools"?


Yes, but it should not be needed and

Re: CUPS - how to match autodetected printers to physical ones

[Greg Wooledge]

On Thu, Feb 16, 2023 at 06:57:46PM +0200, Teemu Likonen wrote:
> Here is my version which I suggest turning into a shell alias, function
> or script:
> 
> avahi-browse -atrp 2>/dev/null | awk -F\; \
> '$1 == "=" { printf "%-23s %-26s %5s %s\n",$7,$8,$9,$5 }'
> 
> It should print lines like these:
> 
> SEC00159939FFD2.local   192.168.0.11 631 Internet Printer
> mithlond.local  192.168.0.2  631 Internet Printer

wooledg:~$ avahi-browse -atrp 2>/dev/null | awk -F\; '$1 == "=" { printf "%-23s 
%-26s %5s %s\n",$7,$8,$9,$5 }'
dhcp-10-76-173-174.local 10.76.173.174631 Internet Printer
wooledg.local   fe80::9e7b:efff:fe24:4213445 Microsoft Windows 
Network
wooledg.local   fe80::9e7b:efff:fe24:4213  0 Device Info
wooledg.local   10.76.172.189445 Microsoft Windows 
Network
wooledg.local   10.76.172.189  0 Device Info
wooledg.local   127.0.0.1445 Microsoft Windows 
Network
wooledg.local   127.0.0.1  0 Device Info
NPI0FCDD7.local 10.76.173.60 631 Internet Printer
NPI0FCDD7.local 10.76.173.60 515 UNIX Printer
NPI0FCDD7.local 10.76.173.60 631 Internet Printer
NPI0FCDD7.local 10.76.173.60 515 UNIX Printer
A09-LBT2-HPLJ4250-01.local 10.76.172.120631 Internet Printer
A09-LBT2-HPLJ4250-01.local 10.76.172.120515 UNIX Printer
dhcp-10-76-173-174.local 10.76.173.174515 UNIX Printer
dhcp-10-76-173-174.local 10.76.173.174 80 Web Site
dhcp-10-76-173-174.local 10.76.173.174   9100 PDL Printer
NPI0FCDD7.local 10.76.173.609100 PDL Printer
NPI0FCDD7.local 10.76.173.60  80 Web Site
NPI0FCDD7.local 10.76.173.60  21 FTP File Transfer
NPI0FCDD7.local 10.76.173.60  23 Telnet Remote Terminal
NPI0FCDD7.local 10.76.173.609100 PDL Printer
NPI0FCDD7.local 10.76.173.60  80 Web Site
NPI0FCDD7.local 10.76.173.60  21 FTP File Transfer
NPI0FCDD7.local 10.76.173.60  23 Telnet Remote Terminal
A09-LBT2-HPLJ4250-01.local 10.76.172.120   9100 PDL Printer
A09-LBT2-HPLJ4250-01.local 10.76.172.120 80 Web Site
A09-LBT2-HPLJ4250-01.local 10.76.172.120 21 FTP File Transfer
A09-LBT2-HPLJ4250-01.local 10.76.172.120 23 Telnet Remote 
Terminal

It does not report the printer at 10.76.172.100.  I imagine that it would
have reported it a year ago.  I don't know what changed.

> I would try to add manually one of these connection addresses:
> 
> http://10.76.172.100:631
> ipp://10.76.172.100:631

I can try that next time I'm physically there, usually once a week.

On Thu, Feb 16, 2023 at 06:54:18PM +, Brian wrote:
> On Thu 16 Feb 2023 at 10:41:33 -0500, Greg Wooledge wrote:
> 
> [...]
> 
> > 3) Also suggested: driverless
> >Here's what I get this year:
> > 
> >wooledg:~$ driverless
> >ipp://Canon%20LBP712Cdn%20(db%3Ac0%3Ad3)._ipp._tcp.local/
> > 
> >That's all.  And no, that's not the right printer.  That's the one
> >that has the right model number, but isn't *mine*.  I can only imagine
> >it's somewhere else on this floor, and that someone is very confused
> >upon seeing income tax forms coming out of it.
> 
> How do you know it it does not point to the right printer?

It's got that "db:c0:d3" suffix.  The printer with that suffix in CUPS
is the black hole where whatever I send doesn't get printed by my printer.
I assume it's another Canon LBP712Cdn somewhere else on the 10th floor,
or at least something claiming to be a Canon LBP712Cdn.

I still have no idea what the db:c0:d3 means.

> Your machine has bullseye, we suppose? Give what you gat for
> 
>   lpstat -l -e

wooledg:~$ cat /etc/debian_version 
11.6
wooledg:~$ lpstat -l -e
Canon_LBP712C_UFR_II_ permanent ipp://localhost/printers/Canon_LBP712C_UFR_II_ 
ipp://Canon%20LBP712Cdn%20(db%3Ac0%3Ad3)._ipp._tcp.local/
Canon_LBP712Cdn_db_c0_d3_ network none 
ipp://Canon%20LBP712Cdn%20(db%3Ac0%3Ad3)._ipp._tcp.local/
Cups_PDF_oc3261540276 permanent ipp://localhost/printers/Cups_PDF_oc3261540276 
file:///dev/null
hp_LaserJet_4250_621E13_ permanent 
ipp://localhost/printers/hp_LaserJet_4250_621E13_ 
implicitclass://hp_LaserJet_4250_621E13_/
HP_LaserJet_P3010_Series_0FCDD7_ permanent 
ipp://localhost/printers/HP_LaserJet_P3010_Series_0FCDD7_ 
implicitclass://HP_LaserJet_P3010_Series_0FCDD7_/
PostScript_oc3261540276 permanent 
ipp://localhost/printers/PostScript_oc3261540276 file:///dev/null

> > Is there any way I can tell CUPS "Please set up a queue for a printer
> > whose IP address is 10.76.172.100 even though you can't discover it with
> > your fancy tools"?
> 
> 

Re: CUPS - how to match autodetected printers to physical ones

[Brian]

On Thu 16 Feb 2023 at 11:27:25 -0800, Bob McGowan wrote:

>On 2/16/23 11:14 AM, Brian wrote:
> 
> On Thu 16 Feb 2023 at 11:52:21 -0500, Stefan Monnier wrote:
> 
> 
> [1]to...@tuxteam.de [2023-02-16 16:53:02] wrote:
> 
> Just for kicks: have you tried sending a PS (or *gasp* PDF) file
> down that alley (e.g. with socat)?
> 
> For That One Form in the Year this might be just sufficient...
> 
> Hint: start with a small one :)
> 
> I don't think "a small one" can be small enough in case it misfires.
> Instead, I usually make sure there's only 1 sheet of paper in the tray
> when I send the test (usually a sheet that I already used :-)
> 
> Producind a PDF with the line "This is a test" in it is
> incredibly easy. Jumping through hoops is not needed.
> 
> 
>However, the PDF file created (I used LibreOffice 'cause its fast and
>easy) was 7,335 characters long, according to 'wc', which also reported
>367 "words" and 139 "lines".
> 
>Given that a standard US letter size sheet (8.5 by 11 inches) has 66
>lines per page, that is just over 2 pages.
> 
>So putting only one used sheet of paper in the printer would save a
>couple of sheets of paper. ;)
> 
>Not much but why waste paper for a simple test?

I have no desire or intention to investigate how LibreOffice
deals with a single line text file converted to a PDF. This
works to not waste paper when fileout.pdf is printed:

 /usr/lib/cups/filter/texttopdf 1 1 1 1 1 filein.txt > fileout.pdf

-- 
Brian.

Re: CUPS - how to match autodetected printers to physical ones

[Bob McGowan]

  
  
On 2/16/23 11:14 AM, Brian wrote:


  On Thu 16 Feb 2023 at 11:52:21 -0500, Stefan Monnier wrote:


  
to...@tuxteam.de [2023-02-16 16:53:02] wrote:


  Just for kicks: have you tried sending a PS (or *gasp* PDF) file
down that alley (e.g. with socat)?

For That One Form in the Year this might be just sufficient...

Hint: start with a small one :)



I don't think "a small one" can be small enough in case it misfires.
Instead, I usually make sure there's only 1 sheet of paper in the tray
when I send the test (usually a sheet that I already used :-)

  
  
Producind a PDF with the line "This is a test" in it is
incredibly easy. Jumping through hoops is not needed.



However, the PDF file created (I used LibreOffice 'cause its fast
  and easy) was 7,335 characters long, according to 'wc', which also
  reported 367 "words" and 139 "lines".
Given that a standard US letter size sheet (8.5 by 11 inches) has
  66 lines per page, that is just over 2 pages.
So putting only one used sheet of paper in the printer would save
  a couple of sheets of paper. ;)
Not much but why waste paper for a simple test?

Bob

  

Re: CUPS - how to match autodetected printers to physical ones

[Brian]

On Thu 16 Feb 2023 at 11:52:21 -0500, Stefan Monnier wrote:

> to...@tuxteam.de [2023-02-16 16:53:02] wrote:
> > Just for kicks: have you tried sending a PS (or *gasp* PDF) file
> > down that alley (e.g. with socat)?
> >
> > For That One Form in the Year this might be just sufficient...
> >
> > Hint: start with a small one :)
> 
> I don't think "a small one" can be small enough in case it misfires.
> Instead, I usually make sure there's only 1 sheet of paper in the tray
> when I send the test (usually a sheet that I already used :-)

Producind a PDF with the line "This is a test" in it is
incredibly easy. Jumping through hoops is not needed.

-- 
Brian.

Re: CUPS - how to match autodetected printers to physical ones

[Brian]

On Thu 16 Feb 2023 at 10:41:33 -0500, Greg Wooledge wrote:

[...]

> 3) Also suggested: driverless
>Here's what I get this year:
> 
>wooledg:~$ driverless
>ipp://Canon%20LBP712Cdn%20(db%3Ac0%3Ad3)._ipp._tcp.local/
> 
>That's all.  And no, that's not the right printer.  That's the one
>that has the right model number, but isn't *mine*.  I can only imagine
>it's somewhere else on this floor, and that someone is very confused
>upon seeing income tax forms coming out of it.

How do you know it it does not point to the right printer?

> 4) Also mentioned: port 9100.
>For grins, I did "telnet 10.76.172.100 9100" and after that connected
>I typed "HELLO WORLD", then pressed Enter, then Ctrl-] q Enter to
>close the telnet session.
> 
>That actually printed the words HELLO WORLD on a sheet of paper.
> 
> So the printer WORKS.  It is ON THE NETWORK.  I can print TEXT to it
> using port 9100.

The printer understands text.

> What I CANNOT do is find it in CUPS.  Or avahi-browse, or driverless, or
> any of these other commands that are so allegedly wonderful.

Your machine has bullseye, we suppose? Give what you gat for

  lpstat -l -e

> Is there any way I can tell CUPS "Please set up a queue for a printer
> whose IP address is 10.76.172.100 even though you can't discover it with
> your fancy tools"?

Yes, but it should not be needed and involves guessing.(Please
try to avoid unhelpful, judgemental adjectives).

[...]

> My burning hatred of printers and this printing system remains unquenched.

Calm down! Understanding a situation (like the operation of a
shell script) requires being able to focus.

-- 
Brian.

Re: CUPS - how to match autodetected printers to physical ones

[tomas]

On Thu, Feb 16, 2023 at 11:52:21AM -0500, Stefan Monnier wrote:
> to...@tuxteam.de [2023-02-16 16:53:02] wrote:
> > Just for kicks: have you tried sending a PS (or *gasp* PDF) file
> > down that alley (e.g. with socat)?
> >
> > For That One Form in the Year this might be just sufficient...
> >
> > Hint: start with a small one :)
> 
> I don't think "a small one" can be small enough in case it misfires.
> Instead, I usually make sure there's only 1 sheet of paper in the tray
> when I send the test (usually a sheet that I already used :-)

:-)

-- 
t


signature.asc
Description: PGP signature

Re: CUPS - how to match autodetected printers to physical ones

[Teemu Likonen]

* 2023-02-16 10:41:33-0500, Greg Wooledge wrote:

> 1) Someone suggested: avahi-discover -r _print-caps._tcp
>When I tried it last year, it simply hung with no visible output
>until Ctrl-C'ed.

Here is my version which I suggest turning into a shell alias, function
or script:

avahi-browse -atrp 2>/dev/null | awk -F\; \
'$1 == "=" { printf "%-23s %-26s %5s %s\n",$7,$8,$9,$5 }'

It should print lines like these:

SEC00159939FFD2.local   192.168.0.11 631 Internet Printer
mithlond.local  192.168.0.2  631 Internet Printer

The SEC00159939FFD2.local is my printer. The printer gets its IP through
DHCP but I don't use the IP address anywhere, because the .local name
works automatically. Make sure to install (almost) all packages which
CUPS and Avahi recommend.

> Is there any way I can tell CUPS "Please set up a queue for a printer
> whose IP address is 10.76.172.100 even though you can't discover it with
> your fancy tools"?

I would try to add manually one of these connection addresses:

http://10.76.172.100:631
ipp://10.76.172.100:631

-- 
/// Teemu Likonen - .-.. https://www.iki.fi/tlikonen/
// OpenPGP: 6965F03973F0D4CA22B9410F0F2CAE0E07608462


signature.asc
Description: PGP signature

Re: CUPS - how to match autodetected printers to physical ones

[Stefan Monnier]

to...@tuxteam.de [2023-02-16 16:53:02] wrote:
> Just for kicks: have you tried sending a PS (or *gasp* PDF) file
> down that alley (e.g. with socat)?
>
> For That One Form in the Year this might be just sufficient...
>
> Hint: start with a small one :)

I don't think "a small one" can be small enough in case it misfires.
Instead, I usually make sure there's only 1 sheet of paper in the tray
when I send the test (usually a sheet that I already used :-)


Stefan

Re: CUPS - how to match autodetected printers to physical ones

[Fred]

On 2/16/23 08:41, Greg Wooledge wrote:

It's tax season again, so once again I am putting myself through the
utter hell that is attempting to print my city's Income Tax Forms.

(Yes, this is mandatory.  No, they do not accept electronic submissions.
You must use paper and ink.  Yes, they require you to print your own
forms.  No, they will not mail you a form.)

Whatever I managed to do last year... it's not working this year.  I can
only assume that my workplace's lovely IT department has taken even more
drastic steps in their eternal war against anything that isn't blessed
by Microsoft, and isn't under their control.

When I tried to print this year's tax form to my local printer, I learned
that the default print queue I had set up last year is no longer there.

This led to a complete rerun of everything from last year -- going up to
the printer, looking at the piece of paper attached to the front of it
which has the IP address (same one -- 10.76.172.100), attempting to
find a queue in CUPS which matches up with that, sending print jobs to
what *appears* to be the correct printer, having no paper come out, etc.

Eventually I unearthed this thread, which had some advice which worked
in the past.

It is not working today.

Here's a run-down:

1) Someone suggested: avahi-discover -r _print-caps._tcp
When I tried it last year, it simply hung with no visible output
until Ctrl-C'ed.

This year, I ran it while physically present in the workplace, so now
I know why it hangs.  It pops up an X11 window.  Only after you close
that X11 window does it print results on the terminal.

That's extremely difficult to detect or deal with when you're ssh-ing
in, running commands in a screen session.

2) Also suggested: avahi-browse -rt _ipp._tcp
This year, the output of that command no longer contains my printer's
IP address.  Last year, it did.  I have no idea why this has changed.

3) Also suggested: driverless
Here's what I get this year:

wooledg:~$ driverless
ipp://Canon%20LBP712Cdn%20(db%3Ac0%3Ad3)._ipp._tcp.local/

That's all.  And no, that's not the right printer.  That's the one
that has the right model number, but isn't *mine*.  I can only imagine
it's somewhere else on this floor, and that someone is very confused
upon seeing income tax forms coming out of it.

4) Also mentioned: port 9100.
For grins, I did "telnet 10.76.172.100 9100" and after that connected
I typed "HELLO WORLD", then pressed Enter, then Ctrl-] q Enter to
close the telnet session.

That actually printed the words HELLO WORLD on a sheet of paper.

So the printer WORKS.  It is ON THE NETWORK.  I can print TEXT to it
using port 9100.

What I CANNOT do is find it in CUPS.  Or avahi-browse, or driverless, or
any of these other commands that are so allegedly wonderful.

Is there any way I can tell CUPS "Please set up a queue for a printer
whose IP address is 10.76.172.100 even though you can't discover it with
your fancy tools"?

Or do I need to use a Windows PC/Laptop to print this stupid form?

Oh, and if it's any help, here's everything that's on the piece of paper
attached to the printer (I took a picture of it with a cell phone, and
carried the phone back to my desk so I can type it all out):

D#: D14841
P#:
IP: 10.76.172.100
Queue \\SPS\S010NEURD14841M
Model # Canon LBP712Cdn
Serial # NGDA008248
Bldg: S
Flr: 10
Zone: Main
Room: 007
Epic ID
Notes B9754

My burning hatred of printers and this printing system remains unquenched.


HI,

I use ftp to send postscript files to my Lexmark printer.  I am not sure 
cups is even installed.  You might also try netcat since you have the ip 
address of the printer.

Best regards,
Fred

Re: CUPS - how to match autodetected printers to physical ones

[tomas]

On Thu, Feb 16, 2023 at 10:41:33AM -0500, Greg Wooledge wrote:

[...]

> 4) Also mentioned: port 9100.
>For grins, I did "telnet 10.76.172.100 9100" and after that connected
>I typed "HELLO WORLD", then pressed Enter, then Ctrl-] q Enter to
>close the telnet session.
> 
>That actually printed the words HELLO WORLD on a sheet of paper.

\o/

Just for kicks: have you tried sending a PS (or *gasp* PDF) file
down that alley (e.g. with socat)?

For That One Form in the Year this might be just sufficient...

Hint: start with a small one :)

Cheers
-- 
t


signature.asc
Description: PGP signature

Re: CUPS - how to match autodetected printers to physical ones

[Greg Wooledge]

It's tax season again, so once again I am putting myself through the
utter hell that is attempting to print my city's Income Tax Forms.

(Yes, this is mandatory.  No, they do not accept electronic submissions.
You must use paper and ink.  Yes, they require you to print your own
forms.  No, they will not mail you a form.)

Whatever I managed to do last year... it's not working this year.  I can
only assume that my workplace's lovely IT department has taken even more
drastic steps in their eternal war against anything that isn't blessed
by Microsoft, and isn't under their control.

When I tried to print this year's tax form to my local printer, I learned
that the default print queue I had set up last year is no longer there.

This led to a complete rerun of everything from last year -- going up to
the printer, looking at the piece of paper attached to the front of it
which has the IP address (same one -- 10.76.172.100), attempting to
find a queue in CUPS which matches up with that, sending print jobs to
what *appears* to be the correct printer, having no paper come out, etc.

Eventually I unearthed this thread, which had some advice which worked
in the past.

It is not working today.

Here's a run-down:

1) Someone suggested: avahi-discover -r _print-caps._tcp
   When I tried it last year, it simply hung with no visible output
   until Ctrl-C'ed.

   This year, I ran it while physically present in the workplace, so now
   I know why it hangs.  It pops up an X11 window.  Only after you close
   that X11 window does it print results on the terminal.

   That's extremely difficult to detect or deal with when you're ssh-ing
   in, running commands in a screen session.

2) Also suggested: avahi-browse -rt _ipp._tcp
   This year, the output of that command no longer contains my printer's
   IP address.  Last year, it did.  I have no idea why this has changed.

3) Also suggested: driverless
   Here's what I get this year:

   wooledg:~$ driverless
   ipp://Canon%20LBP712Cdn%20(db%3Ac0%3Ad3)._ipp._tcp.local/

   That's all.  And no, that's not the right printer.  That's the one
   that has the right model number, but isn't *mine*.  I can only imagine
   it's somewhere else on this floor, and that someone is very confused
   upon seeing income tax forms coming out of it.

4) Also mentioned: port 9100.
   For grins, I did "telnet 10.76.172.100 9100" and after that connected
   I typed "HELLO WORLD", then pressed Enter, then Ctrl-] q Enter to
   close the telnet session.

   That actually printed the words HELLO WORLD on a sheet of paper.

So the printer WORKS.  It is ON THE NETWORK.  I can print TEXT to it
using port 9100.

What I CANNOT do is find it in CUPS.  Or avahi-browse, or driverless, or
any of these other commands that are so allegedly wonderful.

Is there any way I can tell CUPS "Please set up a queue for a printer
whose IP address is 10.76.172.100 even though you can't discover it with
your fancy tools"?

Or do I need to use a Windows PC/Laptop to print this stupid form?

Oh, and if it's any help, here's everything that's on the piece of paper
attached to the printer (I took a picture of it with a cell phone, and
carried the phone back to my desk so I can type it all out):

D#: D14841
P#:
IP: 10.76.172.100
Queue \\SPS\S010NEURD14841M
Model # Canon LBP712Cdn
Serial # NGDA008248
Bldg: S
Flr: 10
Zone: Main
Room: 007
Epic ID
Notes B9754

My burning hatred of printers and this printing system remains unquenched.

Re: CUPS - how to match autodetected printers to physical ones

[Gareth Evans]

On Mon 11 Apr 2022, at 19:23, Brian  wrote:
> On Mon 11 Apr 2022 at 13:55:03 -0400, Greg Wooledge wrote:
>
>> On Mon, Apr 11, 2022 at 06:47:59PM +0100, Brian wrote:
>> > BTW. I am interested in how using /usr/lib/cups/backend/snmp went.
>> > Its drawback is that not all printers provide an snmp service.
>> 
>> wooledg:~$ /usr/lib/cups/backend/snmp
>> network socket://10.76.172.120 "HP LaserJet 4250" "hp LaserJet 4250" 
>> "MFG:Hewlett-Packard;CMD:PJL,MLC,PCLXL,PCL,PJL,POSTSCRIPT;1284.4DL:4d,4e,1;MDL:hp
>>  LaserJet 4250;CLS:PRINTER;DES:Hewlett-Packard LaserJet 4250;" "W01-0224"
>> network socket://10.76.172.88 "HP LaserJet 4100 Series" "HP LaserJet 4100 
>> Series" "MFG:Hewlett-Packard;CMD:PJL,MLC,PCL,POSTSCRIPT,PCLXL,PJL;MDL:HP 
>> LaserJet 4100 Series ;CLS:PRINTER;DES:Hewlett-Packard LaserJet 4100 Series;" 
>> ""
>> network socket://10.76.173.60:9100 "HP LaserJet P3010 Series" "HP LaserJet 
>> P3010 Series" 
>> "MFG:Hewlett-Packard;CMD:PJL,BIDI-ECP,PJL,POSTSCRIPT,PDF,PCLXL,PCL;MDL:HP 
>> LaserJet P3010 Series;CLS:PRINTER;DES:Hewlett-Packard LaserJet P3010 
>> Series;" ""
>> 
>> Looks like that doesn't contain anything for the Canon printers.
>
> Although used by other vendors, a socket://... URI is really an HP
> thing, used by JetDirect appliances, so not surprising. Anyway, this
> very useful info of yours would prompt me to discard advising the use
> of snmp to match IP address with printer model. We are back to
> avahi-browse.
>
> I appreciate you print to that printer infrequently but would suggest a
> manually set up queue may suit you.
>
> Execute
>
>   driverless
>
> to get its URI. (I am sure you can sort out which one it is).
>
> Then
>
>   lpadmin -p SENSIBLE_PRINTER_NAME -L MYOFFICE -v URI -E -m everywhere
>
> -- 
> Brian.


I've been searching for documentation on CUPS "implicitclass" but can't find 
much.

I did find this:

'CUPS can automatically merge multiple identical network printers into 
"implicit classes". This allows clients to send jobs to the implicit class and 
have them print on the first available printer or server.' [though the doc 
predates CUPS driverless printing by some margin]
https://www.cups.org/test/testfile.pdf (p4)

The above is similar (though possibly quite different) to
https://opensource.apple.com/source/cups/cups-87/doc/sam.shtml#PRINTER_CLASSES
(2nd para under 'The Basics')

Assuming implicitclass is the mechanism of first resort in auto-detection (my 
own setup suggests so), does anyone know if this means that, with multiple 
devices of the same type, there's no guarantee from which device printing from 
the same queue will emerge, or are implicit classes resulting from 
auto-detection implemented as implicit classes of one?

Thanks,
Gareth

Re: CUPS - how to match autodetected printers to physical ones

[Brian]

On Mon 11 Apr 2022 at 13:55:03 -0400, Greg Wooledge wrote:

> On Mon, Apr 11, 2022 at 06:47:59PM +0100, Brian wrote:
> > BTW. I am interested in how using /usr/lib/cups/backend/snmp went.
> > Its drawback is that not all printers provide an snmp service.
> 
> wooledg:~$ /usr/lib/cups/backend/snmp
> network socket://10.76.172.120 "HP LaserJet 4250" "hp LaserJet 4250" 
> "MFG:Hewlett-Packard;CMD:PJL,MLC,PCLXL,PCL,PJL,POSTSCRIPT;1284.4DL:4d,4e,1;MDL:hp
>  LaserJet 4250;CLS:PRINTER;DES:Hewlett-Packard LaserJet 4250;" "W01-0224"
> network socket://10.76.172.88 "HP LaserJet 4100 Series" "HP LaserJet 4100 
> Series" "MFG:Hewlett-Packard;CMD:PJL,MLC,PCL,POSTSCRIPT,PCLXL,PJL;MDL:HP 
> LaserJet 4100 Series ;CLS:PRINTER;DES:Hewlett-Packard LaserJet 4100 Series;" 
> ""
> network socket://10.76.173.60:9100 "HP LaserJet P3010 Series" "HP LaserJet 
> P3010 Series" 
> "MFG:Hewlett-Packard;CMD:PJL,BIDI-ECP,PJL,POSTSCRIPT,PDF,PCLXL,PCL;MDL:HP 
> LaserJet P3010 Series;CLS:PRINTER;DES:Hewlett-Packard LaserJet P3010 Series;" 
> ""
> 
> Looks like that doesn't contain anything for the Canon printers.

Although used by other vendors, a socket://... URI is really an HP
thing, used by JetDirect appliances, so not surprising. Anyway, this
very useful info of yours would prompt me to discard advising the use
of snmp to match IP address with printer model. We are back to
avahi-browse.

I appreciate you print to that printer infrequently but would suggest a
manually set up queue may suit you.

Execute

  driverless

to get its URI. (I am sure you can sort out which one it is).

Then

  lpadmin -p SENSIBLE_PRINTER_NAME -L MYOFFICE -v URI -E -m everywhere

-- 
Brian.

Re: CUPS - how to match autodetected printers to physical ones

[Greg Wooledge]

On Mon, Apr 11, 2022 at 06:47:59PM +0100, Brian wrote:
> BTW. I am interested in how using /usr/lib/cups/backend/snmp went.
> Its drawback is that not all printers provide an snmp service.

wooledg:~$ /usr/lib/cups/backend/snmp
network socket://10.76.172.120 "HP LaserJet 4250" "hp LaserJet 4250" 
"MFG:Hewlett-Packard;CMD:PJL,MLC,PCLXL,PCL,PJL,POSTSCRIPT;1284.4DL:4d,4e,1;MDL:hp
 LaserJet 4250;CLS:PRINTER;DES:Hewlett-Packard LaserJet 4250;" "W01-0224"
network socket://10.76.172.88 "HP LaserJet 4100 Series" "HP LaserJet 4100 
Series" "MFG:Hewlett-Packard;CMD:PJL,MLC,PCL,POSTSCRIPT,PCLXL,PJL;MDL:HP 
LaserJet 4100 Series ;CLS:PRINTER;DES:Hewlett-Packard LaserJet 4100 Series;" ""
network socket://10.76.173.60:9100 "HP LaserJet P3010 Series" "HP LaserJet 
P3010 Series" 
"MFG:Hewlett-Packard;CMD:PJL,BIDI-ECP,PJL,POSTSCRIPT,PDF,PCLXL,PCL;MDL:HP 
LaserJet P3010 Series;CLS:PRINTER;DES:Hewlett-Packard LaserJet P3010 Series;" ""

Looks like that doesn't contain anything for the Canon printers.

Re: CUPS - how to match autodetected printers to physical ones

[Brian]

On Mon 11 Apr 2022 at 13:04:12 -0400, Greg Wooledge wrote:

> On Mon, Apr 11, 2022 at 05:47:07PM +0100, Brian wrote:
> > What does
> > 
> >avahi-browse -rt _ipp._tcp | grep -B3 port
> > 
> > give for this device?
> 
> =   eno1 IPv4 Canon LBP351dn (f9:7a:4a) Internet Printer  
>local
>hostname = [dhcp-10-76-172-100.local]
>address = [10.76.172.100]
>port = [631]
> 
> And for completeness:
> 
> wooledg:~$ avahi-resolve -n dhcp-10-76-172-100.local
> dhcp-10-76-172-100.local  10.76.172.100

Thanks. I completly forgot: CUPS constructs a destination from a
printer's Service (Bonjour) Name by replacing a dash (-) with an
underscore (_). It then adds an underscore (_) to the end. (It
has stopped doing the latter in the most recent version, I thnk).

I will scub the third method. It is too involved to explain how
to reverse what is in the implicitclass URI just for resolving.
avahi-browse seems the way to go for your purpose.

BTW. I am interested in how using /usr/lib/cups/backend/snmp went.
Its drawback is that not all printers provide an snmp service.

-- 
Brian.

Re: CUPS - how to match autodetected printers to physical ones

[Greg Wooledge]

On Mon, Apr 11, 2022 at 05:47:07PM +0100, Brian wrote:
> What does
> 
>avahi-browse -rt _ipp._tcp | grep -B3 port
> 
> give for this device?

=   eno1 IPv4 Canon LBP351dn (f9:7a:4a) Internet Printer
 local
   hostname = [dhcp-10-76-172-100.local]
   address = [10.76.172.100]
   port = [631]

And for completeness:

wooledg:~$ avahi-resolve -n dhcp-10-76-172-100.local
dhcp-10-76-172-100.local10.76.172.100

Re: CUPS - how to match autodetected printers to physical ones

[Brian]

On Mon 11 Apr 2022 at 11:53:38 -0400, Greg Wooledge wrote:

> On Mon, Apr 11, 2022 at 03:40:12PM +0100, Brian wrote:
> > A third way forward:
> > 
> > "implicitclass://Canon_LBP351dn_f9_7a_4a_/" is the URI for this printer.
> > Canon_LBP351dn_f9_7a_4a_ is the printer's Service Name. 
> > 
> >   avahi-resolve -n Canon_LBP351dn_f9_7a_4a_.local
> > 
> > should give the IP address of the host.
> 
> wooledg:~$ time avahi-resolve -n Canon_LBP351dn_f9_7a_4a_.local
> Failed to resolve host name 'Canon_LBP351dn_f9_7a_4a_.local': Timeout reached
> real 5.014  user 0.004  sys 0.004

What does

   avahi-browse -rt _ipp._tcp | grep -B3 port

give for this device?

-- 
Brian. 

Re: CUPS - how to match autodetected printers to physical ones

[Greg Wooledge]

On Mon, Apr 11, 2022 at 03:40:12PM +0100, Brian wrote:
> A third way forward:
> 
> "implicitclass://Canon_LBP351dn_f9_7a_4a_/" is the URI for this printer.
> Canon_LBP351dn_f9_7a_4a_ is the printer's Service Name. 
> 
>   avahi-resolve -n Canon_LBP351dn_f9_7a_4a_.local
> 
> should give the IP address of the host.

wooledg:~$ time avahi-resolve -n Canon_LBP351dn_f9_7a_4a_.local
Failed to resolve host name 'Canon_LBP351dn_f9_7a_4a_.local': Timeout reached
real 5.014  user 0.004  sys 0.004

Re: CUPS - how to match autodetected printers to physical ones

[Brian]

On Fri 08 Apr 2022 at 13:22:26 -0400, Greg Wooledge wrote:

> On Fri, Apr 08, 2022 at 06:03:47PM +0100, Tixy wrote:
> > On Fri, 2022-04-08 at 17:59 +0100, Tixy wrote:
> > > On Fri, 2022-04-08 at 12:10 -0400, Greg Wooledge wrote:
> > > > Unfortunately, I was not able to find ANY way to determine the IP
> > > > addresses of the autodetected printers that were presented to me.
> > > 
> > > If I go to http://localhost:631/printers/
> > 
> > I should say I got to that URL from the CUPs interface at
> > http://localhost:631/ then clicking the 'Admininitation' tab at the top
> > followed by the 'Manage Printers' button on the page that showed.
> 
> Here is what I have on that page:
> 
> =
> Showing 7 of 7 printers.
> 
> Queue NameDescription LocationMake and Model  Status
> Canon_LBP351dn_f9_7a_4a_  CNLBP712C CNLBP712C, 
> driverless, cups-filters 1.28.7Idle
> Canon_LBP712Cdn_db_c0_d3_ Canon_LBP712Cdn_db_c0_d3_   
> CNLBP712C CNLBP712C, driverless, cups-filters 1.28.7Idle
> Cups_PDF_oc3261540276 Cups_PDF_oc3261540276   Local Raw Printer   
> Paused
> HP_LaserJet_4100_Series_0001E6A68D3D_ HP_LaserJet_4100_Series_0001E6A68D3D_   
> HP LaserJet 4100 Series , driverless, cups-filters 1.28.7   Idle
> hp_LaserJet_4250_621E13_  hp_LaserJet_4250_621E13_hp 
> LaserJet 4250, driverless, cups-filters 1.28.7   Idle
> HP_LaserJet_P3010_Series_0FCDD7_  HP_LaserJet_P3010_Series_0FCDD7_
> HP LaserJet P3010 Series, driverless, cups-filters 1.28.7   Idle
> PostScript_oc3261540276   PostScript_oc3261540276 Local Raw 
> Printer   Paused
> =
> 
> Of course it looks like crap when I just paste the text from the web
> page into an email.  But if you ignore the horrible formatting, you
> can see there are NO IP addresses here.

Looks are the least of the deficiencies here. The Queue Name appears
to be being used for the printer Descriptiom and the Location column
is empty. Neither column provides adequate, useful information.
> 
> If I go to a single printer's page, I get text like this:
> 
> =
> Canon_LBP351dn_f9_7a_4a_
> Canon_LBP351dn_f9_7a_4a_ (Idle, Accepting Jobs, Not Shared, Server Default)
> 
> Maintenance
>  
> Administration
> Description:  
> Location: 
> Driver:   CNLBP712C CNLBP712C, driverless, cups-filters 1.28.7 (color, 
> 2-sided printing)
> Connection:   implicitclass://Canon_LBP351dn_f9_7a_4a_/
> Defaults: job-sheets=none, none media=na_letter_8.5x11in sides=one-sided
> =
> 
> Maybe I need to amend the question to "How is one supposed to figure out
> which autodetected printer is which IN A CORPORATE NETWORK OF UNKNOWN
> PROVENANCE?"  I don't know what I need to say to convey to you that
> my workplace's network DOES NOT work like what you see on yours.
> 
> Looking at the stuff that I pasted here, how am I supposed to know whether
> this corresponds to the physical printer with IP address 10.76.172.100?

A third way forward:

"implicitclass://Canon_LBP351dn_f9_7a_4a_/" is the URI for this printer.
Canon_LBP351dn_f9_7a_4a_ is the printer's Service Name. 

  avahi-resolve -n Canon_LBP351dn_f9_7a_4a_.local

should give the IP address of the host.

-- 
Brian.

Re: CUPS - how to match autodetected printers to physical ones

[gene heskett]

On Sunday, 10 April 2022 09:54:34 EDT Brian wrote:
> On Sun 10 Apr 2022 at 09:19:43 -0400, gene heskett wrote:
> > On Sunday, 10 April 2022 08:40:29 EDT Brian wrote:
> > >   /usr/lib/cups/backend/snmp
> > 
> > The only machine I have here that has that file installed, an rpi4,
> > does not expose the printers address, only:
> > pi@rpi4:~ $ sudo  /usr/lib/cups/backend/snmp
> > network lpd://BRN30055C8A2DC8/BINARY_P1 "Brother MFC-J6920DW"
> > "Brother
> > MFC-J6920DW" "MFG:Brother;CMD:HBP,BRPJL,URF;MDL:MFC-
> > J6920DW;CLS:PRINTER;CID:Brother IJ
> > Type3;URF:SRGB24,W8,CP1,IS1-13,MT1-8-11,OB9,PQ4-5,RS200-300,OFU0,V1.2
> > ,DM4;" "coyote.coyote.den"
> > 
> > The only location identifier is the resolved "coyote.coyote.den"
> > which is this machine.
> > 
> > None of the buster boxes have it, so they all report file not found.
> > BUT they were all installed from a buster respin by the linuxcnc
> > folks. But geany the editor, can drive that printer from any
> > locatiom my cat5 cable reaches.
> > 
> > And I just checked because there is a 2nd printer, another brother
> > HL2320 B&W duplex capable laser, on this machine, and although the
> > above command only shows one printer, I can feed both printers from
> > geany running on any machine, all 6 of the profiles I have defined
> > are available for geany to use as an output device. I suspect the
> > laser doesn't do snmp, its a $120 printer. Probably some brother
> > version of plc5 since its running on brothers own drivers.
> 
> Thank you, Gene. Your investigations are vey useful and point to my
> forgetfulness.
> 
Your forgetfullness Brian? I'm 87, so it is std proceedure for me to 
either repeat the experiment or spend a couple weeks sorting thru the 
sometimmes decades old stuff in my mental attic, and FWIW I also claim 
any references to oldtimers too. Surely you aren't that ancient. ;-)

> The snmp backend is not installed in the location I gave but has
> to be moved there. Do either
> 
>   mv /usr/lib/cups/backend-available/snmp /usr/lib/cups/backend/snmp
> 
> or
> 
>   dpkg-reconfigure cups
> 
> --
> Brian.
> 
> .


Cheers, Gene Heskett.
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis

Re: CUPS - how to match autodetected printers to physical ones

[Brian]

On Sun 10 Apr 2022 at 21:29:30 +0200, to...@tuxteam.de wrote:

> On Sun, Apr 10, 2022 at 08:19:52PM +0100, Brian wrote:
> 
> [...]
> 
> > > forbidden of trying to do network scans, but the sysadmin wants to
> > > know. I can't blame him (I'm on speaking terms with him ;-)
> > 
> > Not forbidden?
> > 
> >   I know a corporate network or two which would get you disconnected
> >   if you do that :
> > 
> > Disconnected? That doesn't sound permissive.
> 
> In my book, forbidden would mean *you* get disconnected from the
> institution. Your machine disconnected from the network and having
> to do "pretty please" to the admin... I'd say "fair enough". Wouldn't
> be *my* policy, but I can live with that.

I wouldn't say "fair enough", but the dictatorial and irrational
decisions of sysadmins might oblige me to live with that. Just
as I live with the agents of survellance capitalism.
 
> > > > I was once reprimamaned by Amazon for nmapping my own network. That's
> > > > what I call real devotion to stamping out network discovery.
> > > 
> > > Now now. No reprimands. The firewall notices and disables that one port,
> > > That's all.
> > 
> > I was controlled by an inaminte agency? Is that any better than being
> > controlled by an agent of survellance capitalism? Either way, my actions
> > are monitored. My communications are intercepted and censorship applied.
> 
> Could be worse, believe me. At a lower protocol level [1] it's even part
> of the protocol, i.e. mandatory :)

OK, I know when I am beaten into the ground. :)

-- 
Brian.

Re: CUPS - how to match autodetected printers to physical ones

[tomas]

On Sun, Apr 10, 2022 at 08:19:52PM +0100, Brian wrote:

[...]

> > forbidden of trying to do network scans, but the sysadmin wants to
> > know. I can't blame him (I'm on speaking terms with him ;-)
> 
> Not forbidden?
> 
>   I know a corporate network or two which would get you disconnected
>   if you do that :
> 
> Disconnected? That doesn't sound permissive.

In my book, forbidden would mean *you* get disconnected from the
institution. Your machine disconnected from the network and having
to do "pretty please" to the admin... I'd say "fair enough". Wouldn't
be *my* policy, but I can live with that.

> > > I was once reprimamaned by Amazon for nmapping my own network. That's
> > > what I call real devotion to stamping out network discovery.
> > 
> > Now now. No reprimands. The firewall notices and disables that one port,
> > That's all.
> 
> I was controlled by an inaminte agency? Is that any better than being
> controlled by an agent of survellance capitalism? Either way, my actions
> are monitored. My communications are intercepted and censorship applied.

Could be worse, believe me. At a lower protocol level [1] it's even part
of the protocol, i.e. mandatory :)

Cheers
[1] https://en.wikipedia.org/wiki/Ethernet#Jabber
-- 
t


signature.asc
Description: PGP signature

Re: CUPS - how to match autodetected printers to physical ones

[Brian]

On Sun 10 Apr 2022 at 20:39:15 +0200, to...@tuxteam.de wrote:

> On Sun, Apr 10, 2022 at 06:47:36PM +0100, Brian wrote:
> > On Sun 10 Apr 2022 at 15:40:28 +0200, to...@tuxteam.de wrote:
> > 
> > > On Sun, Apr 10, 2022 at 01:40:29PM +0100, Brian wrote:
> > > 
> > > [...]
> > > 
> > > > Many printers provide an snmp (Simple Network Management Protocol)
> > > > service on port 9100. Check with
> > > > 
> > > >   nmap 10.76.172.100
> > > 
> > > I know a corporate network or two which would get you disconnected
> > > if you do that :)
> > > 
> > > Then you've got to go to the firewall admin and beg for being reconnected.
> > > So if you try it, first make sure you are on speaking terms with the
> > > network/firewall admins (a good idea, regardless...)
> > 
> > Strange world we live in! One looks at a shop window and the heavy mob
> > appear to harass you. Survellance capitalism in action? Or the sysadmin
> > is so unsure of the network security in place that it requires drastic
> > and immediate action to prevent a peep at services being offered? :)
> 
> No. The sysadmin has seen folks running around with Kali Linux USB
> sticks and has decided to play safe rather than sorry. Folks are not

"safe rather than sorry"? We see the result of that strategy in Europe
today. The sysadmin has overreacted, presumably because he has little
faith in the security of the network he has devised. How would he react
if he saw folks running around with with Windows USB sticks? :)

> forbidden of trying to do network scans, but the sysadmin wants to
> know. I can't blame him (I'm on speaking terms with him ;-)

Not forbidden?

  I know a corporate network or two which would get you disconnected
  if you do that :

Disconnected? That doesn't sound permissive.

> > I was once reprimamaned by Amazon for nmapping my own network. That's
> > what I call real devotion to stamping out network discovery.
> 
> Now now. No reprimands. The firewall notices and disables that one port,
> That's all.

I was controlled by an inaminte agency? Is that any better than being
controlled by an agent of survellance capitalism? Either way, my actions
are monitored. My communications are intercepted and censorship applied.

-- 
Brian.

-- 
Brian.

Re: CUPS - how to match autodetected printers to physical ones

[The Wanderer]

On 2022-04-10 at 14:25, Brian wrote:

> On Sun 10 Apr 2022 at 08:52:09 -0400, The Wanderer wrote:
> 
>> On 2022-04-10 at 08:38, Brian wrote:
> 
> [...]
> 
>>> The CUPS web interface is not designed to show the IP address but
>>> to display the URI.
>> 
>> This, I think, is exactly the detail that's being complained of. If
>> CUPS knows the IP address, it should be possible to get CUPS to
>> reveal that IP address.
>> 
>> If on the other hand CUPS *doesn't* know the IP address, but only
>> the hostname et cetera (because that's part of the URI, and CUPS
>> only knows/stores the URI), then that might be reasonable.
> 
> CUPS uses the standard networking APIs (getaddrinfo, for example)
> for resolving DNS names to get IP addresses, just like every other
> network service on Linux. CUPS rolling its own DNS resolver would
> cause problems on systems with working resolvers. Why reinvent the
> wheel?

I'm not suggesting that CUPS roll its own DNS resolver.

I'm just suggesting (or, rather, was just assuming) that after having
first learned the IP address during the discovery process, which
probably involves using an external DNS resolver (whether automated or
in the form of sysadmin entering IP address manually), it would cache
that IP address and make use of that cached value rather than repeating
the - presumably relatively expensive - discovery lookup every time.

This was based, at least in part, on the expectation that there
would/will not be DNS lookup for the printer's IP address from its
hostname, since I have rarely if ever seen a network where such lookup
was functioning (never mind one where the printer's hostname was
reliably meaningful or discoverable by any other means than connecting
to it by IP address and asking).

If that expectation was out of sync with reality, then so be it.

> Basically, CUPS leaves it to libnss-mdns. Why should it have any
> record of an IP address when it can easily ask libnss-mdns? We do the
> same with avahi-browse.

Because the lookup will be more expensive than connecting to the IP
address, which is unlikely to have changed - and if it *has* changed,
you've got little or no way of telling whether or not the printer you're
connecting to now is the same one as used to be at the previously-known
address.

>> (My previous comments were based on the assumption that all 
>> communication with the printer would be done based on IP address,
>> rather than on symbolic name and on connect-time resolution. That
>> may in turn be based on my experience in the Windows world, where
>> printer hostnames and DNS lookup are in my experience wildly
>> unreliable and as a consequence are very rarely used; I reflexively
>> expect that the parts of a system which communicate with a printer
>> will always know it primarily, if not exclusively, by its IP
>> address.)
> 
> Of corse the IP address is needed, but not by the user. The user is 
> better served by having the queue name matching the printer.

That depends on what information the user is going to be able to access
about the printer.

I have frequently seen printers which have a front-panel display that
will show the IP address.

I have never, that I recall, seen a printer which has a display that
will readily show the queue name, or the hostname, or any other
seemingly-relevant information about the printer's identity. (Besides
the model, which tends to also be displayed as part of the printer's
physical shell.)

In the case which started this thread, the user had the printer's IP
address (via a label which, I imagine, stood in the stead of such a
display; we also sometimes apply such labels in case the printer loses
its IP address in a power outage and has to have it re-applied), but did
not have the queue name.

Whether or not the queue name matches the printer is irrelevant when the
queue name is not what the user can get from the printer itself.

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man. -- George Bernard Shaw



signature.asc
Description: OpenPGP digital signature

Re: CUPS - how to match autodetected printers to physical ones

[tomas]

On Sun, Apr 10, 2022 at 06:47:36PM +0100, Brian wrote:
> On Sun 10 Apr 2022 at 15:40:28 +0200, to...@tuxteam.de wrote:
> 
> > On Sun, Apr 10, 2022 at 01:40:29PM +0100, Brian wrote:
> > 
> > [...]
> > 
> > > Many printers provide an snmp (Simple Network Management Protocol)
> > > service on port 9100. Check with
> > > 
> > >   nmap 10.76.172.100
> > 
> > I know a corporate network or two which would get you disconnected
> > if you do that :)
> > 
> > Then you've got to go to the firewall admin and beg for being reconnected.
> > So if you try it, first make sure you are on speaking terms with the
> > network/firewall admins (a good idea, regardless...)
> 
> Strange world we live in! One looks at a shop window and the heavy mob
> appear to harass you. Survellance capitalism in action? Or the sysadmin
> is so unsure of the network security in place that it requires drastic
> and immediate action to prevent a peep at services being offered? :)

No. The sysadmin has seen folks running around with Kali Linux USB
sticks and has decided to play safe rather than sorry. Folks are not
forbidden of trying to do network scans, but the sysadmin wants to
know. I can't blame him (I'm on speaking terms with him ;-)

> I was once reprimamaned by Amazon for nmapping my own network. That's
> what I call real devotion to stamping out network discovery.

Now now. No reprimands. The firewall notices and disables that one port,
That's all.

Cheers
-- 
t


signature.asc
Description: PGP signature

Re: CUPS - how to match autodetected printers to physical ones

[Brian]

On Sun 10 Apr 2022 at 08:52:09 -0400, The Wanderer wrote:

> On 2022-04-10 at 08:38, Brian wrote:

[...]
 
> > The CUPS web interface is not designed to show the IP address but to 
> > display the URI.
> 
> This, I think, is exactly the detail that's being complained of. If CUPS
> knows the IP address, it should be possible to get CUPS to reveal that
> IP address.
> 
> If on the other hand CUPS *doesn't* know the IP address, but only the
> hostname et cetera (because that's part of the URI, and CUPS only
> knows/stores the URI), then that might be reasonable.

CUPS uses the standard networking APIs (getaddrinfo, for example) for
resolving DNS names to get IP addresses, just like every other network
service on Linux. CUPS rolling its own DNS resolver would cause problems
on systems with working resolvers. Why reinvent the wheel?

Basically, CUPS leaves it to libnss-mdns. Why should it have any record
of an IP address when it can easily ask libnss-mdns? We do the same with
avahi-browse.

> (My previous comments were based on the assumption that all
> communication with the printer would be done based on IP address, rather
> than on symbolic name and on connect-time resolution. That may in turn
> be based on my experience in the Windows world, where printer hostnames
> and DNS lookup are in my experience wildly unreliable and as a
> consequence are very rarely used; I reflexively expect that the parts of
> a system which communicate with a printer will always know it primarily,
> if not exclusively, by its IP address.)

Of corse the IP address is needed, but not by the user. The user is
better served by having the queue name matching the printer.

-- 
Brian.

Re: CUPS - how to match autodetected printers to physical ones

[Brian]

On Sun 10 Apr 2022 at 15:40:28 +0200, to...@tuxteam.de wrote:

> On Sun, Apr 10, 2022 at 01:40:29PM +0100, Brian wrote:
> 
> [...]
> 
> > Many printers provide an snmp (Simple Network Management Protocol)
> > service on port 9100. Check with
> > 
> >   nmap 10.76.172.100
> 
> I know a corporate network or two which would get you disconnected
> if you do that :)
> 
> Then you've got to go to the firewall admin and beg for being reconnected.
> So if you try it, first make sure you are on speaking terms with the
> network/firewall admins (a good idea, regardless...)

Strange world we live in! One looks at a shop window and the heavy mob
appear to harass you. Survellance capitalism in action? Or the sysadmin
is so unsure of the network security in place that it requires drastic
and immediate action to prevent a peep at services being offered? :)

I was once reprimamaned by Amazon for nmapping my own network. That's
what I call real devotion to stamping out network discovery.

-- 
Brian.

Re: CUPS - how to match autodetected printers to physical ones

[Brian]

On Sun 10 Apr 2022 at 09:31:59 -0400, gene heskett wrote:

> On Sunday, 10 April 2022 08:54:07 EDT Brian wrote:
> > On Sun 10 Apr 2022 at 05:46:35 -0400, gene heskett wrote:
> > 
> > [...]
> > 
> > > This, FWIW, has nothing to do with cups and printer sharing, cups
> > > does
> > > its own advertising. All printers here are attached to this machine,
> > > marked as shareable and I can put stuff on their output trays from
> > > any
> > > machine including the rpi4 on my local network.
> > 
> > Indeed, CUPS does do its own advertising of print queue and uses
> > mDNS/DNS-SD. That is its *only* technique it has available for
> > sharing the queues.
> > 
> > mDNS/DNS-SD requires avahi-daemon to be active. Without it there
> > isn't any sharing and advertising.
> > 
> > So, I do not understand "...has nothing to do with...".
> > 
> The avahi-daemon has either been removed by rm. or by chmod -x on all 
> machines here, yet cups shared printers (plural) can use those shared 
> printers just as if they were plugged into that machine. So IMO removing 
> or disabling avahi-daemon has nothing to do with cups sharing.
> You are saying it won't work, but it does here. What else is there except 
> cups.

You can print from an rpi4 to a printer attached to another machine on
the network. There are only two ways this can happen:

* The rpi4 knows about the print server via mDNS/DNS-SD.
* There is a manual queue set up on the rpi4.

Only you can decide which it is.

-- 
Brian.

Re: CUPS - how to match autodetected printers to physical ones

[Brian]

On Sun 10 Apr 2022 at 10:05:09 -0400, The Wanderer wrote:

> On 2022-04-10 at 09:54, Brian wrote:
> 
> > The snmp backend is not installed in the location I gave but has
> > to be moved there. Do either
> > 
> >   mv /usr/lib/cups/backend-available/snmp /usr/lib/cups/backend/snmp
> > 
> > or
> > 
> >   dpkg-reconfigure cups
> 
> I've never taken specific action in either of these directions, but on
> my machine, this file exists in both of those locations. I suspect that
> they're actually hardlinked together.
> 
> I imagine that this is probably the result of my choosing a particular
> option when configuring CUPS in the first place, but I have no
> recollection of what option that might have been, nor even specifically
> of having been given any CUPS-related prompts when installing this system.
> 
> The point of which is: it's possible that the default for this might
> actually now be to have this enabled.

TBH, I am not in the mood for deciphering postinst files for cups and
cups-daemon. If the snmp backend file is not where it is on ny stable
and unstable machines, it is easy enough to adjust.

OTOH, reports of the technique I suggested are more than welcome.

-- 
Brian.

Re: CUPS - how to match autodetected printers to physical ones

[The Wanderer]

On 2022-04-10 at 09:54, Brian wrote:

> The snmp backend is not installed in the location I gave but has
> to be moved there. Do either
> 
>   mv /usr/lib/cups/backend-available/snmp /usr/lib/cups/backend/snmp
> 
> or
> 
>   dpkg-reconfigure cups

I've never taken specific action in either of these directions, but on
my machine, this file exists in both of those locations. I suspect that
they're actually hardlinked together.

I imagine that this is probably the result of my choosing a particular
option when configuring CUPS in the first place, but I have no
recollection of what option that might have been, nor even specifically
of having been given any CUPS-related prompts when installing this system.

The point of which is: it's possible that the default for this might
actually now be to have this enabled.

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man. -- George Bernard Shaw



signature.asc
Description: OpenPGP digital signature

Re: CUPS - how to match autodetected printers to physical ones

[Brian]

On Sun 10 Apr 2022 at 09:19:43 -0400, gene heskett wrote:

> On Sunday, 10 April 2022 08:40:29 EDT Brian wrote:
> >   /usr/lib/cups/backend/snmp
> The only machine I have here that has that file installed, an rpi4, does 
> not expose the printers address, only:
> pi@rpi4:~ $ sudo  /usr/lib/cups/backend/snmp
> network lpd://BRN30055C8A2DC8/BINARY_P1 "Brother MFC-J6920DW" "Brother 
> MFC-J6920DW" "MFG:Brother;CMD:HBP,BRPJL,URF;MDL:MFC-
> J6920DW;CLS:PRINTER;CID:Brother IJ 
> Type3;URF:SRGB24,W8,CP1,IS1-13,MT1-8-11,OB9,PQ4-5,RS200-300,OFU0,V1.2,DM4;" 
> "coyote.coyote.den"
> 
> The only location identifier is the resolved "coyote.coyote.den" which is 
> this machine.
> 
> None of the buster boxes have it, so they all report file not found. BUT 
> they were all installed from a buster respin by the linuxcnc folks. But 
> geany the editor, can drive that printer from any locatiom my cat5 cable 
> reaches.
> 
> And I just checked because there is a 2nd printer, another brother HL2320 
> B&W duplex capable laser, on this machine, and although the above command 
> only shows one printer, I can feed both printers from geany running on 
> any machine, all 6 of the profiles I have defined are available for geany 
> to use as an output device. I suspect the laser doesn't do snmp, its a 
> $120 printer. Probably some brother version of plc5 since its running on 
> brothers own drivers.

Thank you, Gene. Your investigations are vey useful and point to my
forgetfulness.

The snmp backend is not installed in the location I gave but has
to be moved there. Do either

  mv /usr/lib/cups/backend-available/snmp /usr/lib/cups/backend/snmp

or

  dpkg-reconfigure cups

-- 
Brian.

Re: CUPS - how to match autodetected printers to physical ones

[tomas]

On Sun, Apr 10, 2022 at 01:40:29PM +0100, Brian wrote:

[...]

> Many printers provide an snmp (Simple Network Management Protocol)
> service on port 9100. Check with
> 
>   nmap 10.76.172.100

I know a corporate network or two which would get you disconnected
if you do that :)

Then you've got to go to the firewall admin and beg for being reconnected.
So if you try it, first make sure you are on speaking terms with the
network/firewall admins (a good idea, regardless...)

So careful.

Cheers
-- 
t


signature.asc
Description: PGP signature

Re: CUPS - how to match autodetected printers to physical ones

[Brian]

On Sun 10 Apr 2022 at 08:10:17 -0400, gene heskett wrote:

> On Sunday, 10 April 2022 07:17:42 EDT The Wanderer wrote:
> > On 2022-04-10 at 07:08, gene heskett wrote:
> > > On Sunday, 10 April 2022 06:06:31 EDT to...@tuxteam.de wrote:
> > >> I just don't install it.
> > > 
> > > And how do you accomplish that? Its automatically installed AFAIK.
> > > And once installed, apt will not remove it without destroying the
> > > install. rm or chmod -x seems to be the only way, and nothing
> > > complains.
> > 
> > What package(s), by exact name, are you referring to? That is, which
> > package(s) is it that produce this effect when you try to remove them?
> > 
> > On my computer, I have several libavahi* packages, which could not be
> > removed without removing large swaths of packages - but I also have
> > avahi-daemon and avahi-utils, which can be removed with few if any side
> > effects (as far as triggering removal of other packages goes).
> > 
> > And since the subject at hand in this branch of the thread appears to
> > be avahi-daemon, surely removing that single package should be enough
> > to prevent avahi from doing anything undesirable?
> 
> Which IMO It should be but apt will not remove avahi-daemon on any of my 
> buster machines  or on bullseye without taking "large swaths" of stuff 
> with it.
> 
> Tomas just found, and I have now edited /etc/default/avahi-daemon to 
> officialy shut it off, ditto for brytty, leaving a killed orca spewing 20 

I do not think AVAHI_DAEMON_DETECT_LOCAL does what you think it does.
It applies to detection of *unicast* dns servers.

-- 
Brian.

Re: CUPS - how to match autodetected printers to physical ones

[gene heskett]

On Sunday, 10 April 2022 08:54:07 EDT Brian wrote:
> On Sun 10 Apr 2022 at 05:46:35 -0400, gene heskett wrote:
> 
> [...]
> 
> > This, FWIW, has nothing to do with cups and printer sharing, cups
> > does
> > its own advertising. All printers here are attached to this machine,
> > marked as shareable and I can put stuff on their output trays from
> > any
> > machine including the rpi4 on my local network.
> 
> Indeed, CUPS does do its own advertising of print queue and uses
> mDNS/DNS-SD. That is its *only* technique it has available for
> sharing the queues.
> 
> mDNS/DNS-SD requires avahi-daemon to be active. Without it there
> isn't any sharing and advertising.
> 
> So, I do not understand "...has nothing to do with...".
> 
The avahi-daemon has either been removed by rm. or by chmod -x on all 
machines here, yet cups shared printers (plural) can use those shared 
printers just as if they were plugged into that machine. So IMO removing 
or disabling avahi-daemon has nothing to do with cups sharing.
You are saying it won't work, but it does here. What else is there except 
cups.

> --
> Brian.
> 
> .


Cheers, Gene Heskett.
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis

Re: CUPS - how to match autodetected printers to physical ones

[gene heskett]

On Sunday, 10 April 2022 08:40:29 EDT Brian wrote:
>   /usr/lib/cups/backend/snmp
The only machine I have here that has that file installed, an rpi4, does 
not expose the printers address, only:
pi@rpi4:~ $ sudo  /usr/lib/cups/backend/snmp
network lpd://BRN30055C8A2DC8/BINARY_P1 "Brother MFC-J6920DW" "Brother 
MFC-J6920DW" "MFG:Brother;CMD:HBP,BRPJL,URF;MDL:MFC-
J6920DW;CLS:PRINTER;CID:Brother IJ 
Type3;URF:SRGB24,W8,CP1,IS1-13,MT1-8-11,OB9,PQ4-5,RS200-300,OFU0,V1.2,DM4;" 
"coyote.coyote.den"

The only location identifier is the resolved "coyote.coyote.den" which is 
this machine.

None of the buster boxes have it, so they all report file not found. BUT 
they were all installed from a buster respin by the linuxcnc folks. But 
geany the editor, can drive that printer from any locatiom my cat5 cable 
reaches.

And I just checked because there is a 2nd printer, another brother HL2320 
B&W duplex capable laser, on this machine, and although the above command 
only shows one printer, I can feed both printers from geany running on 
any machine, all 6 of the profiles I have defined are available for geany 
to use as an output device. I suspect the laser doesn't do snmp, its a 
$120 printer. Probably some brother version of plc5 since its running on 
brothers own drivers.

Cheers Brian, Gene Heskett.
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis

Re: CUPS - how to match autodetected printers to physical ones

[Brian]

On Sun 10 Apr 2022 at 05:46:35 -0400, gene heskett wrote:

[...]

> This, FWIW, has nothing to do with cups and printer sharing, cups does 
> its own advertising. All printers here are attached to this machine, 
> marked as shareable and I can put stuff on their output trays from any 
> machine including the rpi4 on my local network.

Indeed, CUPS does do its own advertising of print queue and uses
mDNS/DNS-SD. That is its *only* technique it has available for
sharing the queues.

mDNS/DNS-SD requires avahi-daemon to be active. Without it there
isn't any sharing and advertising.

So, I do not understand "...has nothing to do with...".

-- 
Brian.

Re: CUPS - how to match autodetected printers to physical ones

[The Wanderer]

On 2022-04-10 at 08:38, Brian wrote:

> On Sat 09 Apr 2022 at 20:21:12 -0400, The Wanderer wrote:
> 
>> On 2022-04-09 at 07:56, Brian wrote:

>>> It is straightforward, I don't know about obvious to all users.
>>> 
>>> avahi-browse -rt _ipp._tcp
>> 
>> Does that get the information from CUPS?
>> 
>> It looks to me as if it gets the information from the network, via
>> what are probably the same discovery methods as CUPS used to get
>> it.
>> 
>> That's not the same as getting the information *from CUPS*, which
>> must logically already have that information.
>> 
>> Having a way to get the information at all (and we already seem to
>> have at least two of those, from this thread, one of them being the
>> one you just cited) is not the same as having a way to get the
>> information *from where it must logically already be*, and the
>> apparent lack of the latter is what's bothering me about the
>> described behavior.
> 
> CUPS delegates resolution of hosts and services to mDNS; I am happy 
> to follow in its footsteps.
> 
> CUPS may very well know the IP address but it is not of direct
> interest to the user,

That will very definitely vary depending on the user.

> who is better served by being informed of the URI.

This may be true in some cases, but is very definitely not true in all.

> For various reasons, IP addresses can change, of course; printers
> being moved round the network, for example.

This is based on a set of assumptions which may apply in some cases, but
very definitely do not apply in all cases. I don't want to dive deep
into them, however, since this has already gone on long enough.

>>> CUPS uses mDNS/DNS-sd for discovery. The user does the same:
>>> 
>>> avahi-browse -rt _ipp._tcp
>> 
>> This seems to be confirming the hypothesis above: that this is not 
>> getting CUPS to reveal the information, but performing the same 
>> discovery method that CUPS used to get the information.
> 
> Yes.
> 
>> If, for example, the printer was online when CUPS discovered it and
>> is therefore listed in the CUPS interface, but is offline now
>> (perhaps someone accidentally unplugged the network cable from the
>> printer?), I would be mildly surprised if this would still result
>> in showing the IP address of the printer. CUPS, however, must still
>> have that address, from its past discovery.
> 
> The CUPS web interface is not designed to show the IP address but to 
> display the URI.

This, I think, is exactly the detail that's being complained of. If CUPS
knows the IP address, it should be possible to get CUPS to reveal that
IP address.

If on the other hand CUPS *doesn't* know the IP address, but only the
hostname et cetera (because that's part of the URI, and CUPS only
knows/stores the URI), then that might be reasonable.

(My previous comments were based on the assumption that all
communication with the printer would be done based on IP address, rather
than on symbolic name and on connect-time resolution. That may in turn
be based on my experience in the Windows world, where printer hostnames
and DNS lookup are in my experience wildly unreliable and as a
consequence are very rarely used; I reflexively expect that the parts of
a system which communicate with a printer will always know it primarily,
if not exclusively, by its IP address.)

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man. -- George Bernard Shaw



signature.asc
Description: OpenPGP digital signature

Re: CUPS - how to match autodetected printers to physical ones

[gene heskett]

On Sunday, 10 April 2022 08:02:32 EDT to...@tuxteam.de wrote:
> On Sun, Apr 10, 2022 at 07:46:37AM -0400, gene heskett wrote:
> > On Sunday, 10 April 2022 06:06:31 EDT to...@tuxteam.de wrote:
> > > AVAHI_DAEMON_DETECT_LOCAL=0 into some /etc/default/avahi-daemon.
> > 
> > Checking all my machines, all but one was set to 1, fixed the others
> > and redid the initramfs as it said in 2 of the 5, in that file.
> > 
> > Thank you for that Tomas, now its done by the official way including
> > on this bullseye box. I also took advantage and disabled brltty by
> > similar means. That leaves orca dirtying the logs with about 20
> > lines every 15 seconds. And that leads to a reboot about weekly by
> > filling up the /var partition. Orca however, does not appear in
> > /etc/default. Where is it started so I can officially stop it? That
> > would extend my uptimes I expect.
> 
> As it came out in That Other Thread :) I think this is some rogue USB
> serial adapter fooling udev that it is a Braille input. Find that, fix
> your udev rules (or dump the adapter).
> 
> Background: whenever you stick an USB into your device tree, it tells
> udev "hi, I'm a new mouse". Or a "memory stick". Or "a camera". But
> of course, this comes roundabout: it tells the maker and the maker's
> device model as a pair of numbers.
> 
> There's a lot of things which may go wrong there: from an inexact
> device database to some cheap manufacturer skimping on the USB
> consortium membership and squatting on wrong identifiers.
> 
Or even ducks the issue by all-balling the identifiers. Those most often 
encountered looking like a usb key gismo and soon find the trash can.

But since fdti is the only maker of seriel adaptors that actually works, 
proliic tried but failed miserably, I see no reason not to reach thru the 
adaptor and see if its actually a braille device, rather that blindly 
assuming it is when there are many other often legacy devices that need 
the adaptor. The cm11a to control your lights and appliances interface is 
likely at least 30 years old, and the protocol was known in the mid 80's. 
I wrote software in the late 80's to do that from a trs-80 Color Computer 
running os9-level one, then jim hines and I moved it to amigados using 
ARexx and sold registered copies of it for a few years.  Called it ezhome 
based on something else we wrote called ezcron since amigados had no cron 
utility. We gave that away.
 
> Once we have more details perhaps someone can lead you through the
> process. But test-booting the thing while some USB devices are
> unplugged until you find the culprit is something only you can do.

True Tomas, but my attempts to install w/o it have all failed as it will 
not reboot without it so a reboot turns into a new install, 20 some times 
now, which I'm sick of doing, hence my questions that keep harping on 
getting rid of it gracefully AFTER the install. Basicly, whats done 
should have an undo method and I will keep asking until the magic phrase 
comes out of someones fingertips. In the meantime I am reminded of it by 
the need to reboot weekly in order to have a usable machine.

> Hint: binary search may be helpful (unstick first half of the USBs
> and so on).
> 
> Cheers
> --
> t
Take care and stay well, Tomas.


Cheers, Gene Heskett.
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis

Re: CUPS - how to match autodetected printers to physical ones

[Brian]

On Fri 08 Apr 2022 at 13:22:26 -0400, Greg Wooledge wrote:

> On Fri, Apr 08, 2022 at 06:03:47PM +0100, Tixy wrote:
> > On Fri, 2022-04-08 at 17:59 +0100, Tixy wrote:
> > > On Fri, 2022-04-08 at 12:10 -0400, Greg Wooledge wrote:
> > > > Unfortunately, I was not able to find ANY way to determine the IP
> > > > addresses of the autodetected printers that were presented to me.
> > > 
> > > If I go to http://localhost:631/printers/
> > 
> > I should say I got to that URL from the CUPs interface at
> > http://localhost:631/ then clicking the 'Admininitation' tab at the top
> > followed by the 'Manage Printers' button on the page that showed.
> 
> Here is what I have on that page:
> 
> =
> Showing 7 of 7 printers.
> 
> Queue NameDescription LocationMake and Model  Status
> Canon_LBP351dn_f9_7a_4a_  CNLBP712C CNLBP712C, 
> driverless, cups-filters 1.28.7Idle
> Canon_LBP712Cdn_db_c0_d3_ Canon_LBP712Cdn_db_c0_d3_   
> CNLBP712C CNLBP712C, driverless, cups-filters 1.28.7Idle
> Cups_PDF_oc3261540276 Cups_PDF_oc3261540276   Local Raw Printer   
> Paused
> HP_LaserJet_4100_Series_0001E6A68D3D_ HP_LaserJet_4100_Series_0001E6A68D3D_   
> HP LaserJet 4100 Series , driverless, cups-filters 1.28.7   Idle
> hp_LaserJet_4250_621E13_  hp_LaserJet_4250_621E13_hp 
> LaserJet 4250, driverless, cups-filters 1.28.7   Idle
> HP_LaserJet_P3010_Series_0FCDD7_  HP_LaserJet_P3010_Series_0FCDD7_
> HP LaserJet P3010 Series, driverless, cups-filters 1.28.7   Idle
> PostScript_oc3261540276   PostScript_oc3261540276 Local Raw 
> Printer   Paused
> =

[...]

> Looking at the stuff that I pasted here, how am I supposed to know whether
> this corresponds to the physical printer with IP address 10.76.172.100?

Another idea that may or may not grip you. It's not guaranteed to
work ( whereas the avahi-browse command should be reliable) but it
could be worth a try.

Many printers provide an snmp (Simple Network Management Protocol)
service on port 9100. Check with

  nmap 10.76.172.100

It would be unusual for the service not to be offered because it
dates from the dawn of time and is very simple to implement. There
isn't any reliance on avahi-daemon (just TCP/IP) and it works with
non-ipp printers.

Execute

  /usr/lib/cups/backend/snmp

The output should include an IP address and a printer make and model.

Thanks to The Wanderer for sparking this thought.

-- 
Brian.

Re: CUPS - how to match autodetected printers to physical ones

[Brian]

On Sat 09 Apr 2022 at 20:21:12 -0400, The Wanderer wrote:

> On 2022-04-09 at 07:56, Brian wrote:
> 
> > On Fri 08 Apr 2022 at 19:45:41 -0400, The Wanderer wrote:
> > 
> >> (This is probably both overly long and overly repetitive, among
> >> possibly other undesirable things, but I'm running short on time.)
> > 
> > So I hope you do not mind if I do not reply to every point you make.
> 
> I don't strongly mind that, no. A few of them were probably rephrasings
> of the same thing in different ways.
> 
> >> On 2022-04-08 at 18:44, Brian wrote:
> 
> 
> 
> >> What Greg was asking about, as far as I can tell, is a way to get
> >> CUPS to tell him that network-location information - so that he, as
> >> someone external to the printing system, could then apply that
> >> information to his additional knowledge about the physical location
> >> of the printer with a specific IP address.
> >> 
> >> I'm not sure we (in this thread) have yet found a way to do that 
> >> directly; we've found what appear to be two different ways to find
> >> the IP address of the printer with the name that CUPS is reporting,
> >> but it looks to me as if both of them are getting that information
> >> via an external method (probably similar to how CUPS found the
> >> printer in the first place), rather than getting that information
> >> from CUPS itself.
> >> 
> >> The IP-address (etc.?) information must exist within CUPS, since
> >> CUPS is able to actually send jobs to the printer; why isn't it
> >> straightforward and obvious how to get that information *from*
> >> within CUPS *to* someplace visible?
> > 
> > It is straightforward, I don't know about obvious to all users.
> > 
> > avahi-browse -rt _ipp._tcp
> 
> Does that get the information from CUPS?
> 
> It looks to me as if it gets the information from the network, via what
> are probably the same discovery methods as CUPS used to get it.
> 
> That's not the same as getting the information *from CUPS*, which must
> logically already have that information.
> 
> Having a way to get the information at all (and we already seem to have
> at least two of those, from this thread, one of them being the one you
> just cited) is not the same as having a way to get the information *from
> where it must logically already be*, and the apparent lack of the latter
> is what's bothering me about the described behavior.

CUPS delegates resolution of hosts and services to mDNS; I am happy
to follow in its footsteps.

CUPS may very well know the IP address but it is not of direct interest
to the user, who is better served by being informed of the URI. For
various reasons, IP addresses can change, of course; printers being moved
round the network, for example.
 
> >>> CUPS knows how to route the job. The physical location of the 
> >>> printer is not involved in the routeing.
> >> 
> >> True, and I don't understand why you thought it was involved (as
> >> relates to CUPS) at all.
> >> 
> >> The IP address, however, *is* involved in the routing - and
> >> therefore CUPS must know it. (Or some proxy piece of information,
> >> as above.)
> >> 
> >> The original question as I understand it was how to get CUPS to
> >> reveal that piece of information which it must know.
> > 
> > CUPS uses mDNS/DNS-sd for discovery. The user does the same:
> > 
> > avahi-browse -rt _ipp._tcp
> 
> This seems to be confirming the hypothesis above: that this is not
> getting CUPS to reveal the information, but performing the same
> discovery method that CUPS used to get the information.

Yes.
 
> If, for example, the printer was online when CUPS discovered it and is
> therefore listed in the CUPS interface, but is offline now (perhaps
> someone accidentally unplugged the network cable from the printer?), I
> would be mildly surprised if this would still result in showing the IP
> address of the printer. CUPS, however, must still have that address,
> from its past discovery.

The CUPS web interface is not designed to show the IP address but to
display the URI. However, the URI might give an IP address if it is
a socket://... or lpd://... URI.

An offlin machine would continue to list information for manually
set up queues.

If CUPS retains an address of a previous connection, I am not aware
of a way to extract it

>  What I understood Greg as asking about is how to get CUPS to
>  *tell* you what the IP address it knows about for a given
>  printer object is. That doesn't seem to be an unreasonable
>  thing to want to know, or to expect CUPS to be able to provide;
>  I'd want the same thing, in anything remotely like his place.
> > 
> > avahi-browse -rt _ipp._tcp
> 
> As above.
> 
> >>> Finding the IP address is easy:
> >>> 
> >>> ippfind -T 5 ipp://envy4500.local:631/ipp/print ping -c 3
> >>> envy4500.local
> >> 
> >> That only works if IPP is in use, which isn't guaranteed.
> > 
> > Communication between CUPS servers is guaranteed to be by IPP.
> > Between CUPS and modern printers is only via IPP.
> 
> Ok

Re: CUPS - how to match autodetected printers to physical ones

[The Wanderer]

On 2022-04-10 at 08:10, gene heskett wrote:

> On Sunday, 10 April 2022 07:17:42 EDT The Wanderer wrote:
> 
>> On 2022-04-10 at 07:08, gene heskett wrote:

>>> And how do you accomplish that? Its automatically installed
>>> AFAIK. And once installed, apt will not remove it without
>>> destroying the install. rm or chmod -x seems to be the only way,
>>> and nothing complains.
>> 
>> What package(s), by exact name, are you referring to? That is,
>> which package(s) is it that produce this effect when you try to
>> remove them?
>> 
>> On my computer, I have several libavahi* packages, which could not
>> be removed without removing large swaths of packages - but I also
>> have avahi-daemon and avahi-utils, which can be removed with few if
>> any side effects (as far as triggering removal of other packages
>> goes).
>> 
>> And since the subject at hand in this branch of the thread appears
>> to be avahi-daemon, surely removing that single package should be
>> enough to prevent avahi from doing anything undesirable?
> 
> Which IMO It should be but apt will not remove avahi-daemon on any of
> my buster machines  or on bullseye without taking "large swaths" of
> stuff with it.

Based on what Tomas said in his reply, I'm guessing that that's because
you've got GNOME or some similar fancy DE installed, and that DE's
packages declare a dependency on avahi-daemon directly.

I don't use such a DE (preferring, instead, a WM so niche that it's not
even packaged and in the repositories anymore), so it's no surprise that
I wouldn't see that effect - and also, if you do, no surprise that you
would.

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man. -- George Bernard Shaw



signature.asc
Description: OpenPGP digital signature

Re: CUPS - how to match autodetected printers to physical ones

[gene heskett]

On Sunday, 10 April 2022 07:17:42 EDT The Wanderer wrote:
> On 2022-04-10 at 07:08, gene heskett wrote:
> > On Sunday, 10 April 2022 06:06:31 EDT to...@tuxteam.de wrote:
> >> I just don't install it.
> > 
> > And how do you accomplish that? Its automatically installed AFAIK.
> > And once installed, apt will not remove it without destroying the
> > install. rm or chmod -x seems to be the only way, and nothing
> > complains.
> 
> What package(s), by exact name, are you referring to? That is, which
> package(s) is it that produce this effect when you try to remove them?
> 
> On my computer, I have several libavahi* packages, which could not be
> removed without removing large swaths of packages - but I also have
> avahi-daemon and avahi-utils, which can be removed with few if any side
> effects (as far as triggering removal of other packages goes).
> 
> And since the subject at hand in this branch of the thread appears to
> be avahi-daemon, surely removing that single package should be enough
> to prevent avahi from doing anything undesirable?

Which IMO It should be but apt will not remove avahi-daemon on any of my 
buster machines  or on bullseye without taking "large swaths" of stuff 
with it.

Tomas just found, and I have now edited /etc/default/avahi-daemon to 
officialy shut it off, ditto for brytty, leaving a killed orca spewing 20 
lines of errors into the log every 15 seconds until it takes so long to 
append the log that the machine is unusable for over 30 seconds at a time 
and must be rebooted about weekly to recover, all because the installer 
thinks ANY usb to seriel adaptor plugged in is driving a braille 
interface. Theres a lot of other reasons to have such on a system, and in 
fact I have 2 of them, one serviceing my ups, and one servicing a cm-11a 
interface for heyu. I dare say that is a more common a use than a braille 
interface. Or a speech synth that isn't understandable, which category 
orca certainly is in.

So I'll repeat my request as to how do I turn off orca AND get rid of the 
every 15 second error spew to the log because its been killed?

> --
>The Wanderer
> 
> The reasonable man adapts himself to the world; the unreasonable one
> persists in trying to adapt the world to himself. Therefore all
> progress depends on the unreasonable man. -- George Bernard
> Shaw


Cheers, Gene Heskett.
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis

Re: CUPS - how to match autodetected printers to physical ones

[tomas]

On Sun, Apr 10, 2022 at 07:46:37AM -0400, gene heskett wrote:
> On Sunday, 10 April 2022 06:06:31 EDT to...@tuxteam.de wrote:
> 
> > AVAHI_DAEMON_DETECT_LOCAL=0 into some /etc/default/avahi-daemon.
> 
> Checking all my machines, all but one was set to 1, fixed the others and 
> redid the initramfs as it said in 2 of the 5, in that file.
> 
> Thank you for that Tomas, now its done by the official way including on 
> this bullseye box. I also took advantage and disabled brltty by similar 
> means. That leaves orca dirtying the logs with about 20 lines every 15 
> seconds. And that leads to a reboot about weekly by filling up the /var 
> partition. Orca however, does not appear in /etc/default. Where is it 
> started so I can officially stop it? That would extend my uptimes I 
> expect.

As it came out in That Other Thread :) I think this is some rogue USB
serial adapter fooling udev that it is a Braille input. Find that, fix
your udev rules (or dump the adapter).

Background: whenever you stick an USB into your device tree, it tells
udev "hi, I'm a new mouse". Or a "memory stick". Or "a camera". But
of course, this comes roundabout: it tells the maker and the maker's
device model as a pair of numbers.

There's a lot of things which may go wrong there: from an inexact device
database to some cheap manufacturer skimping on the USB consortium
membership and squatting on wrong identifiers.

Once we have more details perhaps someone can lead you through the
process. But test-booting the thing while some USB devices are
unplugged until you find the culprit is something only you can do.

Hint: binary search may be helpful (unstick first half of the USBs
and so on).

Cheers
-- 
t


signature.asc
Description: PGP signature

Re: CUPS - how to match autodetected printers to physical ones

[tomas]

On Sun, Apr 10, 2022 at 07:17:42AM -0400, The Wanderer wrote:
> On 2022-04-10 at 07:08, gene heskett wrote:
> 
> > On Sunday, 10 April 2022 06:06:31 EDT to...@tuxteam.de wrote:
> 
> >> I just don't install it.
> > 
> > And how do you accomplish that? Its automatically installed AFAIK.
> > And once installed, apt will not remove it without destroying the
> > install. rm or chmod -x seems to be the only way, and nothing
> > complains.
> 
> What package(s), by exact name, are you referring to? That is, which
> package(s) is it that produce this effect when you try to remove them?
> 
> On my computer, I have several libavahi* packages, which could not be
> removed without removing large swaths of packages - but I also have
> avahi-daemon and avahi-utils, which can be removed with few if any side
> effects (as far as triggering removal of other packages goes).

The lib* things are different. That's the price we pay for a binary
distribution. I have quite a few libsystemd around. The alternative
would be to compile everything.

I'm not that uncompromising :)

> And since the subject at hand in this branch of the thread appears to be
> avahi-daemon, surely removing that single package should be enough to
> prevent avahi from doing anything undesirable?

Yes, that would be the one implementing zeroconf.

As I see, gnome is listed as avahi-daemon dependency. So that could be
what happens to Gene. "I'm going to remove Gnome now" does sound scary :)

Cheers
-- 
t


signature.asc
Description: PGP signature

Re: CUPS - how to match autodetected printers to physical ones

[tomas]

On Sun, Apr 10, 2022 at 07:08:36AM -0400, gene heskett wrote:
> On Sunday, 10 April 2022 06:06:31 EDT to...@tuxteam.de wrote:

[...]

> > be putting AVAHI_DAEMON_DETECT_LOCAL=0 into some
> > /etc/default/avahi-daemon.
> 
> Then whyintarnation does it not say that in what serves as a man page?

Sometimes systems become... complex. I guess (just guess) that avahi-daemon
has some command-line parameters to manage that. Those would be in the
man page.

The /etc/default hierarchy is rather a Debian-specific things to provide
start-up options to system-wide services (and also to the boot process).
Those are picked up from there.

> > No need to rm it. But if it satisfies you, you're your box's boss :)
> 
> Exactly.
>  
> > I just don't install it.
> 
> And how do you accomplish that? Its automatically installed AFAIK. And 
> once installed, apt will not remove it without destroying the install. rm 
> or chmod -x seems to be the only way, and nothing complains. 

There are things depending on avahi. I don't need them. I've to jump
through some hoops to keep systemd or dbus to be installed (but it's
manageable), but avahi hasn't ever tried, yet :-)

Current desktop environments won't like that, mind you. But I don't
particularly like them, either.

Cheers
-- 
t


signature.asc
Description: PGP signature

Re: CUPS - how to match autodetected printers to physical ones

[gene heskett]

On Sunday, 10 April 2022 06:06:31 EDT to...@tuxteam.de wrote:

> AVAHI_DAEMON_DETECT_LOCAL=0 into some /etc/default/avahi-daemon.

Checking all my machines, all but one was set to 1, fixed the others and 
redid the initramfs as it said in 2 of the 5, in that file.

Thank you for that Tomas, now its done by the official way including on 
this bullseye box. I also took advantage and disabled brltty by similar 
means. That leaves orca dirtying the logs with about 20 lines every 15 
seconds. And that leads to a reboot about weekly by filling up the /var 
partition. Orca however, does not appear in /etc/default. Where is it 
started so I can officially stop it? That would extend my uptimes I 
expect.

Thanks Tomas.


Cheers, Gene Heskett.
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis

Re: CUPS - how to match autodetected printers to physical ones

[The Wanderer]

On 2022-04-10 at 07:08, gene heskett wrote:

> On Sunday, 10 April 2022 06:06:31 EDT to...@tuxteam.de wrote:

>> I just don't install it.
> 
> And how do you accomplish that? Its automatically installed AFAIK.
> And once installed, apt will not remove it without destroying the
> install. rm or chmod -x seems to be the only way, and nothing
> complains.

What package(s), by exact name, are you referring to? That is, which
package(s) is it that produce this effect when you try to remove them?

On my computer, I have several libavahi* packages, which could not be
removed without removing large swaths of packages - but I also have
avahi-daemon and avahi-utils, which can be removed with few if any side
effects (as far as triggering removal of other packages goes).

And since the subject at hand in this branch of the thread appears to be
avahi-daemon, surely removing that single package should be enough to
prevent avahi from doing anything undesirable?

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man. -- George Bernard Shaw



signature.asc
Description: OpenPGP digital signature

Re: CUPS - how to match autodetected printers to physical ones

[gene heskett]

On Sunday, 10 April 2022 06:06:31 EDT to...@tuxteam.de wrote:
> On Sun, Apr 10, 2022 at 05:46:35AM -0400, gene heskett wrote:
> 
> [...]
> 
> > Then why, after a decade and change of bitching about it because it
> > insists on putting a 169.254.xx,yy address in ones routing table that
> > only removing avahi fixes, has it not been fixed?
> 
> This would be an IPv4 link-local [0] address. Correctly naming
> things is always the first step to taking control over them:
> casting spells and that ;-)
> 
> Setting that up is zeroconf's [1] job, which, AFAIK, is actually
> done by the avahi daemon. I can't check it myself, because my
> box has no avahi.
> 
> But if you know how the thing's called, you can throw your spells
> at a search engine (hopefully not the one of survellance capitalism,
> but I disgress ;-) and find things like [2]. It tells you how to
> convince different systems to not do that; under Debian, this would
> be putting AVAHI_DAEMON_DETECT_LOCAL=0 into some
> /etc/default/avahi-daemon.

Then whyintarnation does it not say that in what serves as a man page?

> No need to rm it. But if it satisfies you, you're your box's boss :)

Exactly.
 
> I just don't install it.

And how do you accomplish that? Its automatically installed AFAIK. And 
once installed, apt will not remove it without destroying the install. rm 
or chmod -x seems to be the only way, and nothing complains. 

> Cheers
> --
> t

Take care and stay well Tomas.

Cheers, Gene Heskett.
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis

Re: CUPS - how to match autodetected printers to physical ones

[tomas]

On Sun, Apr 10, 2022 at 05:46:35AM -0400, gene heskett wrote:

[...]

> Then why, after a decade and change of bitching about it because it 
> insists on putting a 169.254.xx,yy address in ones routing table that 
> only removing avahi fixes, has it not been fixed?

This would be an IPv4 link-local [0] address. Correctly naming
things is always the first step to taking control over them:
casting spells and that ;-)

Setting that up is zeroconf's [1] job, which, AFAIK, is actually
done by the avahi daemon. I can't check it myself, because my
box has no avahi.

But if you know how the thing's called, you can throw your spells
at a search engine (hopefully not the one of survellance capitalism,
but I disgress ;-) and find things like [2]. It tells you how to
convince different systems to not do that; under Debian, this would
be putting AVAHI_DAEMON_DETECT_LOCAL=0 into some /etc/default/avahi-daemon.

No need to rm it. But if it satisfies you, you're your box's boss :)

I just don't install it.

Cheers
-- 
t


signature.asc
Description: PGP signature

Re: CUPS - how to match autodetected printers to physical ones

[gene heskett]

On Sunday, 10 April 2022 02:33:21 EDT to...@tuxteam.de wrote:
> On Sat, Apr 09, 2022 at 08:21:12PM -0400, The Wanderer wrote:
> 
> [...]
> 
> > I honestly don't know the subject very well myself, but I'd
> > definitely
> > like to know it better than I do.
> > 
> > One aspect of Windows printer sharing is that it makes it possible to
> > connect a printer not directly to the network, but locally to a
> > particular computer, and then configure that computer to advertise
> > the
> > printer over the network. Other computers can then send jobs to that
> > printer via that computer, which is de-facto a print server for that
> > printer.
> > 
> > Do you know whether CUPS is capable of interacting with printers
> > which
> > are shared in that way? (This is a tangent to the topic of the
> > thread,
> > but it fits this local context and it's a thing I'd be interested
> > in.)
> 
> If that local printer is known to CUPS and the local sysadmin has
> marked it as shareable (however you do that in CUPS), that would,
> as I have understood it, be Avahi's job, which is a service
> (advertisement and) discovery protocol.
 
Then why, after a decade and change of bitching about it because it 
insists on putting a 169.254.xx,yy address in ones routing table that 
only removing avahi fixes, has it not been fixed?  You can spec the 
correct address other places such as in /etc/networking/interfaces.d/
anyfilename, or in the last two paragraphs of /etc/dhcpcd.conf, but if 
avahi is executable, it will override your settings and kill your 
networking setup dead in the water. 

And what I mean is that removing it is done behind apt's back by hunting 
it down and rm-ing it. apt will not remove it w/o destroying the rest of 
the system. 

For those of us using hosts files for networking on our little home 
networks of less that say 16 machines, avahi is the first thing we hunt 
down and rm after the installers reboot. Only then can we spec a 
192.168.xx.yy address to our local gateway and make it stick.

Of note is that NOTHING else in the system considers a missing avahi as a 
loggable event.

ONLY apt thinks it is valuable enough to cause its dependencies to 
destroy the system if you try to remove it with apt as the package 
manager.

Which suits me just fine as its been a headache, looking for a problem 
that does not exist since it came on the scene. Here, at the coyote.den 
domain, it does not exist in executable form.

Except to pull my trigger when someone recommends that broken concept 
utility for anything.

This, FWIW, has nothing to do with cups and printer sharing, cups does 
its own advertising. All printers here are attached to this machine, 
marked as shareable and I can put stuff on their output trays from any 
machine including the rpi4 on my local network.

The missing avahi has nothing to do with that. The only disadvantage is 
the long walk to retrieve the printout, but I probably needed the 
exercise anyway.

> Cheers
> --
> t


Cheers, Gene Heskett.
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis

Re: CUPS - how to match autodetected printers to physical ones

[tomas]

On Sat, Apr 09, 2022 at 08:21:12PM -0400, The Wanderer wrote:

[...]

> I honestly don't know the subject very well myself, but I'd definitely
> like to know it better than I do.
> 
> One aspect of Windows printer sharing is that it makes it possible to
> connect a printer not directly to the network, but locally to a
> particular computer, and then configure that computer to advertise the
> printer over the network. Other computers can then send jobs to that
> printer via that computer, which is de-facto a print server for that
> printer.
> 
> Do you know whether CUPS is capable of interacting with printers which
> are shared in that way? (This is a tangent to the topic of the thread,
> but it fits this local context and it's a thing I'd be interested in.)

If that local printer is known to CUPS and the local sysadmin has
marked it as shareable (however you do that in CUPS), that would,
as I have understood it, be Avahi's job, which is a service (advertisement
and) discovery protocol.

Cheers
-- 
t


signature.asc
Description: PGP signature

Re: CUPS - how to match autodetected printers to physical ones

[Teemu Likonen]

* 2022-04-10 03:59:25+0100, mick crane wrote:

> On 2022-04-10 01:21, The Wanderer wrote:
>>> avahi-browse -rt _ipp._tcp
>> 
>> Does that get the information from CUPS?
>
> With printer connected via other PC (CUPS print server) there is no 
> output from "avahi-browse -rt _ipp._tcp"

Should be, if the print server has setting "Share printers connected to
this system". Obviously Cups and Avahi must be running on machines in
the same network.

-- 
/// Teemu Likonen - .-.. https://www.iki.fi/tlikonen/
// OpenPGP: 6965F03973F0D4CA22B9410F0F2CAE0E07608462


signature.asc
Description: PGP signature

Re: CUPS - how to match autodetected printers to physical ones

[mick crane]

On 2022-04-10 01:21, The Wanderer wrote:


avahi-browse -rt _ipp._tcp


Does that get the information from CUPS?


With printer connected via other PC (CUPS print server) there is no 
output from "avahi-browse -rt _ipp._tcp"


mick
--
Key ID4BFEBB31

Re: CUPS - how to match autodetected printers to physical ones

[The Wanderer]

On 2022-04-09 at 07:56, Brian wrote:

> On Fri 08 Apr 2022 at 19:45:41 -0400, The Wanderer wrote:
> 
>> (This is probably both overly long and overly repetitive, among
>> possibly other undesirable things, but I'm running short on time.)
> 
> So I hope you do not mind if I do not reply to every point you make.

I don't strongly mind that, no. A few of them were probably rephrasings
of the same thing in different ways.

>> On 2022-04-08 at 18:44, Brian wrote:



>> What Greg was asking about, as far as I can tell, is a way to get
>> CUPS to tell him that network-location information - so that he, as
>> someone external to the printing system, could then apply that
>> information to his additional knowledge about the physical location
>> of the printer with a specific IP address.
>> 
>> I'm not sure we (in this thread) have yet found a way to do that 
>> directly; we've found what appear to be two different ways to find
>> the IP address of the printer with the name that CUPS is reporting,
>> but it looks to me as if both of them are getting that information
>> via an external method (probably similar to how CUPS found the
>> printer in the first place), rather than getting that information
>> from CUPS itself.
>> 
>> The IP-address (etc.?) information must exist within CUPS, since
>> CUPS is able to actually send jobs to the printer; why isn't it
>> straightforward and obvious how to get that information *from*
>> within CUPS *to* someplace visible?
> 
> It is straightforward, I don't know about obvious to all users.
> 
> avahi-browse -rt _ipp._tcp

Does that get the information from CUPS?

It looks to me as if it gets the information from the network, via what
are probably the same discovery methods as CUPS used to get it.

That's not the same as getting the information *from CUPS*, which must
logically already have that information.

Having a way to get the information at all (and we already seem to have
at least two of those, from this thread, one of them being the one you
just cited) is not the same as having a way to get the information *from
where it must logically already be*, and the apparent lack of the latter
is what's bothering me about the described behavior.

>>> CUPS knows how to route the job. The physical location of the 
>>> printer is not involved in the routeing.
>> 
>> True, and I don't understand why you thought it was involved (as
>> relates to CUPS) at all.
>> 
>> The IP address, however, *is* involved in the routing - and
>> therefore CUPS must know it. (Or some proxy piece of information,
>> as above.)
>> 
>> The original question as I understand it was how to get CUPS to
>> reveal that piece of information which it must know.
> 
> CUPS uses mDNS/DNS-sd for discovery. The user does the same:
> 
> avahi-browse -rt _ipp._tcp

This seems to be confirming the hypothesis above: that this is not
getting CUPS to reveal the information, but performing the same
discovery method that CUPS used to get the information.

If, for example, the printer was online when CUPS discovered it and is
therefore listed in the CUPS interface, but is offline now (perhaps
someone accidentally unplugged the network cable from the printer?), I
would be mildly surprised if this would still result in showing the IP
address of the printer. CUPS, however, must still have that address,
from its past discovery.

 What I understood Greg as asking about is how to get CUPS to
 *tell* you what the IP address it knows about for a given
 printer object is. That doesn't seem to be an unreasonable
 thing to want to know, or to expect CUPS to be able to provide;
 I'd want the same thing, in anything remotely like his place.
> 
> avahi-browse -rt _ipp._tcp

As above.

>>> Finding the IP address is easy:
>>> 
>>> ippfind -T 5 ipp://envy4500.local:631/ipp/print ping -c 3
>>> envy4500.local
>> 
>> That only works if IPP is in use, which isn't guaranteed.
> 
> Communication between CUPS servers is guaranteed to be by IPP.
> Between CUPS and modern printers is only via IPP.

Okay, those are both details which I didn't know.

>> Also, how is that command supposed to be discoverable? Greg
>> certainly doesn't seem to have discovered it in his efforts, and I
>> wasn't aware of its existence either, and it also hasn't previously
>> been mentioned in this thread (despite the mentioning of
>> 'avahi-browse -rt _ipp._tcp', which turned out to also be an
>> adequate way of finding out what is probably the same
>> information).
> 
> I don' think I want to hazard a guess as to users' thought
> processes.

But that's an essential thing to do for designing in discoverability.

>>> If you were in his place, you should hope that the sys admins
>>> would include the physical location of the printer when
>>> advertising it. This is part of the IPP standard.
>> 
>> Speaking as someone who has *been* such a sysadmin (though I'm not
>> now, except insofar as those who are call on me to help solve
>> problems), I can say that aside 

Re: CUPS - how to match autodetected printers to physical ones

[Brian]

On Fri 08 Apr 2022 at 13:22:26 -0400, Greg Wooledge wrote:

> On Fri, Apr 08, 2022 at 06:03:47PM +0100, Tixy wrote:
> > On Fri, 2022-04-08 at 17:59 +0100, Tixy wrote:
> > > On Fri, 2022-04-08 at 12:10 -0400, Greg Wooledge wrote:
> > > > Unfortunately, I was not able to find ANY way to determine the IP
> > > > addresses of the autodetected printers that were presented to me.
> > > 
> > > If I go to http://localhost:631/printers/
> > 
> > I should say I got to that URL from the CUPs interface at
> > http://localhost:631/ then clicking the 'Admininitation' tab at the top
> > followed by the 'Manage Printers' button on the page that showed.
> 
> Here is what I have on that page:
> 
> =
> Showing 7 of 7 printers.
> 
> Queue NameDescription LocationMake and Model  Status
> Canon_LBP351dn_f9_7a_4a_  CNLBP712C CNLBP712C, 
> driverless, cups-filters 1.28.7Idle
> Canon_LBP712Cdn_db_c0_d3_ Canon_LBP712Cdn_db_c0_d3_   
> CNLBP712C CNLBP712C, driverless, cups-filters 1.28.7Idle
> Cups_PDF_oc3261540276 Cups_PDF_oc3261540276   Local Raw Printer   
> Paused
> HP_LaserJet_4100_Series_0001E6A68D3D_ HP_LaserJet_4100_Series_0001E6A68D3D_   
> HP LaserJet 4100 Series , driverless, cups-filters 1.28.7   Idle
> hp_LaserJet_4250_621E13_  hp_LaserJet_4250_621E13_hp 
> LaserJet 4250, driverless, cups-filters 1.28.7   Idle
> HP_LaserJet_P3010_Series_0FCDD7_  HP_LaserJet_P3010_Series_0FCDD7_
> HP LaserJet P3010 Series, driverless, cups-filters 1.28.7   Idle
> PostScript_oc3261540276   PostScript_oc3261540276 Local Raw 
> Printer   Paused
> =

[...]

> Looking at the stuff that I pasted here, how am I supposed to know whether
> this corresponds to the physical printer with IP address 10.76.172.100?

Let's eliminate Cups_PDF_oc3261540276 and PostScript_oc3261540276
first. These are local, manually set up print queues (not discovered).
The queue name doe not end with an underscore, indicating they are not
physical printers. (oc3261540276 identifies the host, but why that
format?)

The remaining five entries are printers. The "driverless, cups-filters"
indicates that cups-browsed has automatically set up local print queues
for them. They are on the same subnet as your device. 10/10 up to now
for the printing system.

This leaves two Canons and three HPs. What make is the printer in the
room? Canon? Still don't want to guess? Then

  avahi-browse -rt _ipp._tcp | grep -B 2 "10.76.172.100"

Another 10/10 fot the printing system and the tools it uses.

Of course, knowing the queue name in advance would be more desirable and
lead to less frustration.

-- 
Brian.

Re: CUPS - how to match autodetected printers to physical ones

[Greg Wooledge]

On Sat, Apr 09, 2022 at 12:56:12PM +0100, Brian wrote:
> It woould have been far, far more useful to have had the queue name on
> the card. Perhaps it can be added? Printing then becomes a two minute,
> no-fuss job:
> 
>   lp -d DESTINATION FILE

I'm not on site now, so I can't recall all of the information that
was on the "card" (folded sheet of paper actually).  There was
something that looked like a Windows pathname, but it did not match
any of the names presented by CUPS, and I don't remember exactly what
it said.

Re: On IP addresses and bus tripe [was: CUPS - how to match autodetected printers to physical ones]

[tomas]

On Sat, Apr 09, 2022 at 12:47:09PM +0100, Brian wrote:
> On Sat 09 Apr 2022 at 08:33:31 +0200, to...@tuxteam.de wrote:
> 
> > On Fri, Apr 08, 2022 at 08:52:26PM +0100, Brian wrote:
> > 
> > [...]
> > 
> > > You didn't like my bus analogy, did you?
> > 
> > I did like it. Nevertheless, I thought something's missing:
> 
> In general, analogies don't really work, do they?

In a former life, I used to be physicist. We actually thrive from
analogies :)

[...]

> Setting up a queue in some circumstances may require knowledge of
> an IP address. Printing to it doesn't. The wrong path was taken.

That's, strictly speaking, right; in the OP's case, it'd been
helpful to finding the printed rag, though.

> > In the bus's case, perhaps there is a big sign on the parking lot
> > "NEUF-BRISACH". There, that's your IP address.
> > 
> > Back to the printers, I'm horrified at the idea that CUPS doesn't
> > tell you the IP address it thinks the printer is at. It's what
> > I call "authoritarian software", where the software thinks it's
> > smarter than me. Don't get me wrong, I like comfort like the next
> > guy, but I don't like being treated like an idiot.
> 
> What is important for printing is the queue name (the destination)
> an the URI. Cups will take care of all the nitty-gritty in getting
> the job to the printer. A card with the queue name would have saved
> much head scratching.

That didn't help the OP. To back out from analogy land, a piece of
software which makes available to me as much info as it can has
more of my sympathy. Doing it in a well-structured and discoverable
way gets it 100+ points of sympathy. I appreciate the designer's
hard work in this.
> 
> > Look: if some programmer gal thinks she's smarter than me, I go
> > "arrogant gal, but who knows, probably she's right". But if a
> > piece of software does that, I tend to kick it out of my box.
> > My box, my rules :)
> > 
> > And yes: no CUPS (no Avahi either) on my box :-)
> 
> Avahi is not mandatory for printing. However, it does benefit many
> users.

I know, I know. Before kicking out Avahi I looked into what it
does. It was a voluntary decision, which most definitely isn't
right for everyone.

> Plug in a mouse. It wors straightaway. Nobody gives it a secomd
> thought. Nowadays, plug in a modern printer to USB and, with Avahi,
> it is immediately available for printing. What is there to dislike?
> People have been asking for this level of operation for years.

Overgeneralisation works even less than analogies :)

Cheers
-- 
t


signature.asc
Description: PGP signature

Re: CUPS - how to match autodetected printers to physical ones

[Brian]

On Fri 08 Apr 2022 at 19:57:53 -0500, David Wright wrote:

> On Fri 08 Apr 2022 at 23:44:29 (+0100), Brian wrote:
> > On Fri 08 Apr 2022 at 16:20:54 -0400, The Wanderer wrote:
> 
> > > What I understood Greg as asking about is how to get CUPS to *tell* you
> > > what the IP address it knows about for a given printer object is. That
> > > doesn't seem to be an unreasonable thing to want to know, or to expect
> > > CUPS to be able to provide; I'd want the same thing, in anything
> > > remotely like his place.
> > 
> > Finding the IP address is easy:
> > 
> >  ippfind -T 5
> >  ipp://envy4500.local:631/ipp/print
> >  ping -c 3 envy4500.local
> 
> Would the ping output give an IP address like the one quoted
> (10.76.172.100), or would you only get a 169.254/16 one?
> (I've not run an mDNS configured network.)

brian@desktop:$ ping -c 1 envy4500.local
PING envy4500.local (192.168.7.235) 56(84) bytes of data.
64 bytes from 192.168.7.235 (192.168.7.235): icmp_seq=1 ttl=255 time=31.3 ms

-- 
Brian.

Re: CUPS - how to match autodetected printers to physical ones

[Brian]

On Fri 08 Apr 2022 at 19:45:41 -0400, The Wanderer wrote:

> (This is probably both overly long and overly repetitive, among possibly
> other undesirable things, but I'm running short on time.)

So I hope you do not mind if I do not reply to every point you make.

> On 2022-04-08 at 18:44, Brian wrote:
> 
> > On Fri 08 Apr 2022 at 16:20:54 -0400, The Wanderer wrote:
> > 
> >> On 2022-04-08 at 15:52, Brian wrote:
> 
> >> > You didn't like my bus analogy, did you?
> >> > 
> >> > What makes you think that knowing a bus number and destination 
> >> > provudes information for where it departs from?
> >> > 
> >> > What makes you think that knowing an IP address tells you where any
> >> > machine of any description is located?
> >> 
> >> I'm confused as to why you might think anyone involved in this
> >> conversation thought that.
> >> 
> >> There's no reason to expect that knowing an IP address tells you the
> >> location of the device at the other end.
> > 
> > The OP explicitly associated IP address with physical location:
> > 
> >  > "Aha," I thought.  "All I have to do is figure out which one of the
> >  >  autodetected printers on this list has the same IP address as the 
> > printer
> >  >  that I can see and touch over there.
> > 
> > The user may be aware of the printer's location, but is the printing
> > system in possession of the same knowledge?
> 
> ...I do not follow your reasoning in parsing that statement. I do not
> see how that statement leads in any way to the conclusion that the
> printing system has, or must have, any knowledge of the printer's
> location.
> 
> Even if the printing system doesn't have any knowledge of the printer's
> physical location, it must still have some knowledge of the printer's
> *network* location, in the form of an IP address (or other routing
> information, such as in the print-server model described below).
> 
> What Greg was asking about, as far as I can tell, is a way to get CUPS
> to tell him that network-location information - so that he, as someone
> external to the printing system, could then apply that information to
> his additional knowledge about the physical location of the printer with
> a specific IP address.
> 
> I'm not sure we (in this thread) have yet found a way to do that
> directly; we've found what appear to be two different ways to find the
> IP address of the printer with the name that CUPS is reporting, but it
> looks to me as if both of them are getting that information via an
> external method (probably similar to how CUPS found the printer in the
> first place), rather than getting that information from CUPS itself.
> 
> The IP-address (etc.?) information must exist within CUPS, since CUPS is
> able to actually send jobs to the printer; why isn't it straightforward
> and obvious how to get that information *from* within CUPS *to*
> someplace visible?

It is straightforward, I don't know about obvious to all users.

  avahi-browse -rt _ipp._tcp  
 
> >> However, if CUPS did autodiscovery and found the printer, then it
> >> must know what the place is that it was looking at when it found
> >> that device.
> > 
> > By "place" do you mean physical place?
> 
> No. I mean, the place on the network where it got the information.
> (Which will presumably be a place which has an IP address.)
> 
> >> Unless I'm missing something, the options are that either CUPS
> >> found the printer in a list of printers being maintained somewhere
> >> else (e.g. a print server on the network), or CUPS found the
> >> printer on the network directly.
> > 
> > The same technique is used for both: mDNS/DNS-SD.
> 
> I find that plausible enough, but will have to take your word for it.
> 
> >> If CUPS found the printer on a list of printers being maintained 
> >> somewhere else, then it must have also found information about
> >> that "somewhere else", and that information might include an IP
> >> address.
> > 
> > "somewhere else" would have to be explained. It is not part of my
> > inderstanding.
> 
> I was referencing the same definition of "somewhere else" as used in the
> previous sentence, where I gave the example of a print server on the
> network.
> 
> I was thinking of the design in which a print server maintains a list of
> print queues, and serves as a proxy to receive print jobs and pass them
> to those print queues, so as to both avoid contention on the printer
> itself and facilitate central management of those print queues (rather
> than needing to manage them on the individual endpoints, whether the
> client computers or the printers).
> 
> In that case, as the print server would not hand out the IP addresses of
> the printers (since that would enable bypassing the server-side print
> queues), but would only hand out the combination of the server's IP
> address and the name of the print queue to specify when sending jobs to
> that printer via that print server, CUPS would not have access to the IP
> address of the printer itself.
> 
> (I could have swo

Re: On IP addresses and bus tripe [was: CUPS - how to match autodetected printers to physical ones]

[Brian]

On Sat 09 Apr 2022 at 08:33:31 +0200, to...@tuxteam.de wrote:

> On Fri, Apr 08, 2022 at 08:52:26PM +0100, Brian wrote:
> 
> [...]
> 
> > You didn't like my bus analogy, did you?
> 
> I did like it. Nevertheless, I thought something's missing:

In general, analogies don't really work, do they?
 
> > What makes you think that knowing a bus number and destination
> > provudes information for where it departs from?
> >
> > What makes you think that knowing an IP address tells you where
> > any machine of any description is located?
> 
> This is, of course, not guaranteed. But "the system" might provide
> for the user not being an idiot and perhaps having bits of info
> "the system" doesn't. 
> 
> In Greg's (was he the OP? I lost the thread in the process) case
> it's the IP address stuck on the printer (most printers these days
> tell you, if you ticke their menus for long enough, BTW).

Setting up a queue in some circumstances may require knowledge of
an IP address. Printing to it doesn't. The wrong path was taken.
 
> In the bus's case, perhaps there is a big sign on the parking lot
> "NEUF-BRISACH". There, that's your IP address.
> 
> Back to the printers, I'm horrified at the idea that CUPS doesn't
> tell you the IP address it thinks the printer is at. It's what
> I call "authoritarian software", where the software thinks it's
> smarter than me. Don't get me wrong, I like comfort like the next
> guy, but I don't like being treated like an idiot.

What is important for printing is the queue name (the destination)
an the URI. Cups will take care of all the nitty-gritty in getting
the job to the printer. A card with the queue name would have saved
much head scratching.

> Look: if some programmer gal thinks she's smarter than me, I go
> "arrogant gal, but who knows, probably she's right". But if a
> piece of software does that, I tend to kick it out of my box.
> My box, my rules :)
> 
> And yes: no CUPS (no Avahi either) on my box :-)

Avahi is not mandatory for printing. However, it does benefit many
users.

Plug in a mouse. It wors straightaway. Nobody gives it a secomd
thought. Nowadays, plug in a modern printer to USB and, with Avahi,
it is immediately available for printing. What is there to dislike?
People have been asking for this level of operation for years.

-- 
Brian.

Re: CUPS - how to match autodetected printers to physical ones

[Tixy]

On Sat, 2022-04-09 at 00:05 +0100, Brian wrote:
> On Fri 08 Apr 2022 at 21:07:18 +0100, Tixy wrote:
> 
> > On Fri, 2022-04-08 at 20:18 +0100, Brian wrote:
> > > On Fri 08 Apr 2022 at 17:59:10 +0100, Tixy wrote:
> > > 
> > > > On Fri, 2022-04-08 at 12:10 -0400, Greg Wooledge wrote:
> > > > > Unfortunately, I was not able to find ANY way to determine the IP
> > > > > addresses of the autodetected printers that were presented to me.
> > > > 
> > > > If I go to http://localhost:631/printers/ and click on my printer it
> > > > shows amongst other information:
> > > > 
> > > > Connection: socket://192.168.2.3:9100
> > > 
> > > OK. That's the destination.
> > > > 
> > > > In case it got that IP address because I configured it that way, I just
> > > > tried it on another computer that didn't previously have CUPS on until
> > > > I just installed it and it shows the same for an auto discovered
> > > > printer.
> > > 
> > > Do you find that surprising? The destination hasn't changed because you
> > > use another computer. You would be miffed if it did.
> > > 
> > 
> > I wasn't expecting a different IP address but, given Greg's experience,
> 
> I think we have a differnet understanding of what The OP's experience
> was.

Possibly, I thought his experience was that he couldn't see the IP
address for printers in GUI or command-line interfaces.

-- 
Tixy

On IP addresses and bus tripe [was: CUPS - how to match autodetected printers to physical ones]

[tomas]

On Fri, Apr 08, 2022 at 08:52:26PM +0100, Brian wrote:

[...]

> You didn't like my bus analogy, did you?

I did like it. Nevertheless, I thought something's missing:

> What makes you think that knowing a bus number and destination
> provudes information for where it departs from?
>
> What makes you think that knowing an IP address tells you where
> any machine of any description is located?

This is, of course, not guaranteed. But "the system" might provide
for the user not being an idiot and perhaps having bits of info
"the system" doesn't. 

In Greg's (was he the OP? I lost the thread in the process) case
it's the IP address stuck on the printer (most printers these days
tell you, if you ticke their menus for long enough, BTW).

In the bus's case, perhaps there is a big sign on the parking lot
"NEUF-BRISACH". There, that's your IP address.

Back to the printers, I'm horrified at the idea that CUPS doesn't
tell you the IP address it thinks the printer is at. It's what
I call "authoritarian software", where the software thinks it's
smarter than me. Don't get me wrong, I like comfort like the next
guy, but I don't like being treated like an idiot.

Look: if some programmer gal thinks she's smarter than me, I go
"arrogant gal, but who knows, probably she's right". But if a
piece of software does that, I tend to kick it out of my box.
My box, my rules :)

And yes: no CUPS (no Avahi either) on my box :-)

Cheers
-- 
t


signature.asc
Description: PGP signature

Re: CUPS - how to match autodetected printers to physical ones

[mick crane]

On 2022-04-08 17:10, Greg Wooledge wrote:

If you don't want to read the background information, the question is:

How is one *supposed* to figure out which autodetected printer is the
correct one, apart from trial and error?



I think you'd set up a printer on your machine with
'ipp://ip-address-of-print-server:631/printers/name-of-printer-as-written-on-sticker'
but you are saying that wasn't the exact name ?
There should be a way to query the print server of ip addresses by name.

cheers
mick

Re: CUPS - how to match autodetected printers to physical ones

[David Wright]

On Fri 08 Apr 2022 at 23:44:29 (+0100), Brian wrote:
> On Fri 08 Apr 2022 at 16:20:54 -0400, The Wanderer wrote:

> > What I understood Greg as asking about is how to get CUPS to *tell* you
> > what the IP address it knows about for a given printer object is. That
> > doesn't seem to be an unreasonable thing to want to know, or to expect
> > CUPS to be able to provide; I'd want the same thing, in anything
> > remotely like his place.
> 
> Finding the IP address is easy:
> 
>  ippfind -T 5
>  ipp://envy4500.local:631/ipp/print
>  ping -c 3 envy4500.local

Would the ping output give an IP address like the one quoted
(10.76.172.100), or would you only get a 169.254/16 one?
(I've not run an mDNS configured network.)

Cheers,
David.

Re: CUPS - how to match autodetected printers to physical ones

[The Wanderer]

(This is probably both overly long and overly repetitive, among possibly
other undesirable things, but I'm running short on time.)


On 2022-04-08 at 18:44, Brian wrote:

> On Fri 08 Apr 2022 at 16:20:54 -0400, The Wanderer wrote:
> 
>> On 2022-04-08 at 15:52, Brian wrote:

>> > You didn't like my bus analogy, did you?
>> > 
>> > What makes you think that knowing a bus number and destination 
>> > provudes information for where it departs from?
>> > 
>> > What makes you think that knowing an IP address tells you where any
>> > machine of any description is located?
>> 
>> I'm confused as to why you might think anyone involved in this
>> conversation thought that.
>> 
>> There's no reason to expect that knowing an IP address tells you the
>> location of the device at the other end.
> 
> The OP explicitly associated IP address with physical location:
> 
>  > "Aha," I thought.  "All I have to do is figure out which one of the
>  >  autodetected printers on this list has the same IP address as the printer
>  >  that I can see and touch over there.
> 
> The user may be aware of the printer's location, but is the printing
> system in possession of the same knowledge?

...I do not follow your reasoning in parsing that statement. I do not
see how that statement leads in any way to the conclusion that the
printing system has, or must have, any knowledge of the printer's
location.

Even if the printing system doesn't have any knowledge of the printer's
physical location, it must still have some knowledge of the printer's
*network* location, in the form of an IP address (or other routing
information, such as in the print-server model described below).

What Greg was asking about, as far as I can tell, is a way to get CUPS
to tell him that network-location information - so that he, as someone
external to the printing system, could then apply that information to
his additional knowledge about the physical location of the printer with
a specific IP address.

I'm not sure we (in this thread) have yet found a way to do that
directly; we've found what appear to be two different ways to find the
IP address of the printer with the name that CUPS is reporting, but it
looks to me as if both of them are getting that information via an
external method (probably similar to how CUPS found the printer in the
first place), rather than getting that information from CUPS itself.

The IP-address (etc.?) information must exist within CUPS, since CUPS is
able to actually send jobs to the printer; why isn't it straightforward
and obvious how to get that information *from* within CUPS *to*
someplace visible?

>> However, if CUPS did autodiscovery and found the printer, then it
>> must know what the place is that it was looking at when it found
>> that device.
> 
> By "place" do you mean physical place?

No. I mean, the place on the network where it got the information.
(Which will presumably be a place which has an IP address.)

>> Unless I'm missing something, the options are that either CUPS
>> found the printer in a list of printers being maintained somewhere
>> else (e.g. a print server on the network), or CUPS found the
>> printer on the network directly.
> 
> The same technique is used for both: mDNS/DNS-SD.

I find that plausible enough, but will have to take your word for it.

>> If CUPS found the printer on a list of printers being maintained 
>> somewhere else, then it must have also found information about
>> that "somewhere else", and that information might include an IP
>> address.
> 
> "somewhere else" would have to be explained. It is not part of my
> inderstanding.

I was referencing the same definition of "somewhere else" as used in the
previous sentence, where I gave the example of a print server on the
network.

I was thinking of the design in which a print server maintains a list of
print queues, and serves as a proxy to receive print jobs and pass them
to those print queues, so as to both avoid contention on the printer
itself and facilitate central management of those print queues (rather
than needing to manage them on the individual endpoints, whether the
client computers or the printers).

In that case, as the print server would not hand out the IP addresses of
the printers (since that would enable bypassing the server-side print
queues), but would only hand out the combination of the server's IP
address and the name of the print queue to specify when sending jobs to
that printer via that print server, CUPS would not have access to the IP
address of the printer itself.

(I could have sworn that I'd found this arrangement documented somewhere
in the past, but at the moment I can't completely rule out that it's
anything other than the product of my vivid imagination. It seems like a
coherent and sane design to my immediate eye, however.)

>> If CUPS found the printer on the network directly, then it
>> certainly also found the printer's IP address.
> 
> Indeed. But that information does not give the physical location 

Re: CUPS - how to match autodetected printers to physical ones

[Greg Wooledge]

On Sat, Apr 09, 2022 at 12:05:01AM +0100, Brian wrote:
> On Fri 08 Apr 2022 at 21:07:18 +0100, Tixy wrote:
> > I wasn't expecting a different IP address but, given Greg's experience,
> 
> I think we have a differnet understanding of what The OP's experience
> was.

I knew the printer's IP address before I even touched CUPS.  It was
prominently displayed on the device itself.  It was the one thing I
didn't have to guess at during the entire adventure.(*)

In all of my experience working with printers BEFORE the CUPS/Avahi
thing came along, knowing the IP address of the network printer was
the first, fundamental step.  When you set up the printer device in
Unix, using lprng or whatever it was at the time, that was where you
started.  Here's the IP address, now add it to DNS so it has a name,
and then add a printer device that uses that hostname.

In CUPS/Avahi, apparently you aren't supposed to do things in that way,
because it would be too obvious.

Fortunately, there are low-level commands that allow you to bypass
the "right way of doing things" and get at the information you need to
actually make the thing *work*.  (Or if you don't know those commands
yet, there's still trial and error.)

(*) Remember, I had an entry in DNS pointing to that IP address already.
The IP address *predated the printer device*.  It was surely associated
with the previous printer that was in that spot.  Whoever installed this
printer was probably told to report its MAC address to the DHCP admin
so they could assign the old printer's IP address to the new printer.

Re: CUPS - how to match autodetected printers to physical ones

[Brian]

On Fri 08 Apr 2022 at 21:07:18 +0100, Tixy wrote:

> On Fri, 2022-04-08 at 20:18 +0100, Brian wrote:
> > On Fri 08 Apr 2022 at 17:59:10 +0100, Tixy wrote:
> > 
> > > On Fri, 2022-04-08 at 12:10 -0400, Greg Wooledge wrote:
> > > > Unfortunately, I was not able to find ANY way to determine the IP
> > > > addresses of the autodetected printers that were presented to me.
> > > 
> > > If I go to http://localhost:631/printers/ and click on my printer it
> > > shows amongst other information:
> > > 
> > > Connection:   socket://192.168.2.3:9100
> > 
> > OK. That's the destination.
> > > 
> > > In case it got that IP address because I configured it that way, I just
> > > tried it on another computer that didn't previously have CUPS on until
> > > I just installed it and it shows the same for an auto discovered
> > > printer.
> > 
> > Do you find that surprising? The destination hasn't changed because you
> > use another computer. You would be miffed if it did.
> > 
> 
> I wasn't expecting a different IP address but, given Greg's experience,

I think we have a differnet understanding of what The OP's experience
was.

> it might have shown no address at all if it was auto discovered as
> opposed to being configured by specifying an address. (Which is what I
> thought I had done.) 

Printer discovery results in no address (URI) being known? Just because
it wasn't manually configured? Where would the print job go? Discovery
would be useless.

-- 
Brian,

Re: CUPS - how to match autodetected printers to physical ones

[Brian]

On Fri 08 Apr 2022 at 16:20:54 -0400, The Wanderer wrote:

> On 2022-04-08 at 15:52, Brian wrote:
> 
> > On Fri 08 Apr 2022 at 15:22:58 -0400, Greg Wooledge wrote:
> > 
> >> On Fri, Apr 08, 2022 at 08:08:22PM +0100, Brian wrote:
> 
> >>> Now contact you highly paid sys admins to ask them to add a
> >>> "Location" field to whatever the server/printer is advertising.
> >> 
> >> So... if your corporate network is not set up in the way that
> >> Brian expects, there is simply nothing you can do about it.  You're
> >> just screwed, and must resort to trial and error to figure out
> >> where the printers are.  Even though CUPS can magically contact the
> >> printers, it will refuse to tell you how it does that, because of
> >> some kind of policy decision.
> > 
> > You didn't like my bus analogy, did you?
> > 
> > What makes you think that knowing a bus number and destination 
> > provudes information for where it departs from?
> > 
> > What makes you think that knowing an IP address tells you where any
> > machine of any description is located?
> 
> I'm confused as to why you might think anyone involved in this
> conversation thought that.
> 
> There's no reason to expect that knowing an IP address tells you the
> location of the device at the other end.

The OP explicitly associated IP address with physical location:

 > "Aha," I thought.  "All I have to do is figure out which one of the
 >  autodetected printers on this list has the same IP address as the printer
 >  that I can see and touch over there.

The user may be aware of the printer's location, but is the printing
system in possession of the same knowledge?

> However, if CUPS did autodiscovery and found the printer, then it must
> know what the place is that it was looking at when it found that device.

By "place" do you mean physical place?

> Unless I'm missing something, the options are that either CUPS found the
> printer in a list of printers being maintained somewhere else (e.g. a
> print server on the network), or CUPS found the printer on the network
> directly.

The same technique is used for both: mDNS/DNS-SD.
> 
> If CUPS found the printer on a list of printers being maintained
> somewhere else, then it must have also found information about that
> "somewhere else", and that information might include an IP address.

"somewhere else" would have to be explained. It is not part of my
inderstanding.
 
> If CUPS found the printer on the network directly, then it certainly
> also found the printer's IP address.

Indeed. But that information does not give the physical location of

 > ...the printer that I can see and touch over there.

> Regardless, if CUPS can send a print job to the printer, then it must
> have some information to be able to route the job towards that
> destination - and that information will certainly include an IP address
> at some point along the way, either that of the printer or of the print
> server or of some other intermediary system.

CUPS knows how to route the job. The physical location of the printer
is not involved in the routeing.

> What I understood Greg as asking about is how to get CUPS to *tell* you
> what the IP address it knows about for a given printer object is. That
> doesn't seem to be an unreasonable thing to want to know, or to expect
> CUPS to be able to provide; I'd want the same thing, in anything
> remotely like his place.

Finding the IP address is easy:

 ippfind -T 5
 ipp://envy4500.local:631/ipp/print
 ping -c 3 envy4500.local

If you were in his place, you should hope that the sys admins would
include the physical location of the printer when advertising it. This
is part of the IPP standard. It could then be matched with the IP.
 
> If the printer happens to be one from a central print server, CUPS might
> not have its IP address locally - but being able to get the information
> for that print server (whether IP address or hostname or whatever else),
> along with the identifier used on that print server for the printer,
> might well be enough to make it possible to proceed forward anyway.

Of course.

-- 
Brian.

Re: CUPS - how to match autodetected printers to physical ones

[Greg Wooledge]

On Fri, Apr 08, 2022 at 08:52:26PM +0100, Brian wrote:
> You didn't like my bus analogy, did you?

I don't think it's a very good analogy for this situation.

> What makes you think that knowing an IP address tells you where
> any machine of any description is located?

Because the device is (was) sitting 50 feet away from me, and even
if the people who installed it had not been kind enough to print some
kind of config page and attach it to the front of the printer, I could
have Googled the printer's model number and found out how to print the
printer's own config page myself.  Or else how to scroll through the
printer's control panel menus to find its IP address that way.

The printer's brand, model and IP address are the extremely concrete
pieces of information that I can readily acquire and compare.  Software
that refuses to divulge useful information is not acting in a helpful
manner.

Also, completely coincidentally, I happen to know how the corporate
network is subdivided -- at least in the building that I work in.
Each floor has a /23 network assigned to it.  So, from the IP address
alone, I can at least tell whether the device is on my floor.  If I
need more specific location info than that, I would either have to call
someone, or search manually.

> Trial and error is not neeed. Just an IT department with basic
> skills and the intention to help users would suffice.

I wonder how many IT departments match both parts of that description.

In any case, "avahi-browse -rt _ipp._tcp" was helpful and useful, so
thank you for that.  I've typed it into my notes for next time I need it.

Re: CUPS - how to match autodetected printers to physical ones

[The Wanderer]

On 2022-04-08 at 15:52, Brian wrote:

> On Fri 08 Apr 2022 at 15:22:58 -0400, Greg Wooledge wrote:
> 
>> On Fri, Apr 08, 2022 at 08:08:22PM +0100, Brian wrote:

>>> Now contact you highly paid sys admins to ask them to add a
>>> "Location" field to whatever the server/printer is advertising.
>> 
>> So... if your corporate network is not set up in the way that
>> Brian expects, there is simply nothing you can do about it.  You're
>> just screwed, and must resort to trial and error to figure out
>> where the printers are.  Even though CUPS can magically contact the
>> printers, it will refuse to tell you how it does that, because of
>> some kind of policy decision.
> 
> You didn't like my bus analogy, did you?
> 
> What makes you think that knowing a bus number and destination 
> provudes information for where it departs from?
> 
> What makes you think that knowing an IP address tells you where any
> machine of any description is located?

I'm confused as to why you might think anyone involved in this
conversation thought that.

There's no reason to expect that knowing an IP address tells you the
location of the device at the other end.

However, if CUPS did autodiscovery and found the printer, then it must
know what the place is that it was looking at when it found that device.

Unless I'm missing something, the options are that either CUPS found the
printer in a list of printers being maintained somewhere else (e.g. a
print server on the network), or CUPS found the printer on the network
directly.

If CUPS found the printer on a list of printers being maintained
somewhere else, then it must have also found information about that
"somewhere else", and that information might include an IP address.

If CUPS found the printer on the network directly, then it certainly
also found the printer's IP address.

Regardless, if CUPS can send a print job to the printer, then it must
have some information to be able to route the job towards that
destination - and that information will certainly include an IP address
at some point along the way, either that of the printer or of the print
server or of some other intermediary system.

What I understood Greg as asking about is how to get CUPS to *tell* you
what the IP address it knows about for a given printer object is. That
doesn't seem to be an unreasonable thing to want to know, or to expect
CUPS to be able to provide; I'd want the same thing, in anything
remotely like his place.

If the printer happens to be one from a central print server, CUPS might
not have its IP address locally - but being able to get the information
for that print server (whether IP address or hostname or whatever else),
along with the identifier used on that print server for the printer,
might well be enough to make it possible to proceed forward anyway.

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man. -- George Bernard Shaw



signature.asc
Description: OpenPGP digital signature

Re: CUPS - how to match autodetected printers to physical ones

[Tixy]

On Fri, 2022-04-08 at 20:18 +0100, Brian wrote:
> On Fri 08 Apr 2022 at 17:59:10 +0100, Tixy wrote:
> 
> > On Fri, 2022-04-08 at 12:10 -0400, Greg Wooledge wrote:
> > > Unfortunately, I was not able to find ANY way to determine the IP
> > > addresses of the autodetected printers that were presented to me.
> > 
> > If I go to http://localhost:631/printers/ and click on my printer it
> > shows amongst other information:
> > 
> > Connection: socket://192.168.2.3:9100
> 
> OK. That's the destination.
> > 
> > In case it got that IP address because I configured it that way, I just
> > tried it on another computer that didn't previously have CUPS on until
> > I just installed it and it shows the same for an auto discovered
> > printer.
> 
> Do you find that surprising? The destination hasn't changed because you
> use another computer. You would be miffed if it did.
> 

I wasn't expecting a different IP address but, given Greg's experience,
it might have shown no address at all if it was auto discovered as
opposed to being configured by specifying an address. (Which is what I
thought I had done.) 

-- 
Tixy

Re: CUPS - how to match autodetected printers to physical ones

[Greg Wooledge]

On Fri, Apr 08, 2022 at 08:24:00PM +0100, Brian wrote:
>   avahi-browse -rt _ipp._tcp
> 
> is better.

That one actually works.  It completes in under 1 second, and it
includes IP addresses in its output.

Out of curiosity, I tried omitting the -r option, to try to figure out
what "resolve" means in this context.  The result was simply a list of
the top-level names, without any of the associated details such as
their IP addresses.  So it seems "resolve services" means "provide
details about each thing found, instead of simply reporting its name".

(I find that confusing, because "resolve" usually means "report a
human-readable name rather than a number", but so be it.)

Re: CUPS - how to match autodetected printers to physical ones

[Brian]

On Fri 08 Apr 2022 at 15:22:58 -0400, Greg Wooledge wrote:

> On Fri, Apr 08, 2022 at 08:08:22PM +0100, Brian wrote:
> > On Fri 08 Apr 2022 at 12:10:37 -0400, Greg Wooledge wrote:
> > > How is one *supposed* to figure out which autodetected printer is the
> > > correct one, apart from trial and error?
> 
> > Now contact you highly paid sys admins to ask them to add a "Location"
> > field to whatever the server/printer is advertising.
> 
> So... if your corporate network is not set up in the way that Brian
> expects, there is simply nothing you can do about it.  You're just
> screwed, and must resort to trial and error to figure out where
> the printers are.  Even though CUPS can magically contact the printers,
> it will refuse to tell you how it does that, because of some kind of
> policy decision.

You didn't like my bus analogy, did you?

What makes you think that knowing a bus number and destination
provudes information for where it departs from?

What makes you think that knowing an IP address tells you where
any machine of any description is located?

Trial and error is not neeed. Just an IT department with basic
skills and the intention to help users would suffice.

-- 
Brian.

Re: CUPS - how to match autodetected printers to physical ones

[David Wright]

On Fri 08 Apr 2022 at 15:30:13 (-0400), Greg Wooledge wrote:
> On Fri, Apr 08, 2022 at 08:28:31PM +0200, didier gaumet wrote:
> > CLI:
> > 
> > # avahi-browse -r _print-caps._tcp
> > (from the avahi-utils package) 
> 
> I tried this with and without the -r (which according to the man page
> asks to "resolve services", but it doesn't say what kind of resolution
> it's doing).
> 
> In both cases, after waiting a few minutes and seeing no output, I
> simply terminated the process.  I don't know what it's doing, or why
> it takes so long, but I'm afraid that if it happens to be generating a
> packet storm, I might get in trouble.

If your position is secure, that might be the way to get things
changed: trouble.

Cheers,
David.

Re: CUPS - how to match autodetected printers to physical ones

[David Wright]

On Fri 08 Apr 2022 at 15:22:58 (-0400), Greg Wooledge wrote:
> On Fri, Apr 08, 2022 at 08:08:22PM +0100, Brian wrote:
> > On Fri 08 Apr 2022 at 12:10:37 -0400, Greg Wooledge wrote:
> > > How is one *supposed* to figure out which autodetected printer is the
> > > correct one, apart from trial and error?
> 
> > Now contact you highly paid sys admins to ask them to add a "Location"
> > field to whatever the server/printer is advertising.
> 
> So... if your corporate network is not set up in the way that Brian
> expects, there is simply nothing you can do about it.  You're just
> screwed, and must resort to trial and error to figure out where
> the printers are.  Even though CUPS can magically contact the printers,
> it will refuse to tell you how it does that, because of some kind of
> policy decision.

It's an odd policy decision to pay someone to write IP addresses on
printers rather than the name(s) of the queue(s) that they serve.
It does look as if all the information that is published for/on these
printers is for the benefit of the support staff and not the users.

Cheers,
David.

Re: CUPS - how to match autodetected printers to physical ones

[Fred]

On 4/8/22 10:22, Greg Wooledge wrote:

On Fri, Apr 08, 2022 at 06:03:47PM +0100, Tixy wrote:

On Fri, 2022-04-08 at 17:59 +0100, Tixy wrote:

On Fri, 2022-04-08 at 12:10 -0400, Greg Wooledge wrote:

Unfortunately, I was not able to find ANY way to determine the IP
addresses of the autodetected printers that were presented to me.


If I go to http://localhost:631/printers/


I should say I got to that URL from the CUPs interface at
http://localhost:631/ then clicking the 'Admininitation' tab at the top
followed by the 'Manage Printers' button on the page that showed.


Here is what I have on that page:

=
Showing 7 of 7 printers.

Queue Name  Description LocationMake and Model  Status
Canon_LBP351dn_f9_7a_4a_CNLBP712C CNLBP712C, 
driverless, cups-filters 1.28.7Idle
Canon_LBP712Cdn_db_c0_d3_   Canon_LBP712Cdn_db_c0_d3_   
CNLBP712C CNLBP712C, driverless, cups-filters 1.28.7Idle
Cups_PDF_oc3261540276   Cups_PDF_oc3261540276   Local Raw Printer   
Paused
HP_LaserJet_4100_Series_0001E6A68D3D_   HP_LaserJet_4100_Series_0001E6A68D3D_   
HP LaserJet 4100 Series , driverless, cups-filters 1.28.7   Idle
hp_LaserJet_4250_621E13_hp_LaserJet_4250_621E13_hp 
LaserJet 4250, driverless, cups-filters 1.28.7   Idle
HP_LaserJet_P3010_Series_0FCDD7_HP_LaserJet_P3010_Series_0FCDD7_
HP LaserJet P3010 Series, driverless, cups-filters 1.28.7   Idle
PostScript_oc3261540276 PostScript_oc3261540276 Local Raw Printer   
Paused
=

Of course it looks like crap when I just paste the text from the web
page into an email.  But if you ignore the horrible formatting, you
can see there are NO IP addresses here.

If I go to a single printer's page, I get text like this:

=
Canon_LBP351dn_f9_7a_4a_
Canon_LBP351dn_f9_7a_4a_ (Idle, Accepting Jobs, Not Shared, Server Default)

Maintenance
  
Administration
Description:
Location:   
Driver: CNLBP712C CNLBP712C, driverless, cups-filters 1.28.7 (color, 2-sided 
printing)
Connection: implicitclass://Canon_LBP351dn_f9_7a_4a_/
Defaults:   job-sheets=none, none media=na_letter_8.5x11in sides=one-sided
=

Maybe I need to amend the question to "How is one supposed to figure out
which autodetected printer is which IN A CORPORATE NETWORK OF UNKNOWN
PROVENANCE?"  I don't know what I need to say to convey to you that
my workplace's network DOES NOT work like what you see on yours.

Looking at the stuff that I pasted here, how am I supposed to know whether
this corresponds to the physical printer with IP address 10.76.172.100?


Have you tried asking the IT dept.?

Best regards,
Fred

Re: CUPS - how to match autodetected printers to physical ones

[Greg Wooledge]

On Fri, Apr 08, 2022 at 08:28:31PM +0200, didier gaumet wrote:
> CLI:
> 
> # avahi-browse -r _print-caps._tcp
> (from the avahi-utils package) 

I tried this with and without the -r (which according to the man page
asks to "resolve services", but it doesn't say what kind of resolution
it's doing).

In both cases, after waiting a few minutes and seeing no output, I
simply terminated the process.  I don't know what it's doing, or why
it takes so long, but I'm afraid that if it happens to be generating a
packet storm, I might get in trouble.

Re: CUPS - how to match autodetected printers to physical ones

[David Wright]

On Fri 08 Apr 2022 at 20:08:22 (+0100), Brian wrote:
> On Fri 08 Apr 2022 at 12:10:37 -0400, Greg Wooledge wrote:

> > How is one *supposed* to figure out which autodetected printer is the
> > correct one, apart from trial and error?
> 
> Fancy an analogy?
> 
> My local bus intercange has display screens showing bus nummbers and
> destinations (IP addresses). It does not display the stands the buses
> start from. Whose responsibillity is that down to?
> 
> You got it!
> 
> Now contact you highly paid sys admins to ask them to add a "Location"
> field to whatever the server/printer is advertising.

Where I used to work, they got this right: they put /user/ information
into the Queue name, where it can't but be seen, using the pattern
DeptRoom_unusualCharacteristics.

So MathsB037 might be an ordinary one (A4 B&W), and PhysicsS221_A3_colour_foil
would be something rather special, that might only operate at certain
times of day when they load the foil.

Cheers,
David.

Re: CUPS - how to match autodetected printers to physical ones

[Brian]

On Fri 08 Apr 2022 at 20:28:31 +0200, didier gaumet wrote:

> Hello Greg,
> 
> Perhaps, try: 
> 
> GUI:
> 
> avahi-discover from the avahi-discover package presents a network tree:
> you can find the IP adresses of the printers
> 
> CLI:
> 
> # avahi-browse -r _print-caps._tcp
> (from the avahi-utils package) 
> In my case it's sufficient to detect my network printer but I do not
> know well avahi service types (here: _print-caps._tcp, seems to be
> printer capabilities at the TCP level)
> if you do not find your printers try a more general search:
> # avahi-browse -avr
> and explore the results

  avahi-browse -rt _ipp._tcp

is better.

This also gives the location of a printer if a highly paid sys admin
can be arsed to supply it.

-- 
Brian.

Re: CUPS - how to match autodetected printers to physical ones

[Greg Wooledge]

On Fri, Apr 08, 2022 at 08:08:22PM +0100, Brian wrote:
> On Fri 08 Apr 2022 at 12:10:37 -0400, Greg Wooledge wrote:
> > How is one *supposed* to figure out which autodetected printer is the
> > correct one, apart from trial and error?

> Now contact you highly paid sys admins to ask them to add a "Location"
> field to whatever the server/printer is advertising.

So... if your corporate network is not set up in the way that Brian
expects, there is simply nothing you can do about it.  You're just
screwed, and must resort to trial and error to figure out where
the printers are.  Even though CUPS can magically contact the printers,
it will refuse to tell you how it does that, because of some kind of
policy decision.

Re: CUPS - how to match autodetected printers to physical ones

[Brian]

On Fri 08 Apr 2022 at 17:59:10 +0100, Tixy wrote:

> On Fri, 2022-04-08 at 12:10 -0400, Greg Wooledge wrote:
> > Unfortunately, I was not able to find ANY way to determine the IP
> > addresses of the autodetected printers that were presented to me.
> 
> If I go to http://localhost:631/printers/ and click on my printer it
> shows amongst other information:
> 
> Connection:   socket://192.168.2.3:9100

OK. That's the destination.
> 
> In case it got that IP address because I configured it that way, I just
> tried it on another computer that didn't previously have CUPS on until
> I just installed it and it shows the same for an auto discovered
> printer.

Do you find that surprising? The destination hasn't changed because you
use another computer. You would be miffed if it did.
> 
> -- 
> Tixy
> 

Re: CUPS - how to match autodetected printers to physical ones

[Brian]

On Fri 08 Apr 2022 at 12:10:37 -0400, Greg Wooledge wrote:

[Misconceptions snipped. It would take too long to comment on and refute
every single one of them, interesting though they may be.]

> After all this, I have two final comments:
> 
> 1) To whomever received two surprise printer test pages: sorry.
> 2) I FUCKING HATE PRINTERS!

You are pointing the finger in the wrong direction. (As recent political
events show, this is seen as a good technique to draw attention from the
actual state of affairs).
> 
> And I have one question:
> 
> How is one *supposed* to figure out which autodetected printer is the
> correct one, apart from trial and error?

Fancy an analogy?

My local bus intercange has display screens showing bus nummbers and
destinations (IP addresses). It does not display the stands the buses
start from. Whose responsibillity is that down to?

You got it!

Now contact you highly paid sys admins to ask them to add a "Location"
field to whatever the server/printer is advertising.

-- 
Brian.
> 

Re: CUPS - how to match autodetected printers to physical ones

[didier gaumet]

Hello Greg,

Perhaps, try: 

GUI:

avahi-discover from the avahi-discover package presents a network tree:
you can find the IP adresses of the printers

CLI:

# avahi-browse -r _print-caps._tcp
(from the avahi-utils package) 
In my case it's sufficient to detect my network printer but I do not
know well avahi service types (here: _print-caps._tcp, seems to be
printer capabilities at the TCP level)
if you do not find your printers try a more general search:
# avahi-browse -avr
and explore the results