client 1.2.0 to 1.1.2x server over IPP: client-error-bad-request

Bug #42513 reported by Geo_KM
34
Affects Status Importance Assigned to Milestone
cupsys (Ubuntu)
Fix Released
Medium
Martin Pitt
Dapper
Fix Released
Undecided
Martin Pitt

Bug Description

Hi,

Running Kubuntu Dapper updated as of today 02-05-2006. For the past week I have been unable to print to our ipp based cups server. Other systems are printing fine.

From the command line
lpr 1.ps returns

lpr: Bad Request

From System Settings/Printers

A Test Print returns

A print error occurred. Error message received from system:

cupsdoprint -P 'printer' -J 'KDE Print Test' -H 'lpd:631' -o ' multiple-document-handling=separate-documents-uncollated-copies orientation-requested=3' '/usr/share/apps/kdeprint/testprint.ps' : execution failed with message:
client-error-bad-request
(via knotify)

From OpenOffice

returns just "error while printing"

lpstat -t returns

scheduler is running
system default destination: printer
device for printer: lpd://printer/PASS
printer accepting requests since Thu 01 Jan 1970 10:00:00 EST
printer printer is idle. enabled since Thu 01 Jan 1970 10:00:00 EST
        Data file sent successfully

But in Fact nothing was sent to the cups server.

I'm a little lost at what this error really is, up until a week ago when I notice cups upgraded, it was working fine.

Revision history for this message
Manuel López-Ibáñez (manuellopezibanez) wrote :

Could you check the differences in /var/log/cups/error_log before and after you do "lpr 1.ps returns" (wait until you get the error message) ? Thanks.

Revision history for this message
Geo_KM (keith-barnabasmusic) wrote :

Hi,

There is only 1 entry in /var/log/cups/error_log both before and after I print with "lpr 1.ps" , that is...

E [10/May/2006:11:18:30 +1000] Creating missing directory "/var/run/cups/certs"

So it seems no error is logged. Should I have cupsd start with some non standard logging level?

An interesting point, 3 of us (Me on Kubuntu and the others on Ubuntu (Dapper)) here are now experiencing this problem, although is has become a little more intermittent. That is, every 5-6 attempt to print does seem to get through..... Pretty frustrating, as you can imagine.

I upgreaded the Server machine to (Which is Debian Stable) to 1.1.23-10sarge1 and it has not helped. Meanwhile all the others here at ozlabs are using Debian Unstable and not having any printing problems.?? Weird.

Thanks for yor help.

Revision history for this message
sbothe (ubuntu-sbothe) wrote :

Hi,

Using a new installation of Kubuntu dapper flight 7 and I have the same Problem described above. Other stations in Network running SuSE10 are not affected as well. Please let me know what information could be useful to track the problem.

Thanks for help

Revision history for this message
Manuel López-Ibáñez (manuellopezibanez) wrote :

Could you tell me your current cupsys version ? (you may find it by writting " dpkg -l cupsys | awk '/^ii/{print $2" "$3}' " in a terminal.)

Thanks.

Revision history for this message
Ante Karamatić (ivoks) wrote :

My guess is that you don't have default printer. Try:

lpq

and then

lpq -P [name-of-the-printer]

This wouldn't be first time I see this.

Revision history for this message
sbothe (ubuntu-sbothe) wrote : Re: [Bug 42513] Re: Trying to Print produces lpr: Bad Request

Hi,
On Friday 12 May 2006 13:03, manu wrote:
> Could you tell me your current cupsys version ? (you may find it by
> writting  " dpkg -l cupsys | awk '/^ii/{print $2"  "$3}' " in a
> terminal.)
Of course, cupsys on the Priniting Server is
cupsys 1.1.23-15 (debian testing)
and the kubuntu cupsys (for the client maschine) is
cupsys 1.2.0-0ubuntu2

Thank you for your help!
>
> Thanks.
>
> --
> Trying to Print produces lpr: Bad Request
> https://launchpad.net/bugs/42513

Revision history for this message
sbothe (ubuntu-sbothe) wrote :

Hi,
On Friday 12 May 2006 13:40, Ante Karamatić wrote:
> My guess is that you don't have default printer. Try:
>
> lpq
>
I added -h <print_server> because I only use the remote printer queue. There
are no local queues
# lpq -h artus
kyocera is ready
no entries

> and then
>
> lpq -P [name-of-the-printer]
# lpq -h artus -P kyocera
kyocera is ready
no entries
>
> This wouldn't be first time I see this.
I don't think this is the problem, but thanks for your guess.
>
> --
> Trying to Print produces lpr: Bad Request
> https://launchpad.net/bugs/42513
>
>

Revision history for this message
sbothe (ubuntu-sbothe) wrote : Re: Trying to Print produces lpr: Bad Request

Hi,

  again - Playing around with the command line tools I found the following:
