Discussion:
1.6x IPP printer detection
Kai Hendry
2013-03-13 08:02:07 UTC
Permalink
Hi there,

In the past in Webconverger IPP printers were simply detected via port
631 on the same subnet and presented in a print dialog on Webconverger
instances.
http://webconverger.org/printing

However, recently I can't seem to replicate this. This is my server
configuration: http://ix.io/4Ig
This is my 1.5.3-2.15
https://github.com/Webconverger/webc/blob/master/etc/cups/cupsd.conf
for the Webconverger clients, which should be able to browse the
shared PDF printer on my printing host and print to it.


The Webconverger clients do not detect the printer unless I manually
enter ipp://192.168.43.85/printers/Virtual_PDF_Printer
Previously I didn't need this manual step.

Is there something I'm missing?

Many thanks,
Dennis Leeuw
2013-03-13 08:16:54 UTC
Permalink
Hi Kai,

I am still trying to figure this all out, but I think you are having the
same problem I had. With version 1.6 the BrowsePoll directive and
friends is gone. It means that only mDNS and DNS-SD are supported. mDNS
(multicast) only works within a network not across routers. If you have
one big network add the printers to AVAHI (if your server is a Linux
machine).

In a multi-network environment where multi-cast is not an option
(allowed) you should use DNS-SD. Meaning you have to add "printer
support" to DNS. I am working on documenting this, maybe it is of help
to you too:
http://pig.made-it.com/cups-dns-sd.html
The page gives an initial overview

A more detailed description of the printer settings in DNS can be found in:
http://pig.made-it.com/printing.html
See the section about Mac OS X

If I talk nonsense there is probably someone on this list that will
correct me.

Greetings,

Dennis
Post by Kai Hendry
Hi there,
In the past in Webconverger IPP printers were simply detected via port
631 on the same subnet and presented in a print dialog on Webconverger
instances.
http://webconverger.org/printing
However, recently I can't seem to replicate this. This is my server
configuration: http://ix.io/4Ig
This is my 1.5.3-2.15
https://github.com/Webconverger/webc/blob/master/etc/cups/cupsd.conf
for the Webconverger clients, which should be able to browse the
shared PDF printer on my printing host and print to it.
The Webconverger clients do not detect the printer unless I manually
enter ipp://192.168.43.85/printers/Virtual_PDF_Printer
Previously I didn't need this manual step.
Is there something I'm missing?
Many thanks,
_______________________________________________
cups mailing list
http://lists.easysw.com/mailman/listinfo/cups
Kai Hendry
2013-03-13 08:33:04 UTC
Permalink
Hey Dennis,

Thanks for offering to help.
Post by Dennis Leeuw
I am still trying to figure this all out, but I think you are having the
same problem I had. With version 1.6 the BrowsePoll directive and
So what was this previous "BrowsePoll" called ? This I assume the
mechanism I was using before but no longer works.
Post by Dennis Leeuw
friends is gone. It means that only mDNS and DNS-SD are supported. mDNS
(multicast) only works within a network not across routers. If you have
one big network add the printers to AVAHI (if your server is a Linux
machine).
Yes, we only have one subnet here. We don't need the across routers
(IIUC "multi-network") use case.


My client has a "Ricoh Aficio SP3510DN network printer with built in
IPP server", and now I can't seem to detect it. I'm wondering how I
can typically detect it. Do I need Avahi with Bonjour nowadays?


Thanks again,
Johannes Meixner
2013-03-13 08:43:25 UTC
Permalink
Hello,
... clients, which should be able to browse the
shared PDF printer on my printing host ...
Since CUPS version 1.6 the traditional "CUPS Browsing" is dropped.
Since CUPS version 1.6 only DNS-SD is supported.
Up to CUPS version 1.5 there is no native DNS-SD support in CUPS
under Linux (except via add-on patches that add Avahi support).
Since CUPS version 1.6 there is native DNS-SD support in CUPS
also under Linux.

See
http://www.cups.org/roadmap.php?VERSION=1.6
therein in particular
"Drop support for CUPS Browsing and Polling"
http://www.cups.org/str.php?L3922

