(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). -- 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
Attachment:
signature.asc
Description: OpenPGP digital signature