ipp server: It can't receive user authentication print from Android client

[zhulisong]

When I used the ippserver compiled by the code of ippsample, I found that Android cannot print with ipp authentication. Can anyone help to confirm? Thanks in advance.

Phenomenon

We use the code of ippsample to compile and run ippserver on windows. After enabling ipp authentication, when printing with mopria print installed on the Android phone, after entering the user name and password for authentication in the pop-up dialog box, an error will show and file can't be printed normally.

Steps to reproduce the problem

1. Download ippsample source code.
2. Add "Authentication yes" in the configuration file system.conf to enable ipp authentication.
3. Use Visual Studio 2017 to compile it on windows.
4. Run the compiled ippserver.
5. Install the Mopria Print app(*) on an Android phone.
6. Open one file (eg. photo) and print it with the Mopria Print app.
7. A dialog box for entering the user name and password will be displayed on the mobile phone.
8. Enter the user name and password, and click the OK button. 7.“Cannot send credentials over unencrypted connection” will display and file can't be printed normally.

(*) If Mopria Print app is not installed, the ipp authentication function cannot be used.

Supplementary

1.Under the same conditions, the iOS client can print normally. 2.If you do not enable ipp authentication printing, the Android client can also print normally. 3.It seems to be an error in the "Starting HTTPS session." of the encrypted connection, but I am not sure whether it was the creation of the encryption certificate or what went wrong.

[michaelrsweet]

@zhulisong Right now I know the ippserver doesn't actually support Mopria at all, and as long as it remains a proprietary specification that will likely remain the case since ippserver is intended as a development tool for public IPP standards.

If you can supply a log snippet showing the Android client connecting to the server and sending requests, I might be able to help you figure out the problem.

[wifiprintguy]

A network packet capture (using Wireshark etc.) would be useful. Alternately, if you could run your tests again with "LogLevel Debug" and attach a file containing the log trace written by ippserver, that might also reveal the source of the problem.

[HPRoss]

@zhulisong if you can provide me with an adb log I will have the MPS dev team review it and determine if there is an issue on the Mopria Print Service side.

[zhulisong]

Console_CUPS_LOG.zip @michaelrsweet @wifiprintguy Thank you very much for your quick reply. I have modified "LogLevel Debug" and got the console log and cups log sent from Android to ippserver. Please refer to the attached file.

By the way, when I click [PRINT TEST PAGE] on the Mopria Print app, I can authenticate successfully and print normally, but when I select any file (such as a photo) and then print it, it will fail. For the convenience of comparison, I took the log in both cases.

Please help me confirm whether the current log can find out where the problem is. If necessary, I will use Wireshark to capture network packet.

@HPRoss Thank you for your hint. I have not obtained adb log. I may study the method of obtaining it later and try to obtain adb log.

[michaelrsweet]

@zhulisong From the log file it looks like you have made modifications to ippserver and are running it on Windows?

From the logs it looks like the Mopria client doesn't like something about the printer when printing an ordinary file. Beyond that I'm afraid I can't help...

[HPRoss]

@zhulisong here is a link to a good set of directions for adb logging: https://support.citrix.com/article/CTX232375

I am logging an issue within our Mopria Print Service and we will investigate if this is a Mopria issue. We use ippserver for testing in many instances, so perhaps you have found something we aren't aware of.

[zhulisong]

@michaelrsweet Thank you for your quick confirmation, yes we made a little modification and run it on windows. I am sorry, would you please tell me, have you run and tested the ippserver of ippsample on windows? Because I also found some other small problems when running on windows.

@HPRoss Thank you very much for the method of get log, we will try to get it. By the way, you said that you have used ippserver to test Mopria, do you use ippserver running on windows or running on a Mac/Linux OS other than Windows? The results of running ippserver on Windows and other OSs may be different.

[michaelrsweet]

@zhulisong I personally have not done so, and I know certain features just don't work on Windows due to differences in that OS (particularly the pipe support for print commands).

[HPRoss]

@zhulisong most of our team runs ipp server on Windows.
We have done some investigation and would like you to try one item with your setup. Can you go into the Mopria Settings and turn on "SSL Always". Then try the Authenticated print job.

[zhulisong]

@HPRoss Thank you for your hint, I tried the setting you mentioned, but it didn't work. The authenticated print job still fails to print, and the phenomenon is the same as before.

I'm glad to hear that you can use Android phones to send encrypted data to the ippserver running on windows, but we still have some doubts about this.

Did you also modify the ippsample code to ensure the normal use of ippserver on windows? Because the original ippsample code I downloaded from github cannot run normally on windows.

Today I re-downloaded the latest code on "https://github.com/istopwg/ippsample", and this problem still exists. I need to modify many places in the files in the cups directory and the server directory to ensure a successful startup.

