CloudPRNT - Access to debug / log information on printer to find out cause of (Cloudflare) proxying problem

[holtkamp]

Since there is no repository dedicated to CloudPRNT protocol, I submit it here, feel free to move to the proper repository.

As also discussed here: https://wordpress.org/support/topic/connection-to-printer-gets-lost/, the use of an intermediate proxying server like Cloudflare might cause connection problems when using CloudPRNT.

For example: in Cloudflare I created a CNAME "printer.myProjectDomain.ext" which points to our server "myServerDomain.ext"

• when "proxying" is enabled: this does not work, the requests from the printer do not reach the server
  

• when "proxying" is disabled: this does work, the requests from the printer do reach the server
  

I am trying to figure out what part of Cloudflares proxying functionality breaks the connection. To do this, I use Cloudflare Page Rules to disable specific features and see what happens. But even when I disabled almost all features, the connection still does not work. When disabling proxying again, it works immediately.

It would be nice if there was some kind of debug / log information I can access on the printer itself to determine what it is doing and what goes wrong... currently it is a bit "trial and error"...

[Lozrus]

@holtkamp

Yes, a device side logging/debug solution would be very helpful, we are certainly aware of that. Although nothing is available currently, it is something that we will certainly keep under consideration.

In general, our devices do not care about proxy services in the middle, the issues only arise in cases where very heavy caching prevents the server side from being able to respond. This can manifest in a few ways:

1 - The proxy responds to GET requests from the printer with a previously cached response. This can cause old print jobs to be reprinted.
2 - the proxy responds to a DELETE request with a cached result, considering the resource to be already deleted. this again can cause repeated printing as the server side does not receive the request to clear the job.
3 - less common, but observes is where a service caches the POST requests. http idempotency rules do not allow this, but we have observed it in some cases. in this case, the server does not received device status updates and is entirely unable to trigger a print job.

While caching of GET/DELETE requests is entirely allowed, in some cases we have observed proxy services that seem to ignore the response headers which should prevent it. Resulting in sites that are unable to print or worse repeatedly print the same job.

In many cases, enabling specifying a unique print job id can resolve these issues, since that results in a unique query parameter for the GET and DELETE request for each print job. We will enable this in the WordPress plugin in the future, where these kinds of issue are more common, and often out of the end customers control.

[holtkamp]

@Lozrus thanks for the detailed answer.

When Cloudflare proxying is enabled for the subdomain we use for CloudPRNT, not a single request (POST, GET, DELETE) reaches our servers. Also when disabling a lot / all of the functionality that they provide. As you can see I also tried "Cache Level: Bypass" which completely disables caching. Therefore I suspect something else, like the SSL-part of the connection.

I really would like to have Cloudflare proxying enabled, since it offers protection against various kinds of threats. Eventually the subdomain we intend to use for CloudPRNT will become "public", which opens up a security threat / potential entry for a DDoS-attack

Maybe we can plan a debug session where you use one of your own development printers to send requests to our servers?

[holtkamp]

In an effort to collect additional information we used ngrok to forward incoming requests to our subdomain that we intend to use for CloudPRNT so that I can monitor "what happens" on the ngrok dashboard running on my own computer.

The tunnel can be started like this:

ngrok http --authtoken mySecretToken -host-header=rewrite https://someProjectDomain.someDomain.ext

Note that:

• to forward a request to an external URL, an authorization token is required, which can be acquired after free signup at ngrok
• we need the -host-header=rewrite option for the target server to accept the incoming request

Observations
With tunnel
When using the ngrok tunnel and restarting the printer, this same approach works and keeps working after (multiple) restarts.

- [ok] printer => ngrok tunnel => subdomain 
- [ok] printer => ngrok tunnel => subdomain, proxied by Cloudflare
- [ok] printer restart
- [ok] printer => ngrok tunnel => subdomain, proxied by Cloudflare

Without tunnel
When not using the tunnel and Cloudflare proxying is disabled: requests reach our server. When enabling proxying it keeps working, but after a single restart of the printer it stops working...

- [ok] printer => subdomain
- [ok] printer => subdomain, proxied by Cloudflare
- [ok] printer restart
- [not ok] printer => subdomain, proxied by Cloudflare

When disconnecting and reconnecting the network cable, it keeps working

- [ok] printer => subdomain
- [ok] printer => subdomain, proxied by Cloudflare
- [ok] disconnect for 10 seconds and reconnect network cable
- [ok] printer => subdomain, proxied by Cloudflare

When starting with Cloudflare proxying enabled, it does not work. After disabling Cloudflare proxying and without restarting the printer: it starts working:

- [not ok] printer => subdomain, proxied by Cloudflare
- [ok] printer => subdomain, no restart required

I remember reading something about an SSL handshake issue on older firmware versions. We use a mC-Print2 printer with latest firmware 3.3 so I don't think this is the case, but still the observations are quite "strange"...?

[holtkamp]

@Lozrus and @gare-bear is there anymore information I can provide to see why Cloudflare proxying prevents CloudPRNT requests to reach our servers?

In October 2021 we intend to start experimenting with CloudPRNT printers in a production environment and knowing that Cloudflare's proxy can be enabled to guard our API would make me sleep better at night 😉

[holtkamp]

@Lozrus and @gare-bear just wondering do you guys still have time to spend on these projects?

[zsy6504]

Hi @holtkamp , I'm facing the same issue. Did you happen to find the solution or root cause? Is it possible to resolve the issue by properly configureing cloudflare proxy?

[holtkamp]

Hi @zsy6504,

Did you happen to find the solution or root cause?

No, unfortunately not. I have the "feeling" the cause is certain behaviour of the printer firmware. Check the "weird" observations documented in #16 (comment)

Is it possible to resolve the issue by properly configureing cloudflare proxy?

I was not able to resolve it and kept the Cloudflare proxy disabled.

What firmware are you using? Can you reproduce the problem / observations that I made?

Maybe a newer firmware resolves the problem, I haven't spend time on this since september 2021. I hoped somebody from Star would step in with some pointers to the possible cause. @Lozrus shows little activity on GitHub. @gare-bear was active last week, maybe he can join this thread?

[rt-jeremy]

I'm also running into this issue and my investigation has lead me here. Any progress toward a resolution since August?

[holtkamp]

@fl-jeremy nope, unfortunately it is quite silent from the Star side of this project, which is a pity, since the functionality of CloudPRNT is quite nice.

[rt-jeremy]

@fl-jeremy nope, unfortunately it is quite silent from the Star side of this project, which is a pity, since the functionality of CloudPRNT is quite nice.

A pity, indeed. I'm gonna do some more investigating and will let y'all know if I come up with anything promising.

[mbenammar41]

I have the same problem. the requests from the printer do not reach the server when using cloudflare.
It work very well with 3 existing websites using cloudflare but when i try to add a new website, star cloud printing do not work. It seem to be a proxy problem related to cloudflare but i did not rosolve the problem yet.
So if someone can give feedback about this problem please.