Optimization Request for Pappl-1.3.2 Ported to Embedded System with AirPrint Support

[sahayap]

Hello Michael,

I hope this message finds you well. I wanted to inform you that I have successfully ported pappl-1.3.2 to our embedded system in order to enable AirPrint functionality. The porting process went smoothly, and everything is functioning as expected. However, I have noticed that when using encryption, the initial handshaking process takes approximately 8 seconds to complete. I was wondering if there are any optimization techniques that can be implemented to reduce this time.

Supported Packages: CUPS 2.3.1, libcupsfilters-2.0b2, Avahi-0.8, Gnutls-3.6.16, Pappl-1.3.2, Pappl-retrofit-1.0b2

Thank you for your assistance.

Best regards,
Sahaya P

[michaelrsweet]

@sahayap TLS negotiation times are a function of several factors: connection speed/latency, processor speed, and implementation. Without knowing the details of your embedded system, I would guess all of these things are playing a part.

Using OpenSSL might help - it has more optimizations available for embedded platforms than GNU TLS.

You can also customize the set of supported cipher suites to those that are efficient on your platform - AES and ECDSA typically are hardware accelerated plus they have lower overhead.

[michaelrsweet]

The delay could be a variety of things, from an Avahi issue to a Wi-Fi firmware issue/bug. But that's below PAPPL or LPrint.

WRT the invalid form submission, I'd need to see logs but that normally indicates missing form data. Also, what browser are you using?

[sahayap]

Dear Michael,

Thank you for your prompt response.

I wanted to address the printer discovery delay issue. Currently, our printer is connected via Ethernet rather than WiFi. Our printer supports both WiFi and Ethernet interfaces, and we have observed the same delay in both connection types. However, when we conducted tests using Windows 10 and Ubuntu-22.04, we found that the printer discovery is significantly faster on those platforms (approximately 1 to 2 seconds for Windows 10 and less than 1 second for Ubuntu-22.04). Only Mac OS it took 5 seconds

Regarding the issues with the Web UI interface, previously, when we were using GnuTLS, all the functions worked perfectly fine. However, after switching to OpenSSL, we encountered an "Invalid Form Submission" error. (Chrome, Firefox,safari)

I have attached the Wireshark log and our application log for the Printer Test Page event from the Web Interface. When reviewing the Wireshark log, please apply the filter condition (ip.addr == 192.168.0.100).

bixolon-printer-app.log
Print_Test_Page.zip

Thank you
Best regards,
Sahaya P

[sahayap]

Dear Michael,

I have an update regarding the MacOS delays issue. we have successfully resolved the delay problem. It appears that the delay was related to printer discovery when using Avahi. However, after switching to mDNSResponder, we no longer experience any delays. Our printer is now functioning as expected, which is great news.

The Remaining issue is the Web Interface UI Setting is not functioning properly in all browsers, including Chrome, Firefox, Safari, and Edge, after switching to OpenSSL. We are currently unable to make any changes through the interface.

I kindly request your guidance and support in resolving this issue.
Thank you .

Best regards,
Sahaya P

[sahayap]

Dear Michael,

I hope you are doing well. I wanted to provide you with an update regarding the issue we were facing with the Web UI interface in OpenSSL.

Upon conducting a thorough analysis, I discovered that the problem lies in the function call "cupsHashData" within the "papplClientGetCSRFToken" function in the "client-accessors.c" file. It appears that this function returns incorrect Hash binary data.

Further investigation revealed that the "cupsHashData" function in the "cups/hash.c" file does not support OpenSSL but only GnuTLS. This explains why the Web UI works flawlessly when we use GnuTLS, but encounters issues when OpenSSL is used. Additionally, I noticed a discrepancy in the algorithm values passed from the "papplClientGetCSRFToken" function. It uses "sha2-256," whereas OpenSSL expects "sha256."

In light of these findings, we decided to implement our own hash data function for sha256 using OpenSSL. This solution has proven to be successful, and the Web UI is now functioning properly.

Thank you so much.

Best regards
Sahaya P

[michaelrsweet]

Please file a bug against CUPS - this is fixed in the libcups project but not yet in the CUPS 2.x branches.