I found that the problem of Android printing problem may be in the "http_sspi_server" function in the "cups\tls-sspi.c" file. May I ask if the code of the ippserver that works normally on windows is the same as the release version.

If they are not the same, can you share with me all the ippsample code that successfully run normally on windows?

Of course, it is also possible that my compiling and running environment is different from yours. The following is our compilation and runtime environment: Version: Windows10 Professional Edition Version: 2004 In order to run the environment package installed by ippserver: BonjourPSSetup.exe Microsoft Visual Studio Professional 2017 Version 15.9.31

[wifiprintguy]

If you build ippsample on Linux and run ippserver, do you observe any difference?

[sicklittlemonkey]

@zhulisong @HPRoss It's a shame the modifications needed to get ippserver working properly on Windows haven't been donated back to this project,

[zhulisong]

@sicklittlemonkey I just started investigating the running of ippserver on windows and are not yet familiar with how to donated our changes.

I will then contribute to this project the modifications to ensure that it runs on windows firstly. Hope that more people can contribute to make this project more perfect.

@HPRoss Sorry to remind you again. Did your team also modify the ippsample code to ensure the normal use of ippserver on windows? In order to ensure authentication printing on Android, have you modified the "cups\tls-sspi.c" file?

[zhulisong]

@wifiprintguy Sorry for the late reply, I haven't run it on linux yet, I will try it.

[sicklittlemonkey]

@zhulisong Great to hear. I've started with a small improvement: #229

Basically you need to fork this repo, create a branch, commit your changes, push to your branch, then create a pull request. I recommend getting GitHub Desktop and having a read of the GitHub Flow docs.

[wangzhili-China]

If you build ippsample on Linux and run ippserver, do you observe any difference?

I tested the function of ippsamle under linux system and found the same problem! The code used is the latest version of ippsample, the compiling and running environment is Ubuntu20.04, and uses the parameter ippserver -C test -d /home/username/Desktop/file -r _universal to run. Authentication yes and AuthType Basic are enabled in system.conf. Clients such as Ubuntu, MAC, iphone, etc. can use encrypted authentication to complete printing. However, the problem of "Cannot send credentials over unencrypted connection" occurs when using Mopria Print to print files on Android phones. But if I just click to print the test page in Mopria Print, it can be successful. This is the debug level log I got when the problem occurred: ippsample.log This is the MoPria Print Versin

@zhulisong After I ran the ippsample with basic authentication enabled in the Linux environment, I used an Android phone to send a print job and finally had the same problem as you described.

This is the version of Mopria Print I am using:

This is the reminder when there is a problem with the Android phone:

[zhulisong]

@wangzhili-China Thank you very much for the information. You helped me a lot

@wifiprintguy It seems that the problem of Android authentication printing is not only on Windows, but also on Linux systems. Maybe the ippsample has not been verified with Android authentication?

@michaelrsweet The problem of Android authentication printing failure has the same problem on Linux system, can you help confirm the log?

@sicklittlemonkey Thank you very much for your contribution and tips on how to submit code, I want to learn from you. I understand how to submit changes. By the way, do you have an ippserver that can run successfully, and if so, can Android authentication printing be successful for you?

[michaelrsweet]

@zhulisong ippserver is sample code and comes with absolutely no support, warranty, etc. Furthermore, the whole ippsample project is absolutely not intended for production use - it is prototyping code.

I have not personally done any testing with Android (Mopria), just with iOS, macOS, and Linux, plus the IPP Everywhere self-certification tools. It is certainly possible something is not working, and it is equally possible that the Mopria print client is broken. I will attempt to reproduce with an Android phone I got for testing PAPPL, but since I don't get paid to work on ippserver I can't say when that will be.

[zhulisong]

@michaelrsweet Thank you very much for your detailed comment. I understand that ippsample is just a prototyping code. I will also continue to investigate the possible cause of the problem.

[wifiprintguy]

Capturing traffic via Wireshark and attaching that PCAP file would help too.

[zhulisong]

@wifiprintguy thank you for your advise. I captured network packets when the problem occurred via Wireshark and attaching that PCAP file. AndroidEncryptError_NetworkPackets.zip

The IP address of the ippserver is 172.25.79.52, and the Android phone is 172.25.79.206

[wifiprintguy]

@zhulisong, I looked at your .pcap file but it looks like most of the traffic to / from port 631 is encrypted, so it is difficult to use that to diagnose the authentication issue.

[wangzhili-China]