cupsdoprint -P <printer> -H <host> <file>
=> client-error-bad-request
swapping the options Printer and Host,
cupsdoprint -H <host> -P <printer> <file>
produces normal printout. Can anyone confirm? This seems to be very strange, but perhaps solves the problem.

Revision history for this message
Manuel López-Ibáñez (manuellopezibanez) wrote :

Are you sure about that? Does it work for the other people affected by this problem (using both Ubuntu and Kubuntu) ?

Revision history for this message
sbothe (ubuntu-sbothe) wrote :

I'm very confused about that as well, but I tried several times and the behaviour does not change. Even when using lpq I get,
# lpq -h artus -P kyocera
kyocera is ready
no entries
# lpq -P kyocera -h artus
lpq: Unable to connect to server
Very strange..

Revision history for this message
Manuel López-Ibáñez (manuellopezibanez) wrote :

Could you ask your colleagues using other distributions (Suse and Debian Unstable I think you mentioned) to try both commands and also which version of CUPS they are running ?

I am trying to figure out if this is just an Ubuntu issue and from which version of CUPS the problem originated.

Thanks.

Revision history for this message
sbothe (ubuntu-sbothe) wrote :

Hi,
the SuSE Boxes use cups-client-1.1.23-21, and order of Options does not change anything. The Version on the debian system seems to be same revision excpect the debian added string -15. Printing works and ordering of arguments makes no difference as well.

I took a closer look at what I did on the Kubuntu System and noticed I always executed those two commands in same sequence. What I was not able to see by doing so ist that executing the command twice produces output and is not dependend on argument order. Sorry about the misleading information.

Revision history for this message
Manuel López-Ibáñez (manuellopezibanez) wrote :

I am sorry, your last paragraph lost me completely... do you mean that if you execute "lpq -P kyocera -h artus" twice, the second time it works?

That would be too weird...

Revision history for this message
Manuel López-Ibáñez (manuellopezibanez) wrote :

With respect to the other distribution, they are using an older version of cups (1.1) than dapper (1.2). Now the question is if the bug was introduced by Ubuntu or it is present in the original cups 1.2.0

Also, I made a little error before. Could you check /var/log/cups/error_log in the server machine? Perhaps there is any hint there...

Revision history for this message
sbothe (ubuntu-sbothe) wrote :

Sorry for delaying, I left before I saw your last post- The Cups log on Server maschine says:
E [14/May/2006:21:20:37 +0200] ReadClient: 7 IPP Read Error!

Does this bring us any further? Would increasing log level be of interest?

Revision history for this message
Manuel López-Ibáñez (manuellopezibanez) wrote :

Well, now we know that the client reaches the printer host. It must be some protocol problem between both. However it is kind of weird that repeating the command (or swaping the command options) works.

You may try to change the debug level in the server machine:

o Edit the file /etc/cups/cupsd.conf
o Change the line LogLevel from "info" to "debug" .
o Restart cupsd: killall -HUP cupsd

