Jump to content

Recommended Posts

Posted

Hi,

 

Sorry if this has been asked previously.

 

We have Papercut MF (v. 19) and our teachers have the Papercut client startup on logon. It all works perfect until the Papercut client disconnects as the teacher moves around the school and between the wireless access points. The client disconnects and sometimes never reconnects (and icon turns grey instead of green).

 

This is becoming a major problem for staff. Our solution has been to get them to log off while moving around the school but a lot of staff don't listen and I can understand they don't want to because this can take some time to log back in.

 

Is there a way to configure the client to not care if it's disconnected and simply upload the printing data once reconnection occurs?

 

Thank you,

Posted
We've found that papercut client seems to cache the unavailability of the server forever *if* it is configured to use the DNS name. Setting the client to connect by IP address only, and everything works flawlessly.
  • Thanks 1
Posted

We drop a custom c:\program files (x86)\PaperCut MF Client\config.properties onto the computers. It's been so long since I set this I really can't remember whether there is a server-side setting to build this correctly in the first place.

 

The relevant lines are:

server-ip=

server-port=

server-name=

 

Use the IP address for both the server-ip and the server-name entries.

 

That we needed to do this made me weep.

  • 2 weeks later...
Posted
Hey Andmcq!

 

How did you go? Do you still have this issue? Let us know and we'll jump in to help.

 

- Mikaela

 

Hi,

 

I'm still testing it. We've just started holidays here so it will be weeks before I know now. If this is the solution it really needs to be added to Papercut's KBA as the only solution I've ever been provided by PaperCut has been the logon/logoff workaround or to edit hidden client timeout settings.

Posted (edited)

Hey all,

 

another PaperCutter here.

This one is strange.

At a technical level, the PaperCut User Client uses a lightweight XMLRPC over HTTP (and HTTPS) to communicate with the PaperCut Application Server.

The hostname/IP address is configured via the config.properties file. Specifically these three values:

server-name=printserver.company.lan

server-ip=10.0.0.39

server-port=9191

Something to note here. We have both a server-name and server-ip.

The PaperCut User Client will attempt communicate on the server-name where possible, and fall back to the server-ip.

You can enable debugging in the PaperCut User Client as described here: https://www.papercut.com/kb/Main/HowToEnableDebugInTheUserClient

You'll see something like this for a working server-name:

2020-12-15 10:47:03,171 DEBUG UserClientDispatcher:39 - Creating server connection: 10.0.0.39:9191, timeout: 90s [main]

2020-12-15 10:47:03,406 DEBUG ServerConnection:730 - Client's list of IP addresses is: 10.0.0.61,fe80:0:0:0:2477:fc8:6b35:1857%wlan0. Previously: [main]

2020-12-15 10:47:03,410 DEBUG ServerConnection:139 - Attempting to connect using server's name: http://printserver.company.lan:9191/rpc/clients/xmlrpc [main]

2020-12-15 10:47:03,412 DEBUG ServerConnection:269 - Pinging server [main]

2020-12-15 10:47:03,412 DEBUG ServerConnection:1005 - Calling method: client.ping (parameters suppressed) [main]

2020-12-15 10:47:03,432 DEBUG ServerConnection:1010 - Call to method: client.ping took 20 ms. Result: true [main]

2020-12-15 10:47:03,432 DEBUG ServerConnection:743 - Requesting global config data from server [main]

2020-12-15 10:47:03,432 DEBUG ServerConnection:1005 - Calling method: client.getGlobalConfig (parameters suppressed) [main]

When the server-name doesn't work.. you get something like this.. (I've removed some of the log entries and replaced it with -snip-).

2020-12-15 10:49:27,342 DEBUG UserClientDispatcher:39 - Creating server connection: 10.0.0.39:9191, timeout: 90s [main]

2020-12-15 10:49:27,602 DEBUG ServerConnection:730 - Client's list of IP addresses is: 10.0.0.61,fe80:0:0:0:2477:fc8:6b35:1857%wlan0. Previously: [main]

2020-12-15 10:49:27,607 DEBUG ServerConnection:139 - Attempting to connect using server's name: http://printservertypo.company.lan:9191/rpc/clients/xmlrpc [main]

2020-12-15 10:49:27,608 DEBUG ServerConnection:269 - Pinging server [main]

2020-12-15 10:49:27,609 DEBUG ServerConnection:1005 - Calling method: client.ping (parameters suppressed) [main]

2020-12-15 10:49:27,821 DEBUG ServerConnection:143 - Failed to connect to server using server name. Problem communicating with server: printservertypo.company.lan [main]

biz.papercut.pcng.client.uit.ServerConnection$ServerConnectionException: Problem communicating with server: printservertypo.company.lan

-snip-

Caused by: java.net.UnknownHostException: printservertypo.company.lan

-snip-

... 4 more

2020-12-15 10:49:27,822 DEBUG ServerConnection:152 - Attempting to connect using server's IP: http://10.0.0.39:9191/rpc/clients/xmlrpc [main]

2020-12-15 10:49:27,823 DEBUG ServerConnection:269 - Pinging server [main]2020-12-15 10:49:27,823 DEBUG ServerConnection:1005 - Calling method: client.ping (parameters suppressed) [main]

As you can see, DNS resolution has failed, and it's falling back to using the IP address.

If it still fails to connect, you'll see something like this:

2020-12-15 10:50:09,841 DEBUG ServerConnection:156 - Failed to connect to server using ip address. Problem communicating with server: Connection timed out: connect [main]

biz.papercut.pcng.client.uit.ServerConnection$ServerConnectionException: Problem communicating with server: Connection timed out: connect

-snip-

Caused by: java.net.ConnectException: Connection timed out: connect

at java.base/java.net.PlainSocketImpl.waitForConnect(Native Method)

Or something similar.

So.. Whats happening in this exact case? I don't know :-)

What I'd suggest doing is enabling debug and then peering at the logs.

One thing I will say... We rely on DNS at the operating system working correctly. If the PaperCut User Client requests a hostname->IP lookup, which the OS has cached a bad NXDOMAIN response or has a stale A/AAAA record, then that will be transparent to us. Maybe configuring tighter a TTL on that record could help?

Another possibility is with the stale A/AAAA record pointing to an IP that is no longer available on the new access point due to firewall rules or similar?

Something that just occurred to me, if server-name is just a hostname, e.g. printserver, then you're not only relying on DNS working, you're relying on search suffixes working (and being in the correct order) and possibly even falling back to NETBIOS/WINS (!) on Windows, and Bonjour/ZeroConf/mDNS on macOS which can be very unreliable. Best to ensure you're using a FQDN there.

 

Edit: Ok. Line endings are hard. I've tried to re-format.

Edited by jasonatpapercut
  • Thanks 1

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now



×
×
  • Create New...