Re: CUPS upgrade from Lenny to Squeeze breaks encryption - HELP
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
Reply to: