Description of problem: Adding a printer in CUPS admin fails when trying to select Make of printer. Version-Release number of selected component (if applicable): RHEL 5.2 firefox-3.0-0.beta5.6.el5 cups-1.2.4-11.14.el5 How reproducible: Always Steps to Reproduce: 1. Go to host:631/admin 2. Click Add Printer 3. Fill out name, description, etc 4. Choose printer type 5. Chose Make (for example HP) 6. Hit Continue Actual results: Page loads and loads, eventually drops to a blank screen. Expected results: Proceed to the Model selection page. Additional info: Not an issue in Firefox 1.5 or 2. Reproduceable across all Firefox 3 beta 5 versions in RHEL 5.1, 5.2, Fedora 9, and on a Mac. No issues reported in Error Console.
Apparently this is part of a known CGI issue in CUPS 1.2.4: http://cups.org/newsgroups.php?gcups.general+v:32688 From the link, the latest 1.2 stable release (1.2.12) has this fixed.
Moving to cups.
I can't reproduce this here. If this is reproducible on Fedora 9, the problem is probably not related to the issue you cite in comment #1, as Fedora 9 ships with CUPS 1.3.7. See the thread "webinterface with firefox 3", which starts here: http://cups.org/newsgroups.php?s15516+gcups.general+v16496+T1 The most recent message in the thread, from Michael Sweet: ==> John Holmstadt wrote: > ... > I am using Firefox 3.0 on Windows XP, attempting to add a printer > to Cups 1.3.7 on Fedora 8 and I am seeing the same problem. I hit > continue after specifying the Make/Manufacturer and Firefox hangs > saying "Waiting for <mydomain.com>". I confirmed that trying the > same operations on IE 7 from the same machine worked fine. Hmm, that sounds like a FF3 bug then. Can you download Wireshark (if you don't already have it) and run it to record the session between FF3 and your FC8 system? <== Perhaps you could try that?
Changing component to Firefox, since it seems to be a problem with its handling of encrypted connections (according to upstream discussion referenced above). The correct URL for the cups.general thread is this: http://cups.org/newsgroups.php?gcups.general+v:33070 and the specific message that causes me to think it is a Firefox bug is this: http://cups.org/newsgroups.php?gcups.general+v:33140
After reading this bug and the quoted links on cups.org, I suspect/hope there is some confusion going on. A server that expects https can not be accessed using plain http. A server that expects plain http can not be accessed using https. Attempts to access a server using the wrong protocol will either result in an error message or the stalling you're experiencing. It appears to me that cups can be configured to expect either https or http, but always uses the same port number 631? I think that's confusing and unfortunate. Any other protocols I'm aware of are using different port numbers for always-plain and always-encrypted. (With the exception of protocols that use the start-tls variant, which always start with a plaintext phase and switch to ssl/tls as part of the application protocol). Having said that, I would like to ask for more tests. - disable encryption in cups (port 631 expects http) - use firefox 2 and http (should work) - use firefox 3 and http (should work) - use firefox 2 and https (should stall or fail) - use firefox 3 and https (should stall or fail) - enable encryption in cups (port 631 expects https) - use firefox 2 and http (should stall or fail) - use firefox 3 and http (should stall or fail) - use firefox 2 and https (should work) - use firefox 3 and https (should work)
(In reply to comment #5) > A server that expects https can not be accessed using plain http. > A server that expects plain http can not be accessed using https. This is not how it works at all. For example, take a look at how 'lpstat -h localhost -E -s' works. The initial connection is made using plain HTTP. The client then requests a secure connection with: Connection: Upgrade Upgrade: TLS/1.0,SSL/2.0/SSL/3.0 Then the server responds with: Connection: Upgrade Upgrade: TLS/1.0,HTTP/1.1 (or whatever) and further communications are encrypted. Additionally, CUPS can automatically check new connections for an SSL/TLS handshake, and encrypt the connection from the start. This is how Firefox, links etc should be treated when they use 'https://localhost:631'. > It appears to me that cups can be configured to expect either https or http, but > always uses the same port number 631? CUPS can accept both HTTPS and HTTP at the same time from different clients, depending on the 'Encryption' keyword in /etc/cups/cupsd.conf.
Thanks for the explanation, but I think I still need more info. You're saying that the CUPS server tries to be smart in multiple ways. You say, if the conversation on the CUPS protocol port starts in plaintext, it can switch to encrypted, which sounds similar to the STARTTLS mechanism used in email protocols. That's smart. But you also say, the single CUPS server port tries to detect whether the client is sending encrypted or not. This is a smart idea, but I think it's tricky to implement and might be where some software is getting confused and end up stalling. I don't know. I would like to understand the exact configuration that is failing. Are you saying the failing scenario is: - server with encryption enabled - firefox 3 connecting with https And are you saying that with the same server configuration: - firefox 2 connecting with https works ? I would like to reproduce your setup locally.
from cupsd.conf manpage: Encryption IfRequested Encryption Never Encryption Required Specifies the level of encryption that is required for a particular location. Which setting did you use?
I am able to reproduce on both RHEL 5.2 and Fedora 9. I use the default cupsd.conf, and it's necessary to use https. https://localhost.localdomain:631/admin I added an exception for the self-signed certificate, and while the first few pages of the process work just fine, it stalls when I press "continue" on the page with the heading "Make/Manufacturer". All pages use https, but only one page stalls.
On RHEL I see some messages in the logfiles: I [18/Jul/2008:20:54:41 +0200] cupsdCloseClient: SSL shutdown successful! ==> access_log <== localhost - - [18/Jul/2008:20:58:15 +0200] "POST /admin HTTP/1.1" 200 1742 - - ==> error_log <== I [18/Jul/2008:20:58:20 +0200] Started "/usr/lib/cups/cgi-bin/admin.cgi" (pid=7753) I [18/Jul/2008:20:58:20 +0200] Started "/usr/lib/cups/daemon/cups-driverd" (pid=7754) ==> access_log <== localhost - - [18/Jul/2008:20:58:20 +0200] "POST / HTTP/1.1" 200 30002 CUPS-Get-PPDs - ==> error_log <== E [18/Jul/2008:20:58:27 +0200] cupsdCloseClient: Error in the push function. E [18/Jul/2008:20:58:27 +0200] PID 7753 (/usr/lib/cups/cgi-bin/admin.cgi) crashed on signal 9! I [18/Jul/2008:20:58:27 +0200] Hint: Try setting the LogLevel to "debug" to find out more.
I'm going to move this over to the cups component, which seems the most likely component having a problem, but I'll try to trace the SSL connection.
After lots of output from ssl tracing tool "ssltap" and a long delay (5 minutes), when Firefox switches to the blank page, the ssltap output concludes with the following piece: <-- [ (37 bytes of 32) SSLRecord { [Fri Jul 18 23:41:14 2008] type = 21 (alert) version = { 3,0 } length = 32 (0x20) < encrypted > } ] Read EOF on Server socket. [Fri Jul 18 23:41:14 2008] Read EOF on Client socket. [Fri Jul 18 23:41:14 2008] Connection 11 Complete [Fri Jul 18 23:41:14 2008] The cups server sends an alert record and closes the socket. We don't know yet whether the server is incorrectly waiting for more data to arrive, or whether Firefox fails to send required data.
Created attachment 312181 [details] cups debug output I changed cupsd.conf to contain: LogLevel debug I'm attaching the output that was produced when I clicked "continue" which results in "nothing but stalls".
Comparing what Firefox sends over the 'http://localhost:631' connection when submitting that form with what cupsd receives over the equivalent 'https://localhost:631' form submission from Firefox, there is definitely data missing from the SSL connection. However, when I click 'Stop' in Firefox, the remaining data does appear at the cupsd end. Further investigation required. (I'm away the rest of this week.. anyone else able to look at this?) Attached: 1. firefox-http-request.txt, obtained from wireshark, showing the form submission from Firefox when using the 'http://localhost:631' (non-SSL) URL 2. firefox-http.log, obtained from 'cupsd -f', showing the form submission from Firefox when using the 'https://localhost:631' (SSL) URL. This shows the incomplete request, and the remaining data when the 'stop' button is clicked. 3. cups-debug.patch, used to obtain firefox-http.log
Created attachment 312288 [details] firefox-http-request.txt
Created attachment 312289 [details] firefox-https.log
Created attachment 312290 [details] cups-debug.patch
I suspect the CUPS/SSL server might be unable to correctly handle certain data packets. I compared the data sent by FF2 vs. FF3. The data wrapped inside SSL is identical, if we ignore the "Accept:" and "User-Agent:" HTML headers. The data I see is equivalent to Tim's attachment 312288 [details]. I noticed that Firefox 2 sends the request using 4 separate write calls to the operating system: -1244062832[8a677a8]: [87cb5b8] wrote 449 bytes (out of 449) -1244062832[8a677a8]: [87cb5b8] wrote 102 bytes (out of 102) -1244062832[8a677a8]: [87cb5b8] wrote 24 bytes (out of 24) -1244062832[8a677a8]: [87cb5b8] wrote 1736 bytes (out of 1736) But Firefox 3 is smarter, it queues the bytes for the request and I see only a single request being sent out: -1240466544[b4a0e8a0]: [b14cd120] wrote 2275 bytes (out of 2275) (Although those numbers don't sum up to the same total number, I verified the contents are equivalent. The differences are caused by different user-agent and accept headers.) I was able to reproduce the hang with a local debug build of Firefox 3. Then I changed FF 3 to use a maximum of 1000 bytes for write calls on SSL connections, and I got: -1240466544[b4a118a0]: [b14c5680] wrote 1000 bytes (out of 2296) -1240466544[b4a118a0]: [b14c5680] wrote 1000 bytes (out of 1296) -1240466544[b4a118a0]: [b14c5680] wrote 296 bytes (out of 296) This made it work for me. I seem to remember a similar bug in an SSL library, that has been fixed in newer versions. I'm not sure if it's related and I should try to look up the details. However, I'd like to invite the CUPS developers to look into this issue now. Is it possible that there is a bug in the CUPS receiving side? In comment 14 Tim said he receives the remaining data in the debug log after he presses the stop button in Firefox. According to my tracing, the data has already been sent by Firefox. I suspect that pressing the stop button causes another tcp/ip event to go out that causes a wakeup on the CUPS/SSL server side and causes it to process the remaining data.
(In reply to comment #18) > I seem to remember a similar bug in an SSL library, that has been fixed in newer > versions. I'm not sure if it's related and I should try to look up the details. That would be extremely useful.
I've filed this upstream with a work-around patch that seems to show it really is a CUPS problem: http://cups.org/str.php?L2892 In this case, gnutls has read the data and holds it in a buffer, but cupsd is using poll() to await more data instead of trying gnutls_record_check_pending().
This request was evaluated by Red Hat Product Management for inclusion in a Red Hat Enterprise Linux maintenance release. Product Management has requested further review of this request by Red Hat Engineering, for potential inclusion in a Red Hat Enterprise Linux Update release for currently deployed products. This request is not yet committed for inclusion in an Update release.
cups-1.3.8-1.fc9 has been submitted as an update for Fedora 9
cups-1.3.8-2.fc9 has been pushed to the Fedora 9 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update cups'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F9/FEDORA-2008-7093
F-9 update works for me.
cups-1.3.8-2.fc9 has been pushed to the Fedora 9 stable repository. If problems still persist, please make note of it in this bug report.
We just reproduced with FF3.0.2. However, if you are hitting this on customer sites, IE7 works just fine. Nick
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on therefore solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHEA-2009-0201.html