For a summary of "What's New in CUPS 1.6" see
http://www.cups.org/documentation.php/doc-1.6/whatsnew.html
in particular:
"Sharing Protocols; The scheduler no longer supports
the CUPS, LDAP, or SLP protocols for printer sharing."

Additionally you may have a look at
https://bugzilla.novell.com/show_bug.cgi?id=735404


Kind Regards
Johannes Meixner
--
SUSE LINUX Products GmbH -- Maxfeldstrasse 5 -- 90409 Nuernberg -- Germany
HRB 16746 (AG Nuernberg) GF: Jeff Hawn, Jennifer Guild, Felix Imendoerffer
Kai Hendry
2013-03-13 09:16:12 UTC
Permalink
Post by Johannes Meixner
Since CUPS version 1.6 the traditional "CUPS Browsing" is dropped.
Since CUPS version 1.6 only DNS-SD is supported.
Up to CUPS version 1.5 there is no native DNS-SD support in CUPS
under Linux (except via add-on patches that add Avahi support).
Ok, I've since discovered writing a ServerName IP to
/etc/cups/client.conf, makes Webconverger able to detect my 1.6
printer server.
https://github.com/Webconverger/webc/issues/145

What protocol is this? The only downside is that I think this breaks
in 1.6? https://bugzilla.novell.com/show_bug.cgi?id=735404#c25

This workaround avoids the Avahi install and its crazy amount of
Python dependencies. However now my clients have the prospect of a
poor UX by having to specify their printers IP, instead of the
preferred "it just worked!" UX.
Post by Johannes Meixner
Additionally you may have a look at
https://bugzilla.novell.com/show_bug.cgi?id=735404
Pretty shocking Johannes. Noticed some of those bugs myself. :(

Extremely irritating how the config changed and the coredumps on
restart. Wowsers bad.



Many thanks again,
Kai Hendry
2013-03-13 10:10:32 UTC
Permalink
Actually the client.conf option doesn't work since my clients network
printer, is not a cups printer.

I could try preset the printer.conf with the IPP, but it's a little
messy with http://ix.io/4Ii and the accompanying PPD http://ix.io/4Ij
Furthermore this API looks like it's going with CUPS 1.6?!

I just tried Avahi. However the UX is also terrible here. I had to add
the printer beforehand in CUPS Web interface, before being able to use
it?

Loading Image...
Loading Image...

I need the UX where detected printers just appear in the print dialog.

I hope you guys can help me!

Many thanks,
Johannes Meixner
2013-03-13 11:24:44 UTC
Permalink
Hello,
Post by Kai Hendry
I need the UX where detected printers just appear in the print dialog.
As far as I know this does no longer work with native CUPS 1.6.
As far as I know since CUPS 1.6 this is delegated to the
print dialogs that would need to be enhanced to support
browsing DNS-SD / Bonjour broadcasts directly, see
https://bugzilla.novell.com/show_bug.cgi?id=735404#c15

For background information and reasoning what could be done
until print dialogs natively support DNS-SD browsing, see
the "An idea how to provide CUPS Browsing for CUPS 1.6"
thread in this newsgroup:

https://www.cups.org/newsgroups.php?gcups.general+T+Q%22An+idea+how+to+provide+CUPS+Browsing+for+CUPS+1.6%22

In particular see Till Kamppeter's proposal for
an "universal cups-browsed" in this thread.

As far as I noticed Till already implemented some of the
"universal cups-browsed" functionality in the cups-filters
software.

See
http://www.linuxfoundation.org/collaborate/workgroups/openprinting/pdf_as_standard_print_job_format
for general background information and reasoning
why the cups-filters software exists.

You can download the cups-filters sources from
http://www.openprinting.org/download/cups-filters/

In the latest cups-filters sources there are utils/cups-browsed.*
files that implement some cups-browsed functionality,
see the README file in the cups-filters sources in particular
the section "HELPER DAEMON FOR BROWSING REMOTE CUPS PRINTERS".

I didn't test the current cups-browsed in cups-filters
whether or not it provides already a solution for your issue
but as far as I understand it the cups-browsed in cups-filters
is meant to become the solution for issues like yours.


Kind Regards
Johannes Meixner
--
SUSE LINUX Products GmbH -- Maxfeldstrasse 5 -- 90409 Nuernberg -- Germany
HRB 16746 (AG Nuernberg) GF: Jeff Hawn, Jennifer Guild, Felix Imendoerffer
Michael Sweet
2013-03-13 15:13:56 UTC
Permalink
Kai,
Post by Kai Hendry
...
I need the UX where detected printers just appear in the print dialog.
I have talked a bit with a few folks to see what we can do here in the long run; currently client software has to "opt in" to the new dynamic CUPS destination API, but perhaps we can start a thread in libcups that just maintains a current list of available printers - we would need to start it when cupsGetDests is called the first time (and give it a few seconds to populate the list), and then possibly provide a separate function that could be called to start or stop this thread independently.

Unfortunately, applications like Firefox think it is OK to dynamically load and unload libcups, so we need to be very careful to avoid having such applications crash.

_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair
Kai Hendry
2013-03-14 05:10:35 UTC
Permalink
Post by Michael Sweet
I have talked a bit with a few folks to see what we can do here in the long run; currently client software has to "opt in" to the new dynamic CUPS destination API, but perhaps we can start a thread in libcups that just maintains a current list of available printers - we would need to start it when cupsGetDests is called the first time (and give it a few seconds to populate the list), and then possibly provide a separate function that could be called to start or stop this thread independently.
Ok, just to summarise. IIUC with mdns or DNS-SD, one needs to
*manually* setup the printer in CUPS.

Previously in CUPS 1.5 you could use BrowsePoll to automatically
detect the printers without setup, which is deprecated in 1.6.



Did I understand correctly?

Many thanks,
Michael Sweet
2013-03-14 14:40:24 UTC
Permalink
Kai,
Post by Kai Hendry
...
Ok, just to summarise. IIUC with mdns or DNS-SD, one needs to
*manually* setup the printer in CUPS.
For applications that don't support the current destination functions in libcups, this is correct. Otherwise you can discover and use shared printers directly without adding a local queue pointing to the remote server (which is how CUPS browsing did things).
Post by Kai Hendry
Previously in CUPS 1.5 you could use BrowsePoll to automatically
detect the printers without setup, which is deprecated in 1.6.
Correction: BrowsePoll (and everything having to do with CUPS Browsing) was deprecated in 1.4 and removed in 1.6. Deprecation doesn't mean removal, it just is a warning that it will be removed at some point in the future.

_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair
Kai Hendry
2013-03-14 14:50:30 UTC
Permalink
Post by Michael Sweet
For applications that don't support the current destination functions in libcups, this is correct. Otherwise you can discover and use shared printers directly without adding a local queue pointing to the remote server (which is how CUPS browsing did things).
I'm struggling to understand "current destination functions in libcups".

Can I assume you are saying that if one wants to discover shared
printers, I need to ask my client to run a CUPS server?

Or are there network printers on the market that can be configured to
be used without any setup on a client? i.e. No manual "Add printer..."
phase.


Thanks again Michael,
Michael Sweet
2013-03-14 15:15:07 UTC
Permalink
Kai,
Post by Kai Hendry
Post by Michael Sweet
For applications that don't support the current destination functions in libcups, this is correct. Otherwise you can discover and use shared printers directly without adding a local queue pointing to the remote server (which is how CUPS browsing did things).
I'm struggling to understand "current destination functions in libcups".
CUPS 1.6 added cupsEnumDests, cupsCreateDestJob, cupsStartDestDocument, etc. functions, which replace the older cupsGetDests, cupsCreateJob, cupsStartDocument, etc. functions.
Post by Kai Hendry
Can I assume you are saying that if one wants to discover shared
printers, I need to ask my client to run a CUPS server?
No. A local cupsd is only needed for local queues, which might point to a network printer/print server, but the queue is managed locally and all processing happens on the local system.

The point of the new APIs is to allow client software to discover and use printers or shared print queues directly. The only time you really need to have a local queue is for printers that can't handle PDF directly.
Post by Kai Hendry
Or are there network printers on the market that can be configured to
be used without any setup on a client? i.e. No manual "Add printer..."
phase.
There are some printers on the market today (more coming) that can be used directly. There are some application-specific issues to take care of (retry if the printer is busy), but printing direct can be done, especially for casual printing.

For a printer you use regularly, you probably want a local queue (even if it is just a passthrough queue to the remote server/printer) so that you can queue up multiple jobs, manage those jobs, etc. since most printers don't support queueing of jobs...

_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair
Kai Hendry
2013-03-14 16:14:04 UTC
Permalink
Post by Michael Sweet
The point of the new APIs is to allow client software to discover and use printers or shared print queues directly. The only time you really need to have a local queue is for printers that can't handle PDF directly.
Sidenote: When you say "printers that can't handle PDF directly", you
mean can't handle postscript? IIRC PDF is a subset of PostScript.
Post by Michael Sweet
There are some printers on the market today (more coming) that can be used directly. There are some application-specific issues to take care of (retry if the printer is busy), but printing direct can be done, especially for casual printing.
So these new printers implement the new CUPS 1.6 APIs if I understand
you correctly? Can you name a model for an example? I wonder what
moniker this appears under in their brochure.
Post by Michael Sweet
For a printer you use regularly, you probably want a local queue (even if it is just a passthrough queue to the remote server/printer) so that you can queue up multiple jobs, manage those jobs, etc. since most printers don't support queueing of jobs...
Well, every instance of Webconverger has a local CUPS server running,
so that's the local queue taken care of, right?

Kind regards,
Johannes Meixner
2013-03-13 10:42:16 UTC
Permalink
Hello,
... writing a ServerName IP to
/etc/cups/client.conf, makes Webconverger able to detect my 1.6
printer server.
https://github.com/Webconverger/webc/issues/145
What protocol is this? The only downside is that I think this breaks
in 1.6? https://bugzilla.novell.com/show_bug.cgi?id=735404#c25
Having a "ServerName hostB" entry in /etc/cups/client.conf on hostA
lets the clients (i.e. programs that link with libcups) that run
on hostA no longer talk to the cupsd running on hostA but
instead directly talk to anything that is listening on the
IPP port 631 on hostB.

Since CUPS 1.6 it uses by default IPP version 2.0 which means
if there is CUPS 1.6 installed on hostA a client program that
runs on hostA talks IPP version 2.0 to anything that is listening
on the IPP port 631 on hostB.

If what is listening on the IPP port 631 on hostB is a bit older
it may not support IPP version 2.0 and reject the IPP version 2.0
request from the client on hostA.

E.g. if on hostB an older CUPS version (e.g. 1.3.9) runs,
it rejects IPP version 2.0 requests with "Bad Request".

See my comment "jsmeix.suse: 06:59 Nov 30, 2012" at
https://www.cups.org/str.php?L4231

The solution will be to tell the client that runs on hostA
to talk an older IPP version e.g. IPP version 1.1
e.g. via a "ServerName hostB/version=1.1" entry
in /etc/cups/client.conf on hostA.

This solution will be availabe in CUPS 1.6.2 which should
be released soon.

With CUPS 1.6.1 it does not work.
CUPS 1.6.1 clients cannot talk to older CUPS servers.

Regarding IPP printers:
I guess CUPS 1.6.1 clients cannot talk to many IPP printers
because many IPP printers may not support IPP version 2.0
but I am really no expert reagrding built-in IPP in printers.
My knowledge regarding built-in IPP in printers is basically
"don't use it", see
http://www.cups.org/documentation.php/doc-1.6/network.html
and
http://en.opensuse.org/SDB:Printing_via_TCP/IP_network


Kind Regards
Johannes Meixner
--
SUSE LINUX Products GmbH -- Maxfeldstrasse 5 -- 90409 Nuernberg -- Germany
HRB 16746 (AG Nuernberg) GF: Jeff Hawn, Jennifer Guild, Felix Imendoerffer
Michael Sweet
2013-03-13 15:09:38 UTC
Permalink
This post might be inappropriate. Click to display it.
Kai Hendry
2013-03-14 05:21:50 UTC
Permalink
Post by Michael Sweet
As for breaking things, if you are running an old CUPS without IPP/2.0 support (anything older than 1.4) then you'll need the changes coming in 1.6.2 to specify that the server only does IPP/1.1 ("ServerName host-or-ip/version=1.1").
Ok, now I'm trying to get a network printer (Ricoh Aficio SP3510DN)
working with a CUPS 1.5 client. How do I work out which version of IPP
this Ricoh printer is running? Its IP is 192.168.1.6. I can telnet to
its port 631. I did try lpstat and snmpwalk, and I didn't get results.
Perhaps I am not running them with the correct switches?
Post by Michael Sweet
I didn't think Avahi needed Python to work by itself; perhaps this is a distro packaging issue? In any case, you can also install mDNSResponder (the "other" free software mDNS stack from Apple) which definitely does not have these dependencies.
Where can I find the sources for this? If there is a lightweight
version of what Avahi does, I'm interested in integrating it into
Webconverger. :-)

