On Thu, 2010-07-29 at 10:17 +0200, Florian Kulzer wrote: > On Thu, Jul 29, 2010 at 03:22:31 -0400, John A. Sullivan III wrote: > > On Thu, 2010-07-29 at 06:41 +0000, Camaleón wrote: > > > On Thu, 29 Jul 2010 01:46:40 -0400, John A. Sullivan III wrote: > > > > > > > Hello, all. We are in quite a pickle tonight - our CUPS printing is > > > > complete broken after an upgrade. The cups error_log is filled with > > > > "Bad request line "VCB" from 172.x.x.1!' Printers do not appear in > > > > Gnome or OpenOffice and, even though they appear in KDE, they are > > > > unavailable. > > > > > > (...) > > > > > > I remember a similar thread: > > > > > > *** > > > Help - CUPS printing stopped working > > > http://lists.debian.org/debian-user/2010/07/msg00844.html > > > *** > > > > > > So maybe you are hitting this bug? > > > > > > *** > > > cups: https interface has SSL error ("SSL received a record that exceeded > > > the maximum permissible length") > > > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=590610 > > > > > Yes, that looks like it and there does not appear to be a patch or > > workaround yet :( > > Both the older thread and the bug report show that an SSL error is > encountered when an SSL connection to the CUPS web interface is > attempted on the standard, unencrypted CUPS port (631). As far as I > know, that is the normal behavior with 1.4.4. #590610 looks like > misunderstanding or a user configuration error to me. Your problem might > very well be a different issue. > > In your case, I would: > > - Use netstat on the cups server to check on which port it listens for > the SSL connections. > > - Verify that the CUPS web interface works for an https connection to > that port (not necessarily 631), first from the server itself and then > from the client. > > - Try to specify the SSL port explicitly in all server URLs configured > on the client. > > - If that does not help, use tcpdump or strace -enetwork to see exactly > which connections on which ports the client is attempting when it > tries to print a document. > > Note: I do not use encrypted CUPS connections myself, so the above > advice involves some guesswork. I don't know on which port(s) CUPS > printing (as opposed to the CUPS web interface) negotiates encrypted > connections. Maybe some changes of the procedure were introduced in the > newer CUPS version, so I would also have a look at the changelog with > that in mind.
Thanks very much. I thought the idea of user error very possible as I am by no means a CUPS expert. In the past, we have used the same port for encrypted and unencrypted traffic. So I tried to specify a different port for SSL with SSLListen only to have CUPS not accept it and issue an "unknown directive" error. After a bit of searching, I see in the cups 1.2b1 release notes: "The scheduler now automatically detects SSL/TLS clients without using the SSLPort/SSLListen directives." That was our previous experience anyway. So I am assuming this is a new bug. Any other ideas? Thanks again - John -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1280591253.3342.3.ca...@localhost