@michaelrsweet @wifiprintguy Hello, I have a guess about the phenomenon of this problem, and I don't know if it is correct. From the log and PCAP point of view, no problem occurred during the process of "the client found ippserver->the client sent a print request to the ippserver->ipppserver asked the client for authentication". After "ipppserver asked the client for authentication", it will be the same as in other stages. The connection will be closed first, and the connection will be re-established until the client sends the authentication information verification request next time, and then the subsequent actions will be performed. However, since the client (Android phone) is directly intercepted locally when the authentication information is entered and sent to the ippserver (Cannot send credentials over unencrypted connection), the ippserver will not receive any information from the client, so naturally It is also impossible to see where the problem occurred from the log or PCAP. Another point is that every time the client establishes a connection with the ippserver, it is first non-encrypted, and then upgraded to an encrypted connection. So I guess the reason for this problem is that the design of the connection between the ippserver itself and the client is not applicable to Android phones.

1. It may be because the connection is closed, and the Android phone directly refuses to send the credentials after discovering that the connection with ippserver is not maintained?
2. It may be because each time the connection is established in a non-encrypted way, and then upgraded to an encrypted connection, but Android does not accept this way of upgrading encryption when sending credentials?

The above are my guesses based on analyzing the problem phenomenon, code, log, etc. I don't know whether it is correct or not. I hope to get some answers to continue the investigation.

[zhulisong]

@HPRoss Is it necessary to pass Mopria certification on ippserver for authentication printing on Android?

Because we found that there is no problem with the encrypted connection, the request sent by Android has content about mopria-certified, but ippserver does not support it now, so there is no response.

Therefore, we guess whether it is because the ippserver has not passed the Mopria certification , so the authentication printing is not successful. Because there is no problem using Mopria to print a test page, only printing other files will cause problems.

[michaelrsweet]

No updates in almost 2 years. We can't reproduce, but it might be related to old SSL/TLS code that has since been replaced.

[abljalil]

with attached config file i am not able to print the pdf getting following response from ippserver

"Sending IppPacket(v=0x200, c=Get-Printer-Attributes(11), r=0x1) { operation-attributes { attributes-charset = utf-8, attributes-natural-language = en-us, printer-uri = ipp://172.23.3.74:8000/ipp/print, requesting-user-name = "jprint" (name), requested-attributes = document-format-supported } }

Received: IppPacket(v=0x200, c=client-error-not-found(1030), r=0x1) { operation-attributes { application/pdf format not supported by printer in [] attributes-charset = "utf-8" (charset), attributes-natural-language = "en-us" (naturalLanguage), status-message = ""printer-uri" 'ipp://172.23.3.74:8000/ipp/print' not found." (text) } }"

Console log of ippserver is