Thank you for your help,
Michael Sweet
2013-03-14 14:37:43 UTC
Permalink
This post might be inappropriate. Click to display it.
Kai Hendry
2013-03-14 14:47:19 UTC
Permalink
Post by Michael Sweet
You can't point ServerName to a printer, just to a CUPS server.
Oh OK.
Post by Michael Sweet
When you setup a print queue the best way is using Bonjour - then the discovery provides all of the necessary information. Otherwise you might try looking on the printer's web page or print a network configuration page from the control panel to see what URI to use.
If I knew the ipp address, lets say ipp://192.168.1.5/printers/foobar,
then I could deploy an image to a customer with a printers.conf and a
postcript PPD, couldn't I? Using 1.5.
Post by Michael Sweet
http://www.opensource.apple.com/tarballs/mDNSResponder/
So IIUC this project can implement that Bonjour discovery on Linux? As
an alternative to the typical Avahi deployments in distributions.

Kind regards,
Michael Sweet
2013-03-14 14:59:16 UTC
Permalink
Kai,
Post by Kai Hendry
...
If I knew the ipp address, lets say ipp://192.168.1.5/printers/foobar,
then I could deploy an image to a customer with a printers.conf and a
postcript PPD, couldn't I? Using 1.5.
Yes, although that type of deployment is 100% unsupported because printers.conf and the location of PPD files are implementation (and site configuration) details. A better approach is to provide a shell script that "extracts" the PPD to a temporary file and uses the lpadmin command to add the printer.
Post by Kai Hendry
Post by Michael Sweet
http://www.opensource.apple.com/tarballs/mDNSResponder/
So IIUC this project can implement that Bonjour discovery on Linux? As
an alternative to the typical Avahi deployments in distributions.
Yes. mDNSResponder was first, but the original license had some GPL compatibility issues so Avahi was born as a replacement. Apple has since changed the license, but I guess people still have concerns.

