Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
CUPS - how to match autodetected printers to physical ones
328 views
Skip to first unread message
Greg Wooledge
Apr 8, 2022, 12:20:05 PM4/8/22
to
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?
==========================================================================
Today I had to print something at work (on site). This happens roughly
once a year.
There is one physical printer in my work area. That I know of. However,
the network is much larger than my single work area. It spans many
floors of many buildings.
So, when I got there, I logged into my Debian 11 box, and ran "lpstat -t"
to see if I already had a default printer set up. I did not. However,
lpstat -t gave me a list of several autodetected printers.
"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."
Unfortunately, I was not able to find ANY way to determine the IP
addresses of the autodetected printers that were presented to me.
I tried a few Google searches, but almost all of the results I got were
ass-backwards. They kept trying to teach me how to learn the IP address
of my printer. (The other search results simply didn't work.)
But I already KNEW the IP address of the printer. It's on a piece of
paper that's attached to the front of the printer. I could ping the IP
address. I could look up the IP address in /usr/sbin/arp and get the
MAC address of the printer too. I even had an entry in *my* DNS subdomain
that mapped a name to this IP address.
None of that helped me in any way.
Next, I Googled the port number for the CUPS web interface, because for
some reason "grep cups /etc/services" gives nothing. (Turns out it's 631.
I can never remember it, because I only have to deal with it once every
year or two or three.)
I went into the CUPS web interface, and tried to get *it* to tell me
the IP addresses of the autodetected printers that it clearly knows about.
I could not find anything in the CUPS web interface that would show me
an IP address for a single printer.
Some of the printers had three hex bytes in their names, like
"Canon_LBP712Cdn_db_c0_d3_".
"Perhaps," I thought, "these hex digits are the right-hand side of a MAC
address."
Unfortunately, no, none of the hex digits on the ends of these printer
names matched any part of the MAC address of the printer. I have no
idea *what* they are.
"Perhaps," I thought, "this printer name is an entry in one of the
corporate DNS domains."
Unfortunately, no, I could not find Canon_LBP712Cdn_db_c0_d3_ with or
without the trailing _ in either of the two corporate DNS domains that
I know of.
So the next thing I tried was matching the printer's brand and model
against the names in the list, to see which one was the closest match.
According to the piece of paper on the front of the printer, it was
a Canon LBP 712 Cdn printer. So, naturally, I thought that the
autodetected printer named Canon_LBP712Cdn_db_c0_d3_ might be the
right one.
So I sent a test page to it.
Nothing happened, that I could see. Certainly no paper emerged from the
physical printer.
One of the light-buttons on top of the printer was lit up. Sticking my
head into the cabinet so that I could see what the hell the button labels
said, it turns out the printer was in energy saving mode. I found some
buttons and pressed them and eventually got it into "ready mode", or
whatever it's called.
Still, nothing happened.
I sent a second test page to it.
And still, nothing happened.
At this point I was starting to get really frustrated. I kept searching
Google and typing random commands and clicking random things in the CUPS
web interface, trying to figure out HOW TO FIGURE OUT which printer is
which.
Nothing worked. There was NO WAY to tell which printer was which!
There is simply no way, discoverable by me, that I can tell CUPS "Hey, I
have the IP address of a printer that you should already know about.
Tell me which printer that you already know about has this IP address."
I even tried ADDING a new printer to CUPS, using the IP address. I
have no idea how to do this, so I clicked random shit trying to make it
work. I selected "ipp" because it sounded like the least-frills
option. It said that I had to construct a URL for my printer, and it
gave many examples, like ipp://hostname/port1 and so on, but it did not
tell me HOW TO FIGURE OUT what URL I should give.
So I gave it ipp://10.76.172.100 and tried to print a test page to it.
It didn't work. No paper came out of the printer.
It kept saying the job was being processed, and that it was "connecting
to printer" (or "connected"?). It kept giving me a larger and larger
page count for the single test page. After it told me the page count
was 300-something, I canceled the job.
At this point, I had completely run out of ideas. All I was left with
was TRIAL AND ERROR.
Since the autodetected printer whose name precisely matched the physical
printer's brand and model didn't work, I went with the printer that
was the second closest match. I sent a test page to it.
THAT one worked. A piece of paper emerged from the printer, with ink
markings on it. They looked reasonably correct.
So I told CUPS to make this printer the system default, and printed
the single-page document I needed to print, and left.
After I left, I pondered whether I could have determined which printer
it was by disconnecting the network cable from it, waiting a bit, and
seeing which printer showed up as "not working" in the CUPS list. But
I didn't try that, and it sounds a bit risky.
After all this, I have two final comments:
1) To whomever received two surprise printer test pages: sorry.
2) I FUCKING HATE PRINTERS!
And I have one question:
How is one *supposed* to figure out which autodetected printer is the
correct one, apart from trial and error?
How is one *supposed* to figure out which autodetected printer is the
correct one, apart from trial and error?
==========================================================================
Today I had to print something at work (on site). This happens roughly
once a year.
There is one physical printer in my work area. That I know of. However,
the network is much larger than my single work area. It spans many
floors of many buildings.
So, when I got there, I logged into my Debian 11 box, and ran "lpstat -t"
to see if I already had a default printer set up. I did not. However,
lpstat -t gave me a list of several autodetected printers.
"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."
Unfortunately, I was not able to find ANY way to determine the IP
addresses of the autodetected printers that were presented to me.
I tried a few Google searches, but almost all of the results I got were
ass-backwards. They kept trying to teach me how to learn the IP address
of my printer. (The other search results simply didn't work.)
But I already KNEW the IP address of the printer. It's on a piece of
paper that's attached to the front of the printer. I could ping the IP
address. I could look up the IP address in /usr/sbin/arp and get the
MAC address of the printer too. I even had an entry in *my* DNS subdomain
that mapped a name to this IP address.
None of that helped me in any way.
Next, I Googled the port number for the CUPS web interface, because for
some reason "grep cups /etc/services" gives nothing. (Turns out it's 631.
I can never remember it, because I only have to deal with it once every
year or two or three.)
I went into the CUPS web interface, and tried to get *it* to tell me
the IP addresses of the autodetected printers that it clearly knows about.
I could not find anything in the CUPS web interface that would show me
an IP address for a single printer.
Some of the printers had three hex bytes in their names, like
"Canon_LBP712Cdn_db_c0_d3_".
"Perhaps," I thought, "these hex digits are the right-hand side of a MAC
address."
Unfortunately, no, none of the hex digits on the ends of these printer
names matched any part of the MAC address of the printer. I have no
idea *what* they are.
"Perhaps," I thought, "this printer name is an entry in one of the
corporate DNS domains."
Unfortunately, no, I could not find Canon_LBP712Cdn_db_c0_d3_ with or
without the trailing _ in either of the two corporate DNS domains that
I know of.
So the next thing I tried was matching the printer's brand and model
against the names in the list, to see which one was the closest match.
According to the piece of paper on the front of the printer, it was
a Canon LBP 712 Cdn printer. So, naturally, I thought that the
autodetected printer named Canon_LBP712Cdn_db_c0_d3_ might be the
right one.
So I sent a test page to it.
Nothing happened, that I could see. Certainly no paper emerged from the
physical printer.
One of the light-buttons on top of the printer was lit up. Sticking my
head into the cabinet so that I could see what the hell the button labels
said, it turns out the printer was in energy saving mode. I found some
buttons and pressed them and eventually got it into "ready mode", or
whatever it's called.
Still, nothing happened.
I sent a second test page to it.
And still, nothing happened.
At this point I was starting to get really frustrated. I kept searching
Google and typing random commands and clicking random things in the CUPS
web interface, trying to figure out HOW TO FIGURE OUT which printer is
which.
Nothing worked. There was NO WAY to tell which printer was which!
There is simply no way, discoverable by me, that I can tell CUPS "Hey, I
have the IP address of a printer that you should already know about.
Tell me which printer that you already know about has this IP address."
I even tried ADDING a new printer to CUPS, using the IP address. I
have no idea how to do this, so I clicked random shit trying to make it
work. I selected "ipp" because it sounded like the least-frills
option. It said that I had to construct a URL for my printer, and it
gave many examples, like ipp://hostname/port1 and so on, but it did not
tell me HOW TO FIGURE OUT what URL I should give.
So I gave it ipp://10.76.172.100 and tried to print a test page to it.
It didn't work. No paper came out of the printer.
It kept saying the job was being processed, and that it was "connecting
to printer" (or "connected"?). It kept giving me a larger and larger
page count for the single test page. After it told me the page count
was 300-something, I canceled the job.
At this point, I had completely run out of ideas. All I was left with
was TRIAL AND ERROR.
Since the autodetected printer whose name precisely matched the physical
printer's brand and model didn't work, I went with the printer that
was the second closest match. I sent a test page to it.
THAT one worked. A piece of paper emerged from the printer, with ink
markings on it. They looked reasonably correct.
So I told CUPS to make this printer the system default, and printed
the single-page document I needed to print, and left.
After I left, I pondered whether I could have determined which printer
it was by disconnecting the network cable from it, waiting a bit, and
seeing which printer showed up as "not working" in the CUPS list. But
I didn't try that, and it sounds a bit risky.
After all this, I have two final comments:
1) To whomever received two surprise printer test pages: sorry.
2) I FUCKING HATE PRINTERS!
And I have one question:
How is one *supposed* to figure out which autodetected printer is the
correct one, apart from trial and error?
Tixy
Apr 8, 2022, 1:00:05 PM4/8/22
to
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
> Unfortunately, I was not able to find ANY way to determine the IP
> addresses of the autodetected printers that were presented to me.
shows amongst other information:
Connection: socket://192.168.2.3:9100
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.
--
Tixy
Tixy
Apr 8, 2022, 1:10:05 PM4/8/22
to
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
> 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/
http://localhost:631/ then clicking the 'Admininitation' tab at the top
followed by the 'Manage Printers' button on the page that showed.
--
Tixy
Greg Wooledge
Apr 8, 2022, 1:30:05 PM4/8/22
to
=====================================================================
Showing 7 of 7 printers.
Queue Name Description Location Make and Model Status
Canon_LBP351dn_f9_7a_4a_ CNLBP712C CNLBP712C, driverless, cups-filters 1.28.7 Idle
Canon_LBP712Cdn_db_c0_d3_ Canon_LBP712Cdn_db_c0_d3_ CNLBP712C CNLBP712C, driverless, cups-filters 1.28.7 Idle
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?
didier gaumet
Apr 8, 2022, 2:30:05 PM4/8/22
to
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
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
Brian
Apr 8, 2022, 3:10:05 PM4/8/22
to
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).
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.
>
[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!
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?
> And I have one question:
>
> How is one *supposed* to figure out which autodetected printer is the
> correct one, apart from trial and error?
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.
>
Brian
Apr 8, 2022, 3:20:06 PM4/8/22
to
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.
> 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
>
> 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
> 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.
use another computer. You would be miffed if it did.
>
> --
> Tixy
>
David Wright
Apr 8, 2022, 3:30:05 PM4/8/22
to
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.
Brian
Apr 8, 2022, 3:30:05 PM4/8/22
to
is better.
This also gives the location of a printer if a highly paid sys admin
can be arsed to supply it.
--
Brian.
Greg Wooledge
Apr 8, 2022, 3:30:05 PM4/8/22
to
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?
> 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
> field to whatever the server/printer is advertising.
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.
David Wright
Apr 8, 2022, 3:40:05 PM4/8/22
to
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.
Fred
Apr 8, 2022, 3:40:05 PM4/8/22
to
Best regards,
Fred
Greg Wooledge
Apr 8, 2022, 3:40:05 PM4/8/22
to
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
> CLI:
>
> # avahi-browse -r _print-caps._tcp
> (from the avahi-utils package)
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.
David Wright
Apr 8, 2022, 3:40:05 PM4/8/22
to
changed: trouble.
Cheers,
David.
Brian
Apr 8, 2022, 4:00:05 PM4/8/22
to
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.
Greg Wooledge
Apr 8, 2022, 4:10:06 PM4/8/22
to
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
> avahi-browse -rt _ipp._tcp
>
> is better.
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.)
Tixy
Apr 8, 2022, 4:10:07 PM4/8/22
to
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
The Wanderer
Apr 8, 2022, 4:30:05 PM4/8/22
to
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
> 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?
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
Greg Wooledge
Apr 8, 2022, 4:30:05 PM4/8/22
to
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.
> You didn't like my bus analogy, did you?
> What makes you think that knowing an IP address tells you where
> any machine of any description is located?
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.
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.
Stefan Monnier
Apr 8, 2022, 5:10:04 PM4/8/22
to
> avahi-browse -rt _ipp._tcp
Thanks!
Stefan
Thanks!
Stefan
Brian
Apr 8, 2022, 6:50:05 PM4/8/22
to
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:
> 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.
> "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.
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.
> 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.
"somewhere else" would have to be explained. It is not part of my
> 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.
inderstanding.
> If CUPS found the printer on the network directly, then it certainly
> also found the printer's IP address.
> ...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.
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.
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.
--
Brian.
Brian
Apr 8, 2022, 7:10:05 PM4/8/22
to
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
> 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,
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.)
it wasn't manually configured? Where would the print job go? Discovery
would be useless.
--
Brian,
Greg Wooledge
Apr 8, 2022, 7:40:05 PM4/8/22
to
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
> 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.
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.
The Wanderer
Apr 8, 2022, 7:50:06 PM4/8/22
to
(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 of
>
> > ...the printer that I can see and touch over there.
Not to the print system, it doesn't.
But if that IP-address information is given to the user, who knows the
IP address of "the printer that I can see and touch over there", then
the user can determine whether or not "the printer that I can see and
touch over there" has the same IP address as the printer object seen by
CUPS, and therefore determine whether or not it is the same printer.
>> 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.
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.
>> 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
That only works if IPP is in use, which isn't guaranteed.
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).
> 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 from specifying the name of the print queue on the
print server, we've never bothered to set such information that I'm
aware of.
We also don't use IPP, at least not directly; we define printers on a
Windows print server, and share them from there, using Windows printer
sharing. This is probably common in many environments. If Windows
printer sharing uses IPP in any way, I'm not aware of it.
We do try to put location information in the queue name - but it's not
terribly uncommon for the printer to get relocated without that name
being updated, and in some cases without anyone even telling us that the
printer's been moved.
> It could then be matched with the IP.
...how? In order to match the physical location with the IP address, you
have to *know* the IP address of not only the printer at the physical
location (which Greg did) but the IP address of the printer as seen by
CUPS (which Greg was not able to figure out how to determine, that being
the entire point of his original post as far as I can tell).
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?
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?
(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.
>> 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.
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 of
>
> > ...the printer that I can see and touch over there.
But if that IP-address information is given to the user, who knows the
IP address of "the printer that I can see and touch over there", then
the user can determine whether or not "the printer that I can see and
touch over there" has the same IP address as the printer object seen by
CUPS, and therefore determine whether or not it is the same printer.
>> 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.
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.
>> 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
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).
> 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.
except insofar as those who are call on me to help solve problems), I
can say that aside from specifying the name of the print queue on the
print server, we've never bothered to set such information that I'm
aware of.
We also don't use IPP, at least not directly; we define printers on a
Windows print server, and share them from there, using Windows printer
sharing. This is probably common in many environments. If Windows
printer sharing uses IPP in any way, I'm not aware of it.
We do try to put location information in the queue name - but it's not
terribly uncommon for the printer to get relocated without that name
being updated, and in some cases without anyone even telling us that the
printer's been moved.
> It could then be matched with the IP.
have to *know* the IP address of not only the printer at the physical
location (which Greg did) but the IP address of the printer as seen by
CUPS (which Greg was not able to figure out how to determine, that being
the entire point of his original post as far as I can tell).
David Wright
Apr 8, 2022, 9:00:04 PM4/8/22
to
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
> 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
(10.76.172.100), or would you only get a 169.254/16 one?
(I've not run an mDNS configured network.)
Cheers,
David.
to...@tuxteam.de
Apr 9, 2022, 2:40:05 AM4/9/22
to
On Fri, Apr 08, 2022 at 08:52:26PM +0100, 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?
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
Tixy
Apr 9, 2022, 3:20:05 AM4/9/22
to
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
> 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.
address for printers in GUI or command-line interfaces.
--
Tixy
Brian
Apr 9, 2022, 7:50:05 AM4/9/22
to
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?
> 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).
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.
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 :-)
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.
Brian
Apr 9, 2022, 8:00:04 AM4/9/22
to
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.
> (This is probably both overly long and overly repetitive, among possibly
> other undesirable things, but I'm running short on time.)
avahi-browse -rt _ipp._tcp
avahi-browse -rt _ipp._tcp
> >> 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
>
> That only works if IPP is in use, which isn't guaranteed.
CUPS and modern printers is only via IPP.
> 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).
> > 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 from specifying the name of the print queue on the
> print server, we've never bothered to set such information that I'm
> aware of.
> We also don't use IPP, at least not directly; we define printers on a
> Windows print server, and share them from there, using Windows printer
> sharing. This is probably common in many environments. If Windows
> printer sharing uses IPP in any way, I'm not aware of it.
talk with a Windows server without IPP being involved.
> We do try to put location information in the queue name - but it's not
> terribly uncommon for the printer to get relocated without that name
> being updated, and in some cases without anyone even telling us that the
> printer's been moved.
> > It could then be matched with the IP.
>
> ...how? In order to match the physical location with the IP address, you
> have to *know* the IP address of not only the printer at the physical
> location (which Greg did) but the IP address of the printer as seen by
> CUPS (which Greg was not able to figure out how to determine, that being
> the entire point of his original post as far as I can tell).
the card. Perhaps it can be added? Printing then becomes a two minute,
no-fuss job:
lp -d DESTINATION FILE
--
Brian.
to...@tuxteam.de
Apr 9, 2022, 8:10:05 AM4/9/22
to
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
> 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?
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.
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.
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
> > 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.
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.
Cheers
--
t
Brian
Apr 9, 2022, 8:10:05 AM4/9/22
to
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.
Greg Wooledge
Apr 9, 2022, 9:40:05 AM4/9/22
to
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
> 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
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.
Brian
Apr 9, 2022, 11:40:06 AM4/9/22
to
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:
> 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.
> 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/
> >
> > > 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 Location Make and Model Status
> Canon_LBP351dn_f9_7a_4a_ CNLBP712C CNLBP712C, driverless, cups-filters 1.28.7 Idle
> Canon_LBP712Cdn_db_c0_d3_ Canon_LBP712Cdn_db_c0_d3_ CNLBP712C CNLBP712C, driverless, cups-filters 1.28.7 Idle
> 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
> =====================================================================
[...]
> > 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 Location Make and Model Status
> Canon_LBP351dn_f9_7a_4a_ CNLBP712C CNLBP712C, driverless, cups-filters 1.28.7 Idle
> Canon_LBP712Cdn_db_c0_d3_ Canon_LBP712Cdn_db_c0_d3_ CNLBP712C CNLBP712C, driverless, cups-filters 1.28.7 Idle
> 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?
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.
The Wanderer
Apr 9, 2022, 8:30:05 PM4/9/22
to
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
> 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.
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
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
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
>>> 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.
>> 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.
>>> 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 from specifying the name of the
>> print queue on the print server, we've never bothered to set such
>> information that I'm aware of.
>
> It is not obligatory but can be useful.
>
>> We also don't use IPP, at least not directly; we define printers on
>> a Windows print server, and share them from there, using Windows
>> printer sharing. This is probably common in many environments. If
>> Windows printer sharing uses IPP in any way, I'm not aware of it.
>
> I am unfamiliar with Windows but would think a CUPS server would not
> talk with a Windows server without IPP being involved.
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.)
ISTR that CUPS *is* capable of letting an appropriate sysadmin set a
network printer up on the local machine by IP address (which is the
standard way of doing network-printer setup on Windows when not using a
print server), but my closest connection to that is by way of a former
co-worker who used that method to configure printers for MacOS X, and I
never got a good look at the details.
>> We do try to put location information in the queue name - but it's
>> not terribly uncommon for the printer to get relocated without that
>> name being updated, and in some cases without anyone even telling
>> us that the printer's been moved.
>
> I forgot about that aspect. Another job for the hard-pressed sysadmin
> :).
>>> It could then be matched with the IP.
>>
>> ...how? In order to match the physical location with the IP
>> address, you have to *know* the IP address of not only the printer
>> at the physical location (which Greg did) but the IP address of the
>> printer as seen by CUPS (which Greg was not able to figure out how
>> to determine, that being the entire point of his original post as
>> far as I can tell).
>
> 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
the IP?
(I could go off on a rant about the usefulness of including the IP
address on such a labeling card, but I don't want to make this even more
of a tangent and even less productive than it already is.)
Teemu Likonen
Apr 10, 2022, 1:00:06 AM4/10/22
to
* 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
> On 2022-04-10 01:21, The Wanderer wrote:
>>> avahi-browse -rt _ipp._tcp
>>
>> Does that get the information from CUPS?
>
> 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
to...@tuxteam.de
Apr 10, 2022, 2:40:05 AM4/10/22
to
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
[...]
> 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.)
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
gene heskett
Apr 10, 2022, 5:50:05 AM4/10/22
to
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
to...@tuxteam.de
Apr 10, 2022, 6:10:05 AM4/10/22
to
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
[...]
> 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?
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
gene heskett
Apr 10, 2022, 7:10:05 AM4/10/22
to
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?
> 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.
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.
The Wanderer
Apr 10, 2022, 7:20:06 AM4/10/22
to
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
> 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.
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?
gene heskett
Apr 10, 2022, 7:50:05 AM4/10/22
to
> 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.
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.
to...@tuxteam.de
Apr 10, 2022, 8:00:05 AM4/10/22
to
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:
[...]
> 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?
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.
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
to...@tuxteam.de
Apr 10, 2022, 8:00:05 AM4/10/22
to
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
> 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).
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?
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
to...@tuxteam.de
Apr 10, 2022, 8:10:05 AM4/10/22
to
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
> 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.
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
The Wanderer
Apr 10, 2022, 8:20:05 AM4/10/22
to
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.
> 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?
>
> 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.
gene heskett
Apr 10, 2022, 8:20:05 AM4/10/22
to
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?
> > 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
buster machines or on bullseye without taking "large swaths" of stuff
with it.
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
Brian
Apr 10, 2022, 8:40:05 AM4/10/22
to
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.
> 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.
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
> 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.)
> ISTR that CUPS *is* capable of letting an appropriate sysadmin set a
> network printer up on the local machine by IP address (which is the
> standard way of doing network-printer setup on Windows when not using a
> print server), but my closest connection to that is by way of a former
> co-worker who used that method to configure printers for MacOS X, and I
> never got a good look at the details.
> >> We do try to put location information in the queue name - but it's
> >> not terribly uncommon for the printer to get relocated without that
> >> name being updated, and in some cases without anyone even telling
> >> us that the printer's been moved.
> >
> > I forgot about that aspect. Another job for the hard-pressed sysadmin
> > :).
>
> Tell me about it...
>
> >>> It could then be matched with the IP.
> >>
> >> ...how? In order to match the physical location with the IP
> >> address, you have to *know* the IP address of not only the printer
> >> at the physical location (which Greg did) but the IP address of the
> >> printer as seen by CUPS (which Greg was not able to figure out how
> >> to determine, that being the entire point of his original post as
> >> far as I can tell).
> >
> > 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
>
> Does this address the question of how the printer could be matched with
> the IP?
another way. I wil outline the solution in another post.
--
Brian.
gene heskett
Apr 10, 2022, 8:50:05 AM4/10/22
to
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
> 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.
>
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.
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
Brian
Apr 10, 2022, 8:50:05 AM4/10/22
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.
Brian
Apr 10, 2022, 9:00:06 AM4/10/22
to
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
> 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.
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.
The Wanderer
Apr 10, 2022, 9:00:06 AM4/10/22
to
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.
> 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,
> 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.
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.
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.)
gene heskett
Apr 10, 2022, 9:30:05 AM4/10/22
to
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.
> /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.
Brian
Apr 10, 2022, 9:40:05 AM4/10/22
to
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.
> 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
It applies to detection of *unicast* dns servers.
--
Brian.
gene heskett
Apr 10, 2022, 9:40:05 AM4/10/22
to
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.
>
> .
to...@tuxteam.de
Apr 10, 2022, 9:50:05 AM4/10/22
to
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
[...]
> Many printers provide an snmp (Simple Network Management Protocol)
> service on port 9100. Check with
>
> nmap 10.76.172.100
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
Brian
Apr 10, 2022, 10:00:05 AM4/10/22
to
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
> 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.
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.
The Wanderer
Apr 10, 2022, 10:10:05 AM4/10/22
to
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
> 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
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.
Brian
Apr 10, 2022, 10:40:05 AM4/10/22
to
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
> 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.
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.
Brian
Apr 10, 2022, 10:50:05 AM4/10/22
to
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
> 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.
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.
Brian
Apr 10, 2022, 1:50:05 PM4/10/22
to
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.
Brian
Apr 10, 2022, 2:30:05 PM4/10/22
to
On Sun 10 Apr 2022 at 08:52:09 -0400, The Wanderer wrote:
> On 2022-04-10 at 08:38, Brian 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.
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.)
better served by having the queue name matching the printer.
--
Brian.
to...@tuxteam.de
Apr 10, 2022, 2:40:05 PM4/10/22
to
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
> 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? :)
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.
That's all.
Cheers
--
t
The Wanderer
Apr 10, 2022, 3:10:04 PM4/10/22
to
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.
> 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 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.
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.
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.
to...@tuxteam.de
Apr 10, 2022, 3:30:05 PM4/10/22
to
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?
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
[...]
> > 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 know a corporate network or two which would get you disconnected
> if you do that :
>
> Disconnected? That doesn't sound permissive.
> I know a corporate network or two which would get you disconnected
> if you do that :
>
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.
>
> 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
Brian
Apr 10, 2022, 3:30:06 PM4/10/22
to
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
> 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
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 ;-)
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.
> > 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.
--
controlled by an agent of survellance capitalism? Either way, my actions
are monitored. My communications are intercepted and censorship applied.
Brian.
--
Brian.
Brian
Apr 10, 2022, 3:50:04 PM4/10/22
to
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
> 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.
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 :)
--
Brian.
gene heskett
Apr 10, 2022, 5:00:05 PM4/10/22
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.
Brian
Apr 11, 2022, 10:50:05 AM4/11/22
to
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 Name Description Location Make and Model Status
> Canon_LBP351dn_f9_7a_4a_ CNLBP712C CNLBP712C, driverless, cups-filters 1.28.7 Idle
> Canon_LBP712Cdn_db_c0_d3_ Canon_LBP712Cdn_db_c0_d3_ CNLBP712C CNLBP712C, driverless, cups-filters 1.28.7 Idle
> 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
> 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 Location Make and Model Status
> Canon_LBP351dn_f9_7a_4a_ CNLBP712C CNLBP712C, driverless, cups-filters 1.28.7 Idle
> Canon_LBP712Cdn_db_c0_d3_ Canon_LBP712Cdn_db_c0_d3_ CNLBP712C CNLBP712C, driverless, cups-filters 1.28.7 Idle
> 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
> =====================================================================
>
> 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:
> 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?
"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.
Greg Wooledge
Apr 11, 2022, 12:00:21 PM4/11/22
to
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
> 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.
Failed to resolve host name 'Canon_LBP351dn_f9_7a_4a_.local': Timeout reached
real 5.014 user 0.004 sys 0.004
Brian
Apr 11, 2022, 12:50:04 PM4/11/22
to
avahi-browse -rt _ipp._tcp | grep -B3 port
give for this device?
--
Brian.
Greg Wooledge
Apr 11, 2022, 1:10:05 PM4/11/22
to
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
> What does
>
> avahi-browse -rt _ipp._tcp | grep -B3 port
>
> give for this device?
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
Brian
Apr 11, 2022, 1:50:05 PM4/11/22
to
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.
Greg Wooledge
Apr 11, 2022, 2:00:06 PM4/11/22
to
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
> BTW. I am interested in how using /usr/lib/cups/backend/snmp went.
> Its drawback is that not all printers provide an snmp service.
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.
Brian
Apr 11, 2022, 2:30:05 PM4/11/22
to
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.
Gareth Evans
Apr 11, 2022, 3:10:06 PM4/11/22
to
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
Greg Wooledge
Feb 16, 2023, 10:50:05 AM2/16/23
to
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.
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.
to...@tuxteam.de
Feb 16, 2023, 11:00:06 AM2/16/23
to
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
[...]
> 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.
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
Fred
Feb 16, 2023, 11:20:09 AM2/16/23
to
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
Stefan Monnier
Feb 16, 2023, 12:00:05 PM2/16/23
to
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.
> 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 :)
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
Teemu Likonen
Feb 16, 2023, 12:10:06 PM2/16/23
to
* 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
> 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.
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"?
http://10.76.172.100:631
ipp://10.76.172.100:631
--
/// Teemu Likonen - .-.. https://www.iki.fi/tlikonen/
// OpenPGP: 6965F03973F0D4CA22B9410F0F2CAE0E07608462
Brian
Feb 16, 2023, 2:00:07 PM2/16/23
to
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?
> 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.
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"?
try to avoid unhelpful, judgemental adjectives).
[...]
> My burning hatred of printers and this printing system remains unquenched.
shell script) requires being able to focus.
--
Brian.
Brian
Feb 16, 2023, 2:20:07 PM2/16/23
to
On Thu 16 Feb 2023 at 16:53:02 +0100, to...@tuxteam.de wrote:
> 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)?
A decent suggestion for a printer that speaks and undestands
> 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)?
PS or PDF. But does it? I suppose the "Just for kicks" would
be revealing.
--
Brian.
Brian
Feb 16, 2023, 2:20:07 PM2/16/23
to
incredibly easy. Jumping through hoops is not needed.
--
Brian.
Brian
Feb 16, 2023, 3:10:05 PM2/16/23
to
On Thu 16 Feb 2023 at 11:27:25 -0800, Bob McGowan wrote:
> 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.
> 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.
Greg Wooledge
Feb 16, 2023, 3:40:07 PM2/16/23
to
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 }'
> 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
dhcp-10-76-173-174.local 10.76.173.174 631 Internet Printer
wooledg.local fe80::9e7b:efff:fe24:4213 445 Microsoft Windows Network
wooledg.local fe80::9e7b:efff:fe24:4213 0 Device Info
wooledg.local 10.76.172.189 445 Microsoft Windows Network
wooledg.local 10.76.172.189 0 Device Info
wooledg.local 127.0.0.1 445 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.120 631 Internet Printer
A09-LBT2-HPLJ4250-01.local 10.76.172.120 515 UNIX Printer
dhcp-10-76-173-174.local 10.76.173.174 515 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.60 9100 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.60 9100 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
On Thu, Feb 16, 2023 at 06:54:18PM +0000, 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?
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
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 involves guessing.(Please
> try to avoid unhelpful, judgemental adjectives).
finish, the entire experience has boiled down to "Hi, I'm CUPS. Let me
figure things out for you... OK, here's all the printers I can see,
now just pick one from this list. No, I won't tell you what you need
to know to pick the right one. Who has two of the same printer, anyway?
Nobody!"
What makes it worse is everything I learned last year has been invalidated
by whatever changed, so now I get to start all over again, with an even
more perplexing puzzle.
I think I'll take my Windows laptop with me next time I go in, to see how
it interacts with printerspace.
===============================
Here's a theory. There are two printers with the same model number on
the 10th floor. One, mine, is in an area where almost no people work
on a daily basis. Call that "area A". Another is in an area where a
whole bunch of people work on a daily basis. Call that "area B".
People in area B tried to set up their PCs to print to their printer,
but got confused by the duplicate model number, and ended up sending
their jobs to the wrong printer. They called the help desk, and reported
the problem. The help desk dispatched a printer person, who looked at
both printers, and decided that the easiest solution would be to disable
Avahi announcing stuff on the printer in area A.
Now, all the people in area B just see their own printer, not the printer
in area A, and they're no longer confused. Meanwhile, the people in
area A *also* only see the printer in area B, even if they previously had
a queue set up to their printer, and are tremendously confused. But they
don't call the help desk because they're trying to print from Linux,
which is 100% unsupported, and drawing attention to it would just make
matters even worse.
That's pure speculation at the moment, but it's all I can think of.
gene heskett
Feb 16, 2023, 4:00:06 PM2/16/23
to
printer? Or if its in your /etc/hosts file, what does traceroute say?
It might illuminate what changed. Maybe housekeeping unplugged it to
move & clean ;o(>
> .
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 <http://geneslinuxbox.net:6309/>
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
Bob McGowan
Feb 16, 2023, 4:10:07 PM2/16/23
to
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.
gene heskett
Feb 16, 2023, 5:00:06 PM2/16/23
to
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.
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.
Greg Wooledge
Feb 16, 2023, 5:20:06 PM2/16/23
to
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.
> I hate to ask the obvious, but is the net cable plugged into that printer?
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.
>
Brian
Feb 17, 2023, 6:20:06 AM2/17/23
to
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.
> 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/
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.
Greg Wooledge
Feb 17, 2023, 9:10:06 AM2/17/23
to
On Fri, Feb 17, 2023 at 11:18:32AM +0000, 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
> 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).
+ 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
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).
Reco
Feb 17, 2023, 10:00:05 AM2/17/23
to
Hi.
On Thu, Feb 16, 2023 at 10:41:33AM -0500, Greg Wooledge wrote:
lpadmin -p D14841 -E -v ipp://10.76.172.100/ipp/print -m everywhere
Reco
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:
> 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"?
lpadmin -p D14841 -E -v ipp://10.76.172.100/ipp/print -m everywhere
Reco
Brian
Feb 17, 2023, 10:10:07 AM2/17/23
to
On Fri 17 Feb 2023 at 09:05:39 -0500, Greg Wooledge wrote:
> On Fri, Feb 17, 2023 at 11:18:32AM +0000, Brian wrote:
[...]
> On Fri, Feb 17, 2023 at 11:18:32AM +0000, 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
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.)
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.
Brian
Feb 17, 2023, 2:10:06 PM2/17/23
to
On Thu 16 Feb 2023 at 12:52:37 -0800, Bob McGowan wrote:
[...]
> 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.
I also saw Stefan Monnier's post in the the same way: sending
a file directly to a printer in a PDL it does not understand
usually results in pages of gibberish. Then I went off on a
tangent! Sorry. Thanks for bringing me back to the right view.
--
Brian
[...]
> 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.
a file directly to a printer in a PDL it does not understand
usually results in pages of gibberish. Then I went off on a
tangent! Sorry. Thanks for bringing me back to the right view.
--
Brian
Max Nikulin
Feb 18, 2023, 7:50:06 AM2/18/23
to
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
>
> 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.
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.
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?
Greg Wooledge
Feb 24, 2023, 1:00:06 PM2/24/23
to
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
> Try this next time you're on site:
>
> lpadmin -p D14841 -E -v ipp://10.76.172.100/ipp/print -m everywhere
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.
Brian
Feb 24, 2023, 4:00:07 PM2/24/23
to
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.
> 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.
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.
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.
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.
Reco
Feb 25, 2023, 10:10:06 AM2/25/23
to
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
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.
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.
suite is a living proof of that.
Reco
Brian
Feb 25, 2023, 1:40:06 PM2/25/23
to
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
> 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.
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.
acquired CUPS.
--
Brian.
It is loading more messages.
0 new messages