New Copiers Not Working With Papercut

[Jobos]

Now copiers are being fitted but we cannot deploy Papercut MF to the copiers. The error is 

 

Quote

Started (with errors) - cannot connect to xx.xxx.65:50003 - please check network connection, firewall and MFP settings.
Setup will be retried at 11:12:40 AM. To retry now, press "Apply" below.

Error: HTTP transport error: javax.net.ssl.SSLHandshakeException: Remote host terminated the handshake

 

We have disabled the firewall on the Papercut server but we still get the error.

 

Any ideas?

 

[DalekSec]

Are you able to ping the printer from the server?

On the printer is HTTP and HTTPS turned on?

[Jobos]

1 minute ago, DalekSec said:

Are you able to ping the printer from the server?

On the printer is HTTP and HTTPS turned on?

We can ping the printer fine. The engineers are here trying to fit the printers but keep receiving the same error. The old printers worked fine and they say they have set them to use the previous printers IP address. 

[DalekSec]

Have you tried another IP? May be something in papercut looking for a MAC address also which no longer matches up, or cache issue 

[Jobos]

12 minutes ago, DalekSec said:

Have you tried another IP? May be something in papercut looking for a MAC address also which no longer matches up, or cache issue 

 

Yes tried another IP, still the same.

 

Java was updated over Easter.

 

If we do

 

java -version 

 

we get 

 

openjdk version "17.0.15" 2025-04-15 LTS
OpenJDK Runtime Environment Corretto-17.0.15.6.1 (build 17.0.15+6-LTS)
OpenJDK 64-Bit Server VM Corretto-17.0.15.6.1 (build 17.0.15+6-LTS, mixed mode, sharing)

 

That looks fine to me.

 

[psydii]

I feel the firewall on device might be involved.  Device default configs have tended to be increasingly secure over the last five years, some installation engineers have kept up and know what needs tweaking, some haven't and punt the problem back to head office after a "day of trying" and some just turn off all the security and have done with it.

 

Making sure the device is accepting traffic from the Papercut (and print) servers on the appropriate ports would be one place to start looking.

Server side equivalent firewall rules would be another.

 

If you can get a packet capture of the traffic at the printer side (port mirror into an appropriately configured Wireshark) and at the server side (tcpdump / wireshark / netsh (at a push)  you should see some clues. (such as no traffic at all when you were expecting at least some in one direction, or connection refused messages, or cipher errors on tls connections etc etc.)

 

To be honest (and I've never deployed Papercut, only used it) I wonder if there is a service/config on the MFD that hasn't been enabled - having watched a Riso engineer (who knew what they were doing) correct a config once, the some of the device-side options did not strike me as obvious!

[Jobos]

I'm told the MFD does not have any sort of firewall and we can use powershell from the server the MFD to check the port is open using Test-NetConnection xx.x.xxx.65 -port 50003

 

ComputerName     : xx.x.xxx.65
RemoteAddress    : xx.x.xxx.65
RemotePort       : 50003
InterfaceAlias   : Ethernet
SourceAddress    : x.x.xxx.218
TcpTestSucceeded : True

[ThomL]

Can you check which version of TLS the copiers are using? From a quick google this might be the problem, they are attempting to use TLS not supported by the java version on the server

[pete]

Is the PaperCut server running the connection over HTTPS?  If so:

 

1) Does the copier trust the certificate(s) being presented by the server?

2) Is the server using TLS 1.2 or better for the connection?

 

Also worth a look here: https://www.papercut.com/kb/Main/FirewallPorts/ to double-check.

[psydii]

1 hour ago, Jobos said:

I'm told the MFD does not have any sort of firewall

I am surprised that such a device is even  available new in 2025.  Agree with the above suggesting to check TLS version support and Certificate Trust. 

[Jobos]

 

2 hours ago, ThomL said:

Can you check which version of TLS the copiers are using? From a quick google this might be the problem, they are attempting to use TLS not supported by the java version on the server

TLS 1.2 and 1.3

 

There is more to this than just the Papercut error as so far I have,

 

On my desktop, installed the printer as local IP printer and it prints fine.

 

From my desktop I can open the printer web interface fine and can open the printer interface from other machines in school but when I try from other servers, so far I've tried domain and non domain servers I just get a blank page.

 

On one server I have Wireshark so have attached the capture 

 

[psydii]

Just checking but in your earlier example you used x.x.x.65 and x.x.x.218 as the MFD and computer IPs. These are different to the IPs in the wireshark capture. ALso just checking  whether the server and the mfd are on the same or different subnets?

 

In the wireshark capture, the computer appears to have the address 10.2.104.1  While this could be perfectly valid for your server on your network, I always get a little suspicious when problems are occouring and the last octet is 0, 1, or 254.

 

Finally though, that appears to be a HTTP connection attempt and perhaps the MFD is expecting TLS?

[Jobos]

Yes we started changing IPs to see if it made any difference. I know it shouldn’t but by this time we were getting desperate!

 

The network is a /22 and the . 1 address is an old server due to be removed. There are many odd things in this network hence the problems today. 
 

Strange I can open the printer web interface using desktops but not using servers and it can’t be the way GP is setup either as using a standalone server it doesn’t open. It’s completely not logical. With the servers I tried 2019 and 2022. Both versions refused to open the printer web interface. 

[psydii]

Wild stab in the dark: https://manuals.konicaminolta.eu/bizhub-C658-C558-C458-C368-C308-C258-UD/EN/contents/opkey_925_S.html#_102157831

[Jobos]

1 hour ago, psydii said:

Wild stab in the dark: https://manuals.konicaminolta.eu/bizhub-C658-C558-C458-C368-C308-C258-UD/EN/contents/opkey_925_S.html#_102157831

This is the closest thing I’ve seen to explaining the strange behaviour and might well be this, thanks for pointing it out.

[kierans]

Are you able to ping the MFD from the server? Is the subnet correct on the MFD?

[Jobos]

1 hour ago, kierans said:

Are you able to ping the MFD from the server? Is the subnet correct on the MFD?

Yes can ping the MFD and port 50003 is open when tested with power shell

[Jobos]

15 hours ago, psydii said:

Wild stab in the dark: https://manuals.konicaminolta.eu/bizhub-C658-C558-C458-C368-C308-C258-UD/EN/contents/opkey_925_S.html#_102157831

 

Well what can I say apart from I owe you a pint and the copier guys owe you a keg!

 

You were spot on and the copier engineers said it must be in the new firmware as they have not seen that setting before.

[psydii]

For posterity (in case the link breaks in future), the Konica Minolta MFDs described in that document have a feature called "Quick IP Filtering" which on some models, by default, filters traffic to only allow from IPs matching the first 3 Octets,  this is "equivalent" to a subnet netmask of 255.255.255.0, except it ignores the actual subnet mask configured on the IP stack. It operates at the application level, so as per the packet captures - the IP stack responds as expected, but when you try to try to connect at the application level (HTTP in the above Wireshark capture) it drops the connection. This feature can be configured to better match requirements.

 

 

[Jobos]

11 minutes ago, psydii said:

For posterity (in case the link breaks in future), the Konica Minolta MFDs described in that document have a feature called "Quick IP Filtering" which on some models, by default, filters traffic to only allow from IPs matching the first 3 Octets,  this is "equivalent" to a subnet netmask of 255.255.255.0, except it ignores the actual subnet mask configured on the IP stack. It operates at the application level, so as per the packet captures - the IP stack responds as expected, but when you try to try to connect at the application level (HTTP in the above Wireshark capture) it drops the connection. This feature can be configured to better match requirements.

 

 

 

And it was enabled by default on the other two MFDs they fitted today.