mDNSResponder runs on Linux, OS X, Windows, and pretty much every UNIX/UNIX-like operating system. It can also be embedded in things like printers, cameras, etc., and several manufacturers use mDNSResponder for exactly that reason.

_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair
Kai Hendry
2013-03-14 15:09:43 UTC
Permalink
Post by Michael Sweet
Yes, although that type of deployment is 100% unsupported because printers.conf and the location of PPD files are implementation (and site configuration) details. A better approach is to provide a shell script that "extracts" the PPD to a temporary file and uses the lpadmin command to add the printer.
Do you have an example for me to use as a guide please?

The PPD 9 times out of 10 is hopefully is going to be a generic
postscript template hopefully, right?



Thanks again,
Michael Sweet
2013-03-14 15:21:32 UTC
Permalink
Kai,
Post by Kai Hendry
Post by Michael Sweet
Yes, although that type of deployment is 100% unsupported because printers.conf and the location of PPD files are implementation (and site configuration) details. A better approach is to provide a shell script that "extracts" the PPD to a temporary file and uses the lpadmin command to add the printer.
Do you have an example for me to use as a guide please?
#!/bin/sh
cat >tempfile-$$.ppd <<EOF
CONTENTS OF PPD GO HERE
EOF
lpadmin -p printername -E -v ipp://foo/bar -i tempfile-$$.ppd
rm -f tempfile-$$.ppd
Post by Kai Hendry
The PPD 9 times out of 10 is hopefully is going to be a generic
postscript template hopefully, right?
It will be whatever the printer requires. If it is a shared CUPS printer then use "-m raw" instead of a local PPD, otherwise use whatever PPD is stored in /etc/cups/ppd on your "test" system or use "lpinfo -m" to locate a suitable driver on the system.