Also, please do two trials in a row (you said that the first one doesn't print while the second one does...)

Revision history for this message
Martin Pitt (pitti) wrote :

Please restart cups with

  sudo /etc/init.d/cupsys restart

killall -HUP will most likely not work.

Revision history for this message
Manuel López-Ibáñez (manuellopezibanez) wrote :

Martin, the server is using Debian, which is the appropriate command to restart cupsd in Debian?

Revision history for this message
Ante Karamatić (ivoks) wrote : Re: [Bug 42513] Re: Trying to Print produces lpr: Bad Request

On Mon, 15 May 2006 09:27:43 -0000
manu <email address hidden> wrote:

> Martin, the server is using Debian, which is the appropriate command
> to restart cupsd in Debian?

/etc/init.d/cups* restart

--
Ante Karamatic | 0xD3BDA225 | 0x0A4A0161
<email address hidden> | <email address hidden> | ivoks.blogspot.com
"Tomorrow is my day off, so please stay off the powder!"

Revision history for this message
sbothe (ubuntu-sbothe) wrote : Re: Trying to Print produces lpr: Bad Request
Download full text (21.1 KiB)

This is the server log generated while "processing" a print job from the kde print dialog. Result is no output. I will try to get a track of a successful print with repeated execution now, may take a moment..

Thanks for your help!

D [15/May/2006:13:08:22 +0200] ReadClient: 5 POST / HTTP/1.1
D [15/May/2006:13:08:22 +0200] ProcessIPPRequest: 5 status_code=0
D [15/May/2006:13:08:22 +0200] AcceptClient: 6 from 192.168.0.100:631.
D [15/May/2006:13:08:22 +0200] ReadClient: 6 GET /printers/kyocera.ppd HTTP/1.1
D [15/May/2006:13:08:22 +0200] SendFile: 6 file=8
D [15/May/2006:13:08:22 +0200] CloseClient: 6
D [15/May/2006:13:08:23 +0200] AcceptClient: 6 from 192.168.0.100:631.
D [15/May/2006:13:08:23 +0200] ReadClient: 6 POST /printers/kyocera HTTP/1.1
D [15/May/2006:13:08:24 +0200] print_job: auto-typing file...
D [15/May/2006:13:08:24 +0200] print_job: request file type is application/postscript.
D [15/May/2006:13:08:24 +0200] CancelJob: id = 843
D [15/May/2006:13:08:24 +0200] check_quotas: requesting-user-name = 'sbothe'
D [15/May/2006:13:08:24 +0200] print_job: requesting-user-name = 'sbothe'
D [15/May/2006:13:08:24 +0200] Adding default job-sheets values "none,none"...
I [15/May/2006:13:08:24 +0200] Adding start banner page "none" to job 1343.
I [15/May/2006:13:08:24 +0200] Adding end banner page "none" to job 1343.
I [15/May/2006:13:08:24 +0200] Job 1343 queued on 'kyocera' by 'sbothe'.
D [15/May/2006:13:08:24 +0200] Job 1343 hold_until = 0
D [15/May/2006:13:08:24 +0200] StartJob(1343, 0x8094a10)
D [15/May/2006:13:08:24 +0200] StartJob() id = 1343, file = 0/1
D [15/May/2006:13:08:24 +0200] job-sheets=none,none
D [15/May/2006:13:08:24 +0200] banner_page = 0
D [15/May/2006:13:08:24 +0200] StartJob: argv = "kyocera","1343","sbothe","KDE Print System","1","orientation-requested=3","/var/spool/cups/d01343-001"
D [15/May/2006:13:08:24 +0200] StartJob: envp[0]="PATH=/usr/lib/cups/filter:/bin:/usr/bin"
D [15/May/2006:13:08:24 +0200] StartJob: envp[1]="SOFTWARE=CUPS/1.1"
D [15/May/2006:13:08:24 +0200] StartJob: envp[2]="USER=root"
D [15/May/2006:13:08:24 +0200] StartJob: envp[3]="CHARSET=utf-8"
D [15/May/2006:13:08:24 +0200] StartJob: envp[4]="LANG=en_AU"
D [15/May/2006:13:08:24 +0200] StartJob: envp[5]="TZ=Europe/Berlin"
D [15/May/2006:13:08:24 +0200] StartJob: envp[6]="PPD=/etc/cups/ppd/kyocera.ppd"
D [15/May/2006:13:08:24 +0200] StartJob: envp[7]="CUPS_SERVERROOT=/etc/cups"
D [15/May/2006:13:08:24 +0200] StartJob: envp[8]="RIP_MAX_CACHE=8m"
D [15/May/2006:13:08:24 +0200] StartJob: envp[9]="TMPDIR=/var/spool/cups/tmp"
D [15/May/2006:13:08:24 +0200] StartJob: envp[10]="CONTENT_TYPE=application/postscript"
D [15/May/2006:13:08:24 +0200] StartJob: envp[11]="DEVICE_URI=parallel:/dev/lp0"
D [15/May/2006:13:08:24 +0200] StartJob: envp[12]="PRINTER=kyocera"
D [15/May/2006:13:08:24 +0200] StartJob: envp[13]="CUPS_DATADIR=/usr/share/cups"
D [15/May/2006:13:08:24 +0200] StartJob: envp[14]="CUPS_FONTPATH=/usr/share/cups/fonts"
D [15/May/2006:13:08:24 +0200] StartJob: envp[15]="CUPS_SERVER=localhost"
D [15/May/2006:13:08:24 +0200] StartJob: envp[16]="IPP_PORT=631"
D [15/May/2006:13:08:24 +0200] StartJob: statusfds = [ 8...

Revision history for this message
sbothe (ubuntu-sbothe) wrote :
Download full text (17.2 KiB)

ok, here is a track of two times in row execution- To make more fun this time the first trial of "cupsdoprint -P kyocera -H artus print.ps" generated a printout and the second one not. I don't know what to say about this any further, the behavior seems to be some kind of undeterministic :-(
Perhaps you can figure out what goes wrong here, these are the entries in error_log..

D [15/May/2006:13:18:05 +0200] AcceptClient: 6 from 192.168.0.100:631.
D [15/May/2006:13:18:05 +0200] ReadClient: 6 POST /printers/kyocera HTTP/1.1
D [15/May/2006:13:18:06 +0200] print_job: auto-typing file...
D [15/May/2006:13:18:06 +0200] print_job: request file type is application/postscript.
D [15/May/2006:13:18:06 +0200] CancelJob: id = 845
D [15/May/2006:13:18:06 +0200] check_quotas: requesting-user-name = 'sbothe'
D [15/May/2006:13:18:06 +0200] print_job: requesting-user-name = 'sbothe'
D [15/May/2006:13:18:06 +0200] Adding default job-sheets values "none,none"...
I [15/May/2006:13:18:06 +0200] Adding start banner page "none" to job 1345.
I [15/May/2006:13:18:06 +0200] Adding end banner page "none" to job 1345.
I [15/May/2006:13:18:06 +0200] Job 1345 queued on 'kyocera' by 'sbothe'.
D [15/May/2006:13:18:06 +0200] Job 1345 hold_until = 0
D [15/May/2006:13:18:06 +0200] StartJob(1345, 0x8094a10)
D [15/May/2006:13:18:06 +0200] StartJob() id = 1345, file = 0/1
D [15/May/2006:13:18:06 +0200] job-sheets=none,none
D [15/May/2006:13:18:06 +0200] banner_page = 0
D [15/May/2006:13:18:06 +0200] StartJob: argv = "kyocera","1345","sbothe","KDE Print System","1","","/var/spool/cups/d01345-001"
D [15/May/2006:13:18:06 +0200] StartJob: envp[0]="PATH=/usr/lib/cups/filter:/bin:/usr/bin"
D [15/May/2006:13:18:06 +0200] StartJob: envp[1]="SOFTWARE=CUPS/1.1"
D [15/May/2006:13:18:06 +0200] StartJob: envp[2]="USER=root"
D [15/May/2006:13:18:06 +0200] StartJob: envp[3]="CHARSET=utf-8"
D [15/May/2006:13:18:06 +0200] StartJob: envp[4]="LANG=en_AU"
D [15/May/2006:13:18:06 +0200] StartJob: envp[5]="TZ=Europe/Berlin"
D [15/May/2006:13:18:06 +0200] StartJob: envp[6]="PPD=/etc/cups/ppd/kyocera.ppd"
D [15/May/2006:13:18:06 +0200] StartJob: envp[7]="CUPS_SERVERROOT=/etc/cups"
D [15/May/2006:13:18:06 +0200] StartJob: envp[8]="RIP_MAX_CACHE=8m"
D [15/May/2006:13:18:06 +0200] StartJob: envp[9]="TMPDIR=/var/spool/cups/tmp"
D [15/May/2006:13:18:06 +0200] StartJob: envp[10]="CONTENT_TYPE=application/postscript"
D [15/May/2006:13:18:06 +0200] StartJob: envp[11]="DEVICE_URI=parallel:/dev/lp0"
D [15/May/2006:13:18:06 +0200] StartJob: envp[12]="PRINTER=kyocera"
D [15/May/2006:13:18:06 +0200] StartJob: envp[13]="CUPS_DATADIR=/usr/share/cups"
D [15/May/2006:13:18:06 +0200] StartJob: envp[14]="CUPS_FONTPATH=/usr/share/cups/fonts"
D [15/May/2006:13:18:06 +0200] StartJob: envp[15]="CUPS_SERVER=localhost"
D [15/May/2006:13:18:06 +0200] StartJob: envp[16]="IPP_PORT=631"
D [15/May/2006:13:18:06 +0200] StartJob: statusfds = [ 8 9 ]
D [15/May/2006:13:18:06 +0200] StartJob: filterfds[1] = [ 10 -1 ]
D [15/May/2006:13:18:06 +0200] StartJob: filter = "/usr/lib/cups/filter/pstops"
D [15/May/2006:13:18:06 +0200] StartJob: filterfds[0] = [ 11 12 ]
D [15/May/2006:13:18:06 +0200] start_...

Revision history for this message
Manuel López-Ibáñez (manuellopezibanez) wrote :

Hmm, next time, please, put the log in a file and attach it.

The job in the first log fails from a problem in the postscript (I think). Relevant lines:

D [15/May/2006:13:08:30 +0200] [Job 1343] Closing renderer
D [15/May/2006:13:08:30 +0200] [Job 1343] Error: /configurationerror in --setpagedevice--
D [15/May/2006:13:08:30 +0200] [Job 1343] Additional information: [/Duplex true]
D [15/May/2006:13:08:30 +0200] [Job 1343] Operand stack:
D [15/May/2006:13:08:30 +0200] [Job 1343] --dict:4/6(L)--
D [15/May/2006:13:08:30 +0200] [Job 1343] ESP Ghostscript 815.01: Unrecoverable error, exit code 1

The second job of the second log fails for an unknown reason:
D [15/May/2006:13:18:07 +0200] AcceptClient: 6 from 192.168.0.100:631.
D [15/May/2006:13:18:07 +0200] ReadClient: 6 POST /printers/kyocera HTTP/1.1
E [15/May/2006:13:18:08 +0200] ReadClient: 6 IPP Read Error!
D [15/May/2006:13:18:08 +0200] SendError: 6 code=400 (Bad Request)
D [15/May/2006:13:18:08 +0200] CloseClient: 6

Both are the same postscript file, isn't it?

Perhaps relevant to this is bug 41593.

Revision history for this message
sbothe (ubuntu-sbothe) wrote :

Sorry for the "bulk" data above, I posted through web interface, I'll use email with attachment next time.
The first log (single execution) is produced by print dialog of kde, trying to print first page of an pdf document. Second log (two executions) is generated by printing first page of the same pdf to a ps and using cupsdoprint from a console manually. The kdeprinting generates a temporary ps as well.

Revision history for this message
Manuel López-Ibáñez (manuellopezibanez) wrote :

You can attach files through the web interface (Menu on the top-left "Add attachment").

Revision history for this message
sbothe (ubuntu-sbothe) wrote :

Hello again,

  I can workaround with a local printer queue that points to the ipp printer on the printserver. - Only as a remark if someone reads this thread and needs a working printer soon..

Revision history for this message
Ulrich Lukas (ulrich-lukas) wrote : Re: Same problem, same behaviour

Hi!

I can confirm this problem and the strange behaviour that it matters in which order the arguments are passed to "cupsdoprint".

"cupsdoprint -P Epl5900l_fiapp0 -H fiapp0 n.ps"
==> "client-error-bad-request"

"cupsdoprint -H fiapp0 n.ps -P Epl5900l_fiapp0 n.ps"
==> normal printout

I would consider this a serious bug, because printing is a very common task...

My CUPS-Version:
"cupsys 1.2.0-0ubuntu5"

My system ist Dapper Drake as at today, 29.05.2006.

Best wishes,
Ulrich

Revision history for this message
Manuel López-Ibáñez (manuellopezibanez) wrote : Re: Trying to Print produces lpr: Bad Request

confirmed by several users

Changed in cupsys:
status: Unconfirmed → Confirmed
Revision history for this message
Manuel López-Ibáñez (manuellopezibanez) wrote :

Ulrich, please, read the whole thread.

Do you get the same errors in the logs?
What is the version of your cups server?
The initial reporter said that executing the command twice produces output and is not dependend on argument order, is it the same for you?
Thanks.

Revision history for this message
blaise (blaise-vogel) wrote :

I have the same bug.
1. First print order have the bug
2
. Second print order is ok !!

Revision history for this message
Manuel López-Ibáñez (manuellopezibanez) wrote :

blaise, please, could you read the whole thread and answer the following questions?

Do you get the same errors in the logs?

What is the version of your cups server?

The initial reporter said that executing the command twice produces output, is it the same for you?

Thanks.

Revision history for this message
blaise (blaise-vogel) wrote :

client: kubuntu dapper up to date
server: debian sarge - cupsys 1.1.23-10sarge1
Same error in the log, executing the command twice produces output !

Revision history for this message
Manuel López-Ibáñez (manuellopezibanez) wrote :

Thanks blaise, this seems to confirm that it is an interaction issue between cups client version 1.2 and cups server version 1.1

I am not sure if raising the severity level is proper, since there exists an obvious workaround. Also, it may not depend on Ubuntu but rather upstream to fix this bug.

Revision history for this message
Manuel López-Ibáñez (manuellopezibanez) wrote :

If someone has time, he/she could search upstream ( http://www.cups.org/str.php ) and open a bug report there if there is no similar issue already opened. Then, please link this bug report with upstream by using the "Link to Other Bug Tracker" option on the top-left menu. Thanks in advance.

Revision history for this message
Ulrich Lukas (ulrich-lukas) wrote :

Hi,

manu wrote:
> > Do you get the same errors in the logs?

If I do a "cat /var/log/cups/error_log" on the client computer, then the
file is empty.

The /var/log/cups/error_log from the server machine is included in the
attachement of this posting. (Only the lower part of the file should be
of interest)

> > What is the version of your cups server?

The CUPS-Version on the server is:
cupsys 1.1.23-15 (Debian testing)

> > The initial reporter said that executing the command twice produces output and is not dependend on argument order, is it the same for you?

I tried it some more times, and in fact, it is a bit weird:
If I try to print with this commandline:

"cupsdoprint -P Epl5900l_fiapp0 -H fiapp0 n.ps",

it actually works after about five to ten invocations. It works one or
two times, and then again there is the message
"client-error-bad-request" for the next ten tries.

If I use exactly this command:
"cupsdoprint -H fiapp0 n.ps -P Epl5900l_fiapp0 n.ps"

Then it seems to always work.

YES, the file "n.ps" is listed two times! Maybe only that is the
important thing (sporadic error/timing problems...) and not the order.

HTH,
Ulrich

Revision history for this message
Ulrich Lukas (ulrich-lukas) wrote :

Hi,

manu wrote:
> > Do you get the same errors in the logs?

If I do a "cat /var/log/cups/error_log" on the client computer, then the
file is empty.

The /var/log/cups/error_log from the server machine can be downloaded here:
> http://datenparkplatz.de/DiesUndDas/error_log.txt
(Only the lower part of the file should be of interest)

> > What is the version of your cups server?

The CUPS-Version on the server is:
cupsys 1.1.23-15 (Debian testing)

> > The initial reporter said that executing the command twice produces output and is not dependend on argument order, is it the same for you?

I tried it some more times, and in fact, it is a bit weird:
If I try to print with this commandline:

"cupsdoprint -P Epl5900l_fiapp0 -H fiapp0 n.ps",

it actually works after about five to ten invocations. It works one or
two times, and then again there is the message
"client-error-bad-request" for the next ten tries.

If I use exactly this command:
"cupsdoprint -H fiapp0 n.ps -P Epl5900l_fiapp0 n.ps"

Then it seems to always work.

YES, the file "n.ps" is listed two times! Maybe only that is the
important thing (sporadic error/timing problems...) and not the order.

HTH,
Ulrich

Revision history for this message
Manuel López-Ibáñez (manuellopezibanez) wrote :

Ulrich, please, could you use the web interface to add the file as an attachment using the top-left menu. I hope you understand that external files have the bad habit of suddenly dissapearing. Thanks in advance.

Revision history for this message
Manuel López-Ibáñez (manuellopezibanez) wrote :

There is a patch here (found in bug 42802):
http://www.easysw.com/~mike/cups/newsgroups.php?s1711+gcups.commit+v1720+T0

This may or may not fix the issue. It seems this patch will be available in cups 1.2.1, not sure if it is already included in Ubuntu's version. If somebody can build an experimental deb package using this patch and attach it, others could test if it fixes the problem. Unfortunately, I have no experience building debian packages (yet).

Revision history for this message
Ulrich Lukas (ulrich-lukas) wrote : error_log

There you go!

(And sorry this ist my third attempt to post the file - I'm new to Ubuntu and to this place)

File: error_log from my print server: Debian testing, cupsys 1.1.23-15.

Revision history for this message
Manuel López-Ibáñez (manuellopezibanez) wrote : Re: Trying to Print produces lpr: Bad Request

As the current release cups 1.2.0-0ubuntu5, that patch has not been applied (see Changelog at:
http://changelogs.ubuntu.com/changelogs/pool/main/c/cupsys/cupsys_1.2.0-0ubuntu5/changelog ), so there are some chances that if you apply the patch and build a new package, it fixes the issue. I doubt it will make into Dapper, though. At least you will have fix ...

Revision history for this message
Manuel López-Ibáñez (manuellopezibanez) wrote :

Thanks Ulrich, I am 99% sure that it is the same issue.

Revision history for this message
Tom Albers (tomalbers-deactivatedaccount) wrote :

Ok, I'm no pro in building packages, but I've rebuild them with the patch on that url. Consider them experimental. I can only try them tomorrow, but here they are: http://www.omat.nl/cups/
Again:unofficial, experimental.

Revision history for this message
Steffen Neumann (sneumann) wrote :

Thanks Tom for the packages, they solved my problem printing from dapper cups-1.2 client to a cups-1.1.x server as well. Investigating my problem earlier I found a few bug reports in launchpad that sounded similar, so a fix for dapper (at least -updates) should have a high priority.
Yours,
Steffen

Revision history for this message
Tom Albers (tomalbers-deactivatedaccount) wrote :

My packages dont work for me though. Changing the paramaters did not change anything either. Out of the ten tries, one succeeded:

$ cupsdoprint -H nummer64 -P 'C1900PS' 8.pdf
client-error-bad-request
$ cupsdoprint -H nummer64 -P 'C1900PS' 8.pdf
$ cupsdoprint -H nummer64 -P 'C1900PS' 8.pdf
client-error-bad-request
$ cupsdoprint -H nummer64 -P 'C1900PS' 8.pdf
client-error-bad-request
$ cupsdoprint -H nummer64 -P 'C1900PS' 8.pdf
client-error-bad-request
$ cupsdoprint -P 'C1900PS' -H nummer64 8.pdf
client-error-bad-request
$ cupsdoprint -P 'C1900PS' -H nummer64 8.pdf
client-error-bad-request
$ cupsdoprint -P 'C1900PS' -H nummer64 8.pdf
client-error-bad-request
$ cupsdoprint -P 'C1900PS' -H nummer64 8.pdf
client-error-bad-request

Revision history for this message
Manuel López-Ibáñez (manuellopezibanez) wrote :

Geo_KM and Ulrich, could you test the packages kindly built by Tom? Test them for one or two days before reporting just to be sure that they fix the issue. Thanks.

Revision history for this message
Manuel López-Ibáñez (manuellopezibanez) wrote :

Oh, bad luck then. It is strange that they work for Steffen, though. And please, get out of your mind the crazy idea that the fix will make into Dapper. It is delusional. Not even the craziest maintainer will add stuff to his package one or two days before release. Moreover, when there is no confirmation at all that the stuff does fix anything. I hope you understand.

Revision history for this message
Ulrich Lukas (ulrich-lukas) wrote :

I'm sorry, but the patched packages don't work for me, too.

The error message seems to be the same, basically. I've added the new error_log from the server machine.

Revision history for this message
Ulrich Lukas (ulrich-lukas) wrote : error_log

error_log

(Client:
cupsys_1.2.0-0ubuntu5-toma1_i386
libcupsys2_1.2.0-0ubuntu5-toma1_i386
cupsys-client_1.2.0-0ubuntu5-toma1_i386
libcupsys2-gnutls10_1.2.0-0ubuntu5-toma1_all
)

Revision history for this message
Manuel López-Ibáñez (manuellopezibanez) wrote : Re: Trying to Print produces lpr: Bad Request

Ulrich, next time please, use a different name for the file (for example, error_log_cupsys_1.2.0-0ubuntu5-toma1_i386). Anyway, I didn't do a thorough search of the bug reports in upstream ( http://www.cups.org/str.php ). You could also open a bug report there.

Revision history for this message
Ulrich Lukas (ulrich-lukas) wrote : Bug report on www.cups.org

This bug is already listet on www.cups.org under STR #1717.

> http://www.cups.org/str.php?L1717+P0+S-2+C0+I0+E0+Qbad+request

(Btw.: http://www.kdedevelopers.org/node/2064 - no comment)

Revision history for this message
Manuel López-Ibáñez (manuellopezibanez) wrote :

Another try, Ante Karamatić has packaged CUPS 1.2.1 for Dapper [*]. Again, this is *experimental*, install it *at your own risk*.

[*] http://www.grad.hr/~ivoks/ubuntu/cups

Revision history for this message
Ante Karamatić (ivoks) wrote :

This packages shouldn't fix this issue. It's worth to try, but I don't guarantee anything. Anyway, report chagnes.

Revision history for this message
Tom Albers (tomalbers-deactivatedaccount) wrote :

Packages at http://www.grad.hr/~ivoks/ubuntu/cups/ do not fix the problem.

Revision history for this message
Ante Karamatić (ivoks) wrote :

That was expected. This packages weren't ment to resolve this bug. Upstream is aware of this problem and it's solution is pending, so best thing is to wait untill fix is released.

Revision history for this message
Claudio Bernardini (claudiob) wrote :

I can confirm the bug as I upgraded all my clients machines from Breezy to Dapper. Now we cannot print anymore to a 1.1.2x cups server over IPP. I think our solution, while waiting for a fix, is to point directly to the printers from the clients.

Revision history for this message
Geo_KM (keith-barnabasmusic) wrote : Re: [Bug 42513] Re: Trying to Print produces lpr: Bad Request

Hi Sorry for the delay.

Yeah, these did not fix the problem for me either...... 8-(

On Wednesday 31 May 2006 18:07, manu wrote:
> Geo_KM and Ulrich, could you test the packages kindly built by Tom? Test
> them for one or two days before reporting just to be sure that they fix
> the issue. Thanks.

Revision history for this message
Ante Karamatić (ivoks) wrote :

Please, take a look at bug 45099 and my comments for problems with printing to CUPS <1.2 servers.

Revision history for this message
Jordi Mallach (jordi) wrote :

Claudio, what do you mean with "point directly to the printers"?

I'm having this problem at the office, have tried several changes to our ocnfig but no luck just yet.

Revision history for this message
Claudio Bernardini (claudiob) wrote : Re: [Bug 42513] Re: client 1.2.0 to 1.1.2x server over IPP: client-error-bad-request

Il giorno mer, 05/07/2006 alle 12.29 +0000, Jordi Mallach ha scritto:
> Claudio, what do you mean with "point directly to the printers"?
>
> I'm having this problem at the office, have tried several changes to our
> ocnfig but no luck just yet.

I think I had a setting in /etc/cups/cupsd.conf ponting all of o the
jobs to a cups server (don't remember cups version... was on SuSE 8.2)
my ubuntu machines. I checked right now the man for cupsd but cannot'
find it. I removed the line pointing to the server and activated auto
finding of lan printers, everything then went ok and we could print
happily. May not be so helpful but I don't remeber more and far away to
check comments I left in the conf. Sorry.
Just it happened upgrading client machines from hoary to dapper.

Revision history for this message
Ante Karamatić (ivoks) wrote :

@Claudio

Hoary -> Dapper isn't supported. The file you are talking about is /etc/cups/client.conf which probably had line:

ServerName IP_OF_YOUR_SERVER

Revision history for this message
Jordi Mallach (jordi) wrote :

I have managed to make it work changing the DeviceURI of my printer to use http as a protocol.

DeviceURI http://10.0.0.160:631/ipp/

This works flawlessly.

Revision history for this message
Claudio Bernardini (claudiob) wrote :

Il giorno gio, 06/07/2006 alle 06.42 +0000, Ante Karamatić ha scritto:
> @Claudio
>
> Hoary -> Dapper isn't supported. The file you are talking about is
> /etc/cups/client.conf which probably had line:
>
> ServerName IP_OF_YOUR_SERVER

Yes you are right, that was the file.
Sorry but I am away and could not check.

Revision history for this message
Claudio Bernardini (claudiob) wrote :

Il giorno gio, 06/07/2006 alle 10.27 +0000, Jordi Mallach ha scritto:
> I have managed to make it work changing the DeviceURI of my printer to
> use http as a protocol.
>
> DeviceURI http://10.0.0.160:631/ipp/
>
> This works flawlessly.

After the upgrade of Dapper today I cannot print anymore on the cups
server from ubuntu dapper clients.

You mean you solved changing the DeviceURI of the printers automatically
discovered from the cups browser on the client side?

Thanks
--
Claudio Bernardini <email address hidden>
COMVERT

Revision history for this message
Ante Karamatić (ivoks) wrote :

Claudio, check /var/log/cups/error.log and add relevant lines here.

Revision history for this message
Claudio Bernardini (claudiob) wrote :

Ante, I checked /var/log/cups/error.log and no error lines appear.

When I print the test page from the dapper client a blank page comes out of the printer.

Revision history for this message
Claudio Bernardini (claudiob) wrote :

Sorry for the duplicate posts above (if someone with admin permission can remove them I am thankful).

The problem I was experiencing after last updates was definitely mine and NOT related to cups on Dapper. For me it is solved.

Revision history for this message
Fabien (fabien-ubuntu) wrote :

Hi, I have exactly the same troubles (ubuntu cups 1.2 client trying to print on debian sarge 1.1 server).
Sending the same command will result in random errors (2 on 10 succeded).

Cups released a fix yesterday in their svn repository :
http://www.cups.org/str.php?L1717

<<
mike
13:57 Jul 18, 2006 Fixed in Subversion repository.
>>

Could we hope to get updated packages for that ?

Thanks.

Revision history for this message
Fabien (fabien-ubuntu) wrote :

Finally, I decided to build myself the packages with the patch.

I installed them and it fixed the problems I had.

Here are the package files I built (they work for me, but no warranty !) :
http://chara.epfl.ch/ubuntu/cups/

FYI, here's the patch :

--- cups-bogus/cups/http.c
+++ cups/cups/http.c
@@ -1809,6 +1809,16 @@
     return (1);

  /*
+ * Flush pending data, if any...
+ */
+
+ if (http->wused)
+ {
+ if (httpFlushWrite(http) < 0)
+ return (0);
+ }
+
+ /*
   * If not, check the SSL/TLS buffers and do a select() on the connection...
   */

Revision history for this message
Martin Pitt (pitti) wrote :

Fabien, thanks for the link to the upstream fix. This looks appropriate for dapper-updates.

Changed in cupsys:
assignee: nobody → pitti
status: Confirmed → In Progress
assignee: nobody → pitti
status: Unconfirmed → In Progress
Revision history for this message
Martin Pitt (pitti) wrote :

 cupsys (1.2.2-0ubuntu1) edgy; urgency=low
 .
   * Merge to Debian unstable:
     - This gets rid of /etc/cups/conf.d/ again and re-merges the separate
       browsing and ports settings to /etc/cups/cupsd.conf again. Separating
       was nice for preserving an unchanged conffile for the most important
       settings, but it broke KDE and the web interface and generated way too
       many bugs. Closes: LP#37892, LP#50804, LP#53582
    * Update to new upstream version 1.2.2 (UVF exception granted by by Matt
      Zimmerman):
      - Fixes printing to 1.1.x servers. Closes: LP#42513, LP#42802
      - Fixes parsing of some PostScript files which previously generated empty
        pages. Closes: LP#51432
      - Fixes parsing of network masks. Closes: LP#52390
      - Lots of more fixes, see upstream changelog.
   * debian/cupsys.preinst: Drop some obsolete migration bits for
     Breezy->Dapper upgrade.
   * debian/control: Add libdbus-1-dev build dependency to enable dbus support.
   * debian/cupsys.examples: Do not ship .svn files (upstream Makefiles install
     them).
   * cupsys.postinst: Fix permissions of cupsd.conf to be writable by user
     cupsys world-readable.
   * debian/local/enable_{sharing,browsing}, {sharing,browsing}_status: Adapt
     to new single configuration file format.
   * debian/rules: Clean cups/raster.h symlink to unbreak source package build.
   * Add debian/patches/ubuntu-disable-browsing.dpatch: Disable browsing by
     default to avoid open port and stay compatible to previous releases.

Changed in cupsys:
status: In Progress → Fix Released
Revision history for this message
Martin Pitt (pitti) wrote :

 cupsys (1.2.2-0ubuntu0.6.06) dapper-updates; urgency=low
 .
   * New upstream bugfix release:
      - Fixes printing to 1.1.x servers. Closes: LP#42513, LP#42802
      - Fixes parsing of some PostScript files which previously generated empty
        pages. Closes: LP#51432
      - Fixes parsing of network masks. Closes: LP#52390
      - Lots of more fixes, see upstream changelog.
   * Dropped debian/patches/00_r{5643,5660}.dpatch: Upstream now.
   * debian/patches/02_configure.dpatch,
     debian/patches/09_runasuser_autoconf.dpatch: Adapted to new upstream
     version (taken from current edgy package).

Changed in cupsys:
status: In Progress → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.