What exactly do you mean with "upgrade"?
Did you install openSUSE 10.2 from scratch
or did you update an existing Suse Linux 10.1 system?

What exactly did you do to set up the print queue in YaST?
We need a detailed step by step explanation so that we can
understand what goes on on your particular system:
I.e.:
Which entries did you see in YaST and which did you select and
which buttons did you click in YaST and all exact (error)-messages
which may pop up in YaST while you do your setup.

Furthermore we need the YaST log for exactly one setup of your printer:
Please provide the YaST log file as follows:
1.
Have a clean state to start:
Remove all your print queues in YaST and finish YaST.
2.
Move the old YaST log file away:
mv /var/log/YaST2/y2log /var/log/YaST2/y2log.old
3.
Start YaST and do again setup your pinter.
Finish YaST and save the log file:
cp -p /var/log/YaST2/y2log /var/log/YaST2/y2log.save
4.
Attach /var/log/YaST2/y2log.save
as attachment with mime type "text plain" to this bug.

Finally we need the basic info about your print queue(s)
after you did the above re-setup with YaST:
a)
What exactly does
lpstat -t
show you?
b)
Which PPD(s) do you use:
What does
egrep -i 'NickName|cupsFilter' /etc/cups/ppd/*
show you?

I have formatted "/" and installed openSUSE 10.2 beta 1, just the "/home"-partition is the old one. Now I'm upgrading nearly daily from factory with smart.

I set up the printer with the CUPS-Webadmin-tool (http://localhost:631) because YaST (yast2-printer-2.14.4-2.x86_64) is crashing on startup while creating the database (I've already read a bug report about this...), and the KDE-control-center has an error at te end of adding a printer (client-error-bad-request). So has this webadmin-tool a log, too?

There I choose "add printer", then as name "KellerLaser", on next page "Internet Printing Protocol (http)", then  "http://192.168.2.1:1631/printers/My_Printer". I'm choosing the ppd-file Epson-AL-C1100-fm3.ppd (I found this in the internet and it's working perfect in SuSE 10.1) and it's ready.

"lpstat -t" on openSuSE 10.2 beforetrying to print:
Scheduler läuft
Kein systemweites Standardziel
Gerät für Kellerlaser: http://192.168.2.1:1631/printers/My_Printer
Kellerlaser akzeptiert Anfragen seit Do 02 Nov 2006 18:24:32 CET
Drucker Kellerlaser ist frei.  freigegeben seit Do 02 Nov 2006 18:24:32 CET

"lpstat -t" on openSUSE 10.2 after trying to print:
Scheduler läuft
Kein systemweites Standardziel
Gerät für Kellerlaser: http://192.168.2.1:1631/printers/My_Printer
Kellerlaser akzeptiert Anfragen seit Do 02 Nov 2006 18:29:29 CET
Drucker Kellerlaser ist gesperrt seit Do 02 Nov 2006 18:29:29 CET -
        /usr/lib64/cups/backend/http failed
Kellerlaser-9           root             18432   Do 02 Nov 2006 18:29:26 CET

"egrep -i 'NickName|cupsFilter' /etc/cups/ppd/*":
*ShortNickName:       "ALC1100"
*NickName:            "EPSON AL-C1100, ESC/PageS Filter"
*cupsFilter:          "application/vnd.cups-postscript 0 foomatic-rip"

Created attachment 103576 [details]
The used ppd-file

The DeviceURI "http://192.168.2.1:1631/printers/My_Printer"
looks strange but according to
http://www.usr.com/support/5461/5461-ug/trouble20.html
it seems to be really correct.

To find out why "/usr/lib64/cups/backend/http failed"
we need the CUPS error_log as follows:
(See http://en.opensuse.org/SDB:CUPS_in_a_Nutshell
"If problems are encountered".)

1.
Set the "LogLevel debug" in /etc/cups/cupsd.conf.
2.
Stop cupsd.
3.
Move /var/log/cups/error_log* to another location (or delete it)
in order to avoid having to search through gigantic log files.
4.
Start cupsd.
4a)
Re-enable the disabled print queue:
cupsenable Kellerlaser
5.
Retry the action leading to the problem:
I.e. print via the queue:
echo Hello | lp -d Kellerlaser
6.
Now /var/log/cups/error_log contains many messages
that are useful for troubleshooting. 

Attach /var/log/cups/error_log as attachment
with mime type "text plain" to this bug.

Created attachment 103800 [details]
cups-error-log

Here is the needed cups-error-log

I tried to print a test-page on the cups-webinterface.

The error_log tels only this about why the backend fails
----------------------------------------------------------------------------
E ... [Job 11] Print file was not accepted (server-error-device-error)!
E ... PID 4849 (/usr/lib64/cups/backend/http) stopped with status 1!
----------------------------------------------------------------------------
and according to "RFC 2911 - Internet Printing Protocol"
the "server-error-device-error" error code means
----------------------------------------------------------------------------
13.1.5.5 server-error-device-error (0x0504)

   A printer error, such as a paper jam, occurs while the IPP object
   processes a Print or Send operation.
   ...
   This error status code is
   only returned in situations where the Printer is unable to accept the
   create request because of such a device error.
----------------------------------------------------------------------------
I.e. it is your router box which doesn't accept the job
and there is nothing we can do to slove this problem inside
the router box (therefore the bug is invalid for us).

Therefore you should check the documentation of the router box
or contact the manufacturer of the router box how to dal with
this problem.

By the way:

The ipp/http backend has changed from Suse Linux 10.1 (CUPS 1.1.x)
to openSUSE 10.2 (CUPS 1.2.x) and the new version may detect a problem
with the data transfer to the printer which might have been ignored
by the old version.

Why do you use the most complicated protocol (IPP) for
only the plain data transfer to the printer?

It is well known that many printserver boxes (and network printers)
have somewhat problematic implelentations of the IPP protocol
(e.g. some IPP functionality may be missing) and then the CUPS
ipp/http backend fails to communicate correctly with such a device.

It is recommended to use the simple TCP socket data transfer
if it is supported by the printserver box.
Look for a free port at your printserver box (often it is port 9100)
and read your printserver box manual or use "nmap".

Alternatively any printserver box should support the LPD protocol.

See for example our Suse Linux 10.1 online manual
(package suselinux-manual_en):
/usr/share/doc/manual/suselinux-manual_en/manual/cha.p.html
"11.4.2. Network Printers" and "11.7.4. Network Printer Connections"
and for some general information have a look at
http://www.cups.org/documentation.php/network.html

First: Thanks for helping even if it is not your bug...

The manufacturer isn't very Linux-friendly... a half year ago I had a similar problem with Suse Linux 10.1 and have written to USRobotics, but they just have answered that they arn't supporting Linux and I should ask the community. So I don't think that they will help me now. Randomly I had found a firmware-update and after installing this it was working with Suse 10.1.

Also the manual. It's a "stupid-windows-user-click-by-click"-manual how to get it working in Windows and Mac. But no word about Linux and no word about technical things like open ports.

nmap is showing just 80(the web-interface) and 1631(for printing) as open ports, so simple TCP socket data transfer seems to be impossible here.

In http://www.usr.com/support/doc-popup-template.asp?url=5461/5461-files/printer_installation_linux/index.html is the following written:

----------------------------------------------------------------------------
Note: The MAXg Wireless Router does not support the Line Printer Daemon/Line Printer Remote (LPD/LPR) protocol. IPP must be installed as part of your CUPS installation.
----------------------------------------------------------------------------

So I can forget LPD, too. My only way is using ipp.

So my question: Is it possible to downgrade cups to 1.1.x with the packages from Suse 10.1?? I know, this isn't very nice and just a workaround, but if this would work it seems to be the only way...

One thing by the way: In weekend I tried a lot with printing... try to print from openSUSE 10.2... print from Suse Linux 10.1... reboot router... restart cups... restart printer... and so on. And one time the test-page of openSUSE 10.2 was printed... But I wasn't able to reproduce it. But this lets me hope... it should work anyhow...

The CUPS 1.1.x packages from Suse Linux 10.1 should work on openSUSE 10.2
but perhaps some nice graphical printer setup tools in openSUSE 10.2
may no longer work. Use "lpadmin" instead, see
http://en.opensuse.org/SDB:CUPS_in_a_Nutshell

As the backends are stand-alone programs, it should be sufficient to
copy only the CUPS 1.1.x /usr/lib64/cups/backend/ipp from Suse Linux 10.1
(the http backend is only a symbolic link to the ipp backend).

Finally:
If you find somewhere on the Internet a "stupid" IPP backend for CUPS
(i.e. which doesn't care at all about whatever errors but simply
blindly sends the data to the recipient) you can use this one
(backends are stand-alone programs - see "man backend" - so you can
use whatever program you like - provided it is in compliance to what
is described in "man backend").

If I use /usr/lib64/cups/backend/ipp from 10.1 there's the same error...

but after a simple "rpm -Uvh --nodeps --oldpackage --replacepkgs cups-*" in the suse/x86_64 - directory of the suse 10.1-dvd the printer was printing fine...;-)

BTW: I've searched also in the web about this problems... and I found a lot which have problems with cups 1.2.x... not only suse, also ubuntu, kanotix, debian... So perhaps it would be good if you would make something like cups11-packages, for users like me which has problems with cups 1.2.x... just an idea

*** Bug 231139 has been marked as a duplicate of this bug. ***

I have very same problem.

In 10.0 I could print locally to the printer or via printserver (USR Robotics all-in-one router 9108A).

But when I upgraded to 10.2 printing via printserver is dead. And I cannot trace anything valuable -- cups either "processing" the print job until my death, or gives me an error -- but the message is meaningless, "print-job-refused".

I am so desperate I tried to look at LAN activity (wireshark) but I cannot trace a thing.

My printer, Lexmark E120, was/is configured as network printer, via URI:
http://192.168.1.1:1631/printers/My_Printer

Just to be sure, when the error occured in 10.2, I removed the printer from the system (I mean -> yast2) and added it again. It didn't help.

For the log:
There is a matching upstream problem report:
http://www.cups.org/str.php?L2185

with solution: WONTFIX.

It is really sad that actually no one apparently cares about hardware support -- what we should run the system? On air? 
Suse -> INVALID, Cups -> WONTFIX. Hmm, old story, it is "their" fault. In this case USR.

"So long loser, you bought wrong stuff". How could anyone dream about beating Windows? There it just works. Hmm...

I do not understand why you complain at us about a problem inside
a piece of hardware which seems to be designed to be accessible
only via a special IPP-like protocol (but not true IPP).

In this case only the manufacturer of this piece of hardware can
help you and if there is no interest in any of IPP/LPD/TCP-socket
support, you can use this piece of hardware only with the operating
system for which it is designed.

Johannes, I would agree with you but -- the point of anything is not being correct but doing the job.
So maybe this USR model is broken and maybe CUPS 1.2.x is superb and maybe SUSE 10.2 is excellent. But combining those I cannot print.

And... using this "broken" USR + old, ancient CUPS 1.1.x and not so superb (because there is 10.2) SUSE 10.0, well, I can print. Job is done.

Here is complain -- the professional attitude is to add condition "do you use hardware compliant only with x.y.z software? Yes -> install this version, no? --> install the newest version". So the users could have their job done. That's the whole point.
This way suse could "speak" with most of hardware -- rejecting such attitude you focus on a small set which who knows, how it can shrink in future.

Currently you (and suse team I think) are rejecting valuable knowledge -- USR 9108A works only with cups 1.1.x, not rocket science, but useful for suse users. It (USR printserver) could run out-of-the-box but... it is your call now :-)

Isn't it well explained at http://www.cups.org/str.php?L2185 ?

It has worked before only by pure luck of a combination of two bugs
(imperfect IPP in CUPS 1.1.x and special IPP-like protocol in your
printserver box).

Note my comment #9:
Perhaps you can find somewhere a stand-alone "stupid" IPP backend
for CUPS which might work for your printserver box.
Ideally you find a stand-alone backend for CUPS for exactly
this special IPP-like protocol of your printserver box.
Comment #10 shows that it is actually in the CUPS library what has
changed regarding IPP in CUPS and this makes it totally impossible
to go back because then any IPP communication of CUPS would go back
to the imperfect CUPS 1.1 way.

Of course if I knew a suitable stand-alone backend for your
printserver box, I would have informed you, but only you can
test it because we don't have (and won't buy) this printserver box.

My point is that opensuse 10.3 (next release) should offer two cups versions (or three, or more if necessary). Patch for 10.2 is welcome.

So the end-user could just choose "I have x.y.z hardware" and suse will know which cups version to use. It is better old cups that works than newer that does not work.
Currently the user installs suse, spots the problem, struggles with it, looks at google, enters this report maybe, uninstalls manually cups, installs manually older cups. It should be transparent and automatic.