_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair
Kai Hendry
2013-03-14 16:08:42 UTC
Permalink
Post by Michael Sweet
#!/bin/sh
cat >tempfile-$$.ppd <<EOF
CONTENTS OF PPD GO HERE
EOF
lpadmin -p printername -E -v ipp://foo/bar -i tempfile-$$.ppd
rm -f tempfile-$$.ppd
Ok this looks promising. I can avoid the "Add printer..." phase by
scripting this on boot. However I need to get the ipp:// address from
my client in advance. And my client on site doesn't seem to know it
and I can't figure it out myself remotely.

There is no command I can (I can ask my client to) issue on telnet to
reveal the ipp:// address? I know the IP, just not the fully qualified
ipp:// URL.
Post by Michael Sweet
Post by Kai Hendry
The PPD 9 times out of 10 is hopefully is going to be a generic
postscript template hopefully, right?
It will be whatever the printer requires. If it is a shared CUPS printer then use "-m raw" instead of a local PPD, otherwise use whatever PPD is stored in /etc/cups/ppd on your "test" system or use "lpinfo -m" to locate a suitable driver on the system.
Understood, though I was hoping I could assume that most network
printers are postscript compatible. I guess I can assume nothing
nowadays. ;)

http://www.ricoh-usa.com/downloads/popup/popup_manuals_drivers_download.aspx?path=http%3a%2f%2fsupport.ricoh.com%2fbb%2fhtml%2fdr_ut_e%2frc2%2fmodel%2fsp35%2fsp35en.htm


Thanks again. This is really helpful.
Kai Hendry
2013-03-20 05:48:09 UTC
Permalink
Post by Michael Sweet
Post by Kai Hendry
Do you have an example for me to use as a guide please?
#!/bin/sh
cat >tempfile-$$.ppd <<EOF
CONTENTS OF PPD GO HERE
EOF
lpadmin -p printername -E -v ipp://foo/bar -i tempfile-$$.ppd
rm -f tempfile-$$.ppd
I've implemented a printer=printer name,device URI,driver URI API, so
that my clients can pre-configure the printer and therefore avoiding
the expensive detection and "Add printer..." phases.

Documentation: http://webconverger.org/printing
MIT licensed code:
https://github.com/Webconverger/webc/blob/master/etc/webc/live-config.sh#L120

Be great to get a review from CUPS upstream here. :-)

Of course the downside, is that my clients need to carefully manage
the IP of their printers and the accompanying driver.

Kind regards,
Michael Sweet
2013-03-20 15:15:02 UTC
Permalink
Kai,
Post by Kai Hendry
...
Be great to get a review from CUPS upstream here. :-)
It's fine.
Post by Kai Hendry
Of course the downside, is that my clients need to carefully manage
the IP of their printers and the accompanying driver.
That's why we want IPP Everywhere: Bonjour discovery, no drivers.

_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair
Kai Hendry
2013-03-20 16:06:27 UTC
Permalink
Hi Michael,

Thanks again for taking a look.
Post by Michael Sweet
That's why we want IPP Everywhere: Bonjour discovery, no drivers.
I don't quite understand that.