$ sudo ippserver  -C ~/ipp
Unable to open log file "~/ipp/stderr": No such file or directory
<67>1 2023-09-12T10:42:32.841Z ubuntu ippserver 1847 -  Using default data directory "/tmp/ippserver.1847".
<67>1 2023-09-12T10:42:32.841Z ubuntu ippserver 1847 -  Using default spool directory "/tmp/ippserver.1847".
<67>1 2023-09-12T10:42:32.846Z ubuntu ippserver 1847 -  Using default listenersfor ubuntu:8000.
<67>1 2023-09-12T10:42:32.848Z ubuntu ippserver 1847 -  Loading printers from '/home/elixir/ipp/print'.
<67>1 2023-09-12T10:42:32.848Z ubuntu ippserver 1847 -  Skipping "testprt.config".
(null)1 2023-09-12T10:42:32.848Z ubuntu ippserver 1847 -  serverRun: 0 printersconfigured.
(null)1 2023-09-12T10:42:32.848Z ubuntu ippserver 1847 -  serverRun: 2 listenersconfigured.
(null)1 2023-09-12T10:42:42.858Z ubuntu ippserver 1847 -  Cleaning old jobs.
(null)1 2023-09-12T10:42:50.614Z ubuntu ippserver 1847 -  serverRun: Incoming connection on listener ubuntu:8000.
<67>1 2023-09-12T10:42:50.614Z ubuntu ippserver 1847 -  [Client 1] Accepted connection from "172.23.6.171".
<67>1 2023-09-12T10:42:50.617Z ubuntu ippserver 1847 -  [Client 1] POST /ipp/print
(null)1 2023-09-12T10:42:50.622Z ubuntu ippserver 1847 -  [Client 1] Request: version=2.0
(null)1 2023-09-12T10:42:50.622Z ubuntu ippserver 1847 -  [Client 1] Request: operation-id=Get-Printer-Attributes(000b)
(null)1 2023-09-12T10:42:50.622Z ubuntu ippserver 1847 -  [Client 1] Request: request-id=1
(null)1 2023-09-12T10:42:50.622Z ubuntu ippserver 1847 -  [Client 1] Request: operation-attributes-tag
(null)1 2023-09-12T10:42:50.622Z ubuntu ippserver 1847 -  [Client 1] Request: attributes-charset (charset) utf-8
(null)1 2023-09-12T10:42:50.622Z ubuntu ippserver 1847 -  [Client 1] Request: attributes-natural-language (naturalLanguage) en-us
(null)1 2023-09-12T10:42:50.622Z ubuntu ippserver 1847 -  [Client 1] Request: printer-uri (uri) ipp://172.23.3.74:8000/ipp/print
(null)1 2023-09-12T10:42:50.622Z ubuntu ippserver 1847 -  [Client 1] Request: requesting-user-name (nameWithoutLanguage) jprint
(null)1 2023-09-12T10:42:50.622Z ubuntu ippserver 1847 -  [Client 1] Request: requested-attributes (keyword) document-format-supported
<67>1 2023-09-12T10:42:50.622Z ubuntu ippserver 1847 -  [Client 1] Get-Printer-Attributes client-error-not-found (\"printer-uri\" \'ipp://172.23.3.74:8000/ipp/p                                                                                                             rint\' not found.)
(null)1 2023-09-12T10:42:50.625Z ubuntu ippserver 1847 -  [Client 1] Response: version=2.0
(null)1 2023-09-12T10:42:50.625Z ubuntu ippserver 1847 -  [Client 1] Response: status-code=client-error-not-found(0406)
(null)1 2023-09-12T10:42:50.625Z ubuntu ippserver 1847 -  [Client 1] Response: request-id=1
(null)1 2023-09-12T10:42:50.625Z ubuntu ippserver 1847 -  [Client 1] Response: operation-attributes-tag
(null)1 2023-09-12T10:42:50.625Z ubuntu ippserver 1847 -  [Client 1] Response: attributes-charset (charset) utf-8
(null)1 2023-09-12T10:42:50.625Z ubuntu ippserver 1847 -  [Client 1] Response: attributes-natural-language (naturalLanguage) en-us
(null)1 2023-09-12T10:42:50.625Z ubuntu ippserver 1847 -  [Client 1] Response: status-message (textWithoutLanguage) \\\"printer-uri\\\" \'ipp://172.23.3.74:8000                                                                                                             /ipp/print\' not found.
<67>1 2023-09-12T10:42:50.633Z ubuntu ippserver 1847 -  [Client 1] OK
(null)1 2023-09-12T10:42:50.633Z ubuntu ippserver 1847 -  [Client 1] serverRespondHTTP: Sending 153 bytes of IPP response (Content-Length=153)
(null)1 2023-09-12T10:42:50.633Z ubuntu ippserver 1847 -  [Client 1] serverRespondHTTP: Sent IPP response.
(null)1 2023-09-12T10:42:50.633Z ubuntu ippserver 1847 -  [Client 1] serverRespondHTTP: Flushing write buffer.
<67>1 2023-09-12T10:43:20.644Z ubuntu ippserver 1847 -  [Client 1] Closing connection from "172.23.6.171".
(null)1 2023-09-12T10:43:20.644Z ubuntu ippserver 1847 -  Cleaning old jobs.
(null)1 2023-09-12T10:43:50.675Z ubuntu ippserver 1847 -  Cleaning old jobs.
(null)1 2023-09-12T10:43:56.180Z ubuntu ippserver 1847 -  serverRun: Incoming connection on listener ubuntu:8000.
<67>1 2023-09-12T10:43:56.181Z ubuntu ippserver 1847 -  [Client 2] Accepted connection from "172.23.6.171".
<67>1 2023-09-12T10:43:56.187Z ubuntu ippserver 1847 -  [Client 2] GET /
<67>1 2023-09-12T10:43:56.187Z ubuntu ippserver 1847 -  [Client 2] OK
(null)1 2023-09-12T10:43:56.188Z ubuntu ippserver 1847 -  [Client 2] serverRespondHTTP: Flushing write buffer.
(null)1 2023-09-12T10:43:56.191Z ubuntu ippserver 1847 -  serverRun: Incoming connection on listener ubuntu:8000.
<67>1 2023-09-12T10:43:56.191Z ubuntu ippserver 1847 -  [Client 3] Accepted connection from "172.23.6.171".
(null)1 2023-09-12T10:44:26.216Z ubuntu ippserver 1847 -  Cleaning old jobs.
<67>1 2023-09-12T10:44:26.217Z ubuntu ippserver 1847 -  [Client 2] Closing connection from "172.23.6.171".
<67>1 2023-09-12T10:44:26.220Z ubuntu ippserver 1847 -  [Client 3] Closing connection from "172.23.6.171"."

config.zip