FS#30975 - [cups] lpstat: Bad request. Printing will not work
Attached to Project:
Arch Linux
Opened by roko (roko) - Thursday, 02 August 2012, 11:55 GMT
Last edited by Andreas Radke (AndyRTR) - Saturday, 04 August 2012, 08:55 GMT
Opened by roko (roko) - Thursday, 02 August 2012, 11:55 GMT
Last edited by Andreas Radke (AndyRTR) - Saturday, 04 August 2012, 08:55 GMT
|
Details
Description:
This is a regression. With the newest version of libcups (1.6.1-1) I cannot get a list of printers from the remote cups server. Running lpstat gives: $ lpstat -a lpstat: Bad Request Everything works with libcups-1.5.3-5 and cups-1.5.3-5. In the attachment the output of the strace lpstat -a (the case, in which I get Bad request). 
strace-lpstat.txt
(26.9 KiB)
|
This task depends upon
Note: This behavior has not been changed with cups 1.6.x - the difference is that until 1.5.x cupsd was able to do printer browsing alone and now needs avahi to discover unknown printers!
Maybe it should be: has been changed, not has NOT been changed?
ServerName 192.168.1.90:631
That's what I have and lpstat shows up here all printers that my server allows to be browsable. The server may need some changes if it's also running Arch or some
other distro that also upgraded to cups 1.6.x.
Using strace I was able to do the following findings:
a)with an older libcups, that works:
sendto(4, "POST / HTTP/1.1\r\nContent-Length: 349\r\nContent-Type: application/ipp\r\nHost: 134.34.57.71\r\nUser-Agent: CUPS/1.5.3\r\nExpect: 100-continue\r\n\r\n", 137, 0, NULL, 0) = 137
sendto(4, "\1\1\0\n\0\0\0\1\1G\0\22attributes-charset\0\5utf-8H\0\33attributes-natural-language\0\5en-usE\0\vprinter-uri\0\20ipp://localhost/D\0\24requested-attributes\0\6job-idD\0\0\0\fjob-k-octetsD\0\0\0\10job-nameD\0\0\0\31job-originating-user-nameD\0\0\0\31job-printer-state-messageD\0\0\0\17job-printer-uriD\0\0\0\21job-state-reasonsD\0\0\0\20time-at-creationB\0\24requesting-user-name\0\5romanD\0\nwhich-jobs\0\rnot-completed\3", 349, 0, NULL, 0) = 349
recvfrom(4, "HTTP/1.1 100 Continue\r\n\r\n", 2048, 0, NULL, NULL) = 25
recvfrom(4, "HTTP/1.1 200 OK\r\nDate: Fri, 03 Aug 2012 19:52:42 GMT\r\nServer: CUPS/1.2\r\nConnection: Keep-Alive\r\nKeep-Alive: timeout=60\r\nContent-Language: en\r\nContent-Type: application/ipp\r\nContent-Length: 75\r\n\r\n\1\1\0\0\0\0\0\1\1G\0\22attributes-charset\0\5utf-8H\0\33attributes-natural-language\0\5en-us\3", 2048, 0, NULL, NULL) = 270
b)with a newer libcups:
sendto(4, "POST / HTTP/1.1\r\nContent-Length: 349\r\nContent-Type: application/ipp\r\nHost: 134.34.57.71\r\nUser-Agent: CUPS/1.6.1\r\nExpect: 100-continue\r\n\r\n", 137, 0, NULL, 0) = 137
sendto(4, "\2\0\0\n\0\0\0\1\1G\0\22attributes-charset\0\5utf-8H\0\33attributes-natural-language\0\5en-usE\0\vprinter-uri\0\20ipp://localhost/D\0\24requested-attributes\0\6job-idD\0\0\0\fjob-k-octetsD\0\0\0\10job-nameD\0\0\0\31job-originating-user-nameD\0\0\0\31job-printer-state-messageD\0\0\0\17job-printer-uriD\0\0\0\21job-state-reasonsD\0\0\0\20time-at-creationB\0\24requesting-user-name\0\5romanD\0\nwhich-jobs\0\rnot-completed\3", 349, 0, NULL, 0) = 349
recvfrom(4, "HTTP/1.1 100 Continue\r\n\r\n", 2048, 0, NULL, NULL) = 25
recvfrom(4, "HTTP/1.1 400 Bad Request\r\nDate: Fri, 03 Aug 2012 19:48:59 GMT\r\nServer: CUPS/1.2\r\nContent-Language: en\r\nUpgrade: TLS/1.0,HTTP/1.1\r\nConnection: close\r\nContent-Type: text/html; charset=utf-8\r\nContent-Length: 344\r\n\r\n<!DOCTYPE HTML PUBLIC \"-//W3C//DTD HTML 4.0 Transitional//EN\" \"http://www.w3.org/TR/REC-html40/loose.dtd\">\n<HTML>\n<HEAD>\n\t<META HTTP-EQUIV=\"Content-Type\" CONTENT=\"text/html; charset=utf-8\">\n\t<TITLE>400 Bad Request</TITLE>\n\t<LINK REL=\"STYLESHEET\" TYPE=\"text/css\" HREF=\"/cups.css\">\n</HEAD>\n<BODY>\n<H1>400 Bad Request</H1>\n<P></P>\n</BODY>\n</HTML>\n", 2048, 0, NULL, NULL) = 556
The difference is only that at the beginning of the second sendto the old one is sending "\1\1\0" as first three hex numbers(?) and the new one "\2\0\0".
What are those numbers? Version of the communication format? Maybe it indicates that the server is too old?
The default IPP version for requests is now 2.0 (STR #3929)
So the server is indeed too old. Bad for me, I do not have influence on it.