Because for example when you setup a (Ricoh) network printer with IPP
using the address http://IP.ADDRESS/printer, you still need to specify
a printer driver.

Perhaps the "Bonjour discovery" is not working correctly. Does that
somehow advertise the driver?

Kind regards,
Michael Sweet
2013-03-20 16:19:35 UTC
Permalink
Kai,
Post by Kai Hendry
Hi Michael,
Thanks again for taking a look.
Post by Michael Sweet
That's why we want IPP Everywhere: Bonjour discovery, no drivers.
I don't quite understand that.
Because for example when you setup a (Ricoh) network printer with IPP
using the address http://IP.ADDRESS/printer, you still need to specify
a printer driver.
If the printer supports a well-defined standard, like IPP Everywhere, then all you need is the address or URI and a single, common "driver" that talks the standard protocol and file formats.
Post by Kai Hendry
Perhaps the "Bonjour discovery" is not working correctly. Does that
somehow advertise the driver?
Bonjour (DNS-SD) does in fact advertise make-and-model/product/1284 device ID fields, and that can be (and is) used for legacy driver lookup.

However, what I'm talking about is a new class of printer (available for the last few years now thanks to a lot of work by a lot of people, including me) that implements standard protocols and file formats, eliminating the need for printer drivers as we have known them. This has been a long time in coming (I have personally been pushing for this since 1998 in the IETF and PWG) and will make printer setup as easy as plugging in (or wirelessly pairing with) a keyboard or mouse.

_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair

Tim Waugh
2013-03-13 11:19:18 UTC
Permalink
Post by Johannes Meixner
Since CUPS version 1.6 the traditional "CUPS Browsing" is dropped.
Since CUPS version 1.6 only DNS-SD is supported.
Up to CUPS version 1.5 there is no native DNS-SD support in CUPS
under Linux (except via add-on patches that add Avahi support).
Since CUPS version 1.6 there is native DNS-SD support in CUPS
also under Linux.
FWIW, I've recently added support for BrowsePoll, and CUPS Browsing for
sharing and discovery, to the cups-browsed program (part of the
cups-filters package).

This means you can continue to use these features with CUPS 1.6 by
running the cups-browsed daemon.

Tim.
*/
Johannes Meixner
2013-03-14 11:38:01 UTC
Permalink
Hello Tim,
Post by Tim Waugh
I've recently added support for BrowsePoll, and CUPS Browsing for
sharing and discovery, to the cups-browsed program (part of the
cups-filters package).
Great!
Many thanks for it.


Kind Regards
Johannes Meixner
--
SUSE LINUX Products GmbH -- Maxfeldstrasse 5 -- 90409 Nuernberg -- Germany
HRB 16746 (AG Nuernberg) GF: Jeff Hawn, Jennifer Guild, Felix Imendoerffer
Michael Sweet
2013-03-13 14:27:43 UTC
Permalink
Kai,

CUPS browsing was deprecated in CUPS 1.4 and removed in CUPS 1.6, so this product you are using will no longer work automatically. What has replaced CUPS browsing is Bonjour aka Zeroconf + DNS-SD + mDNS, all IETF proposed standards with 10+ years of deployment now... The advantage is that Bonjour provides the name resolution and IPv6 support that was missing from CUPS Browsing.
Post by Kai Hendry
Hi there,
In the past in Webconverger IPP printers were simply detected via port
631 on the same subnet and presented in a print dialog on Webconverger
instances.
http://webconverger.org/printing
However, recently I can't seem to replicate this. This is my server
configuration: http://ix.io/4Ig
This is my 1.5.3-2.15
https://github.com/Webconverger/webc/blob/master/etc/cups/cupsd.conf
for the Webconverger clients, which should be able to browse the
shared PDF printer on my printing host and print to it.
The Webconverger clients do not detect the printer unless I manually
enter ipp://192.168.43.85/printers/Virtual_PDF_Printer
Previously I didn't need this manual step.
Is there something I'm missing?
Many thanks,
_______________________________________________
cups mailing list
http://lists.easysw.com/mailman/listinfo/cups
_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair
Loading...