Network Card Reader Technical Overview

Introduction

Network card readers are network connected card readers that communicate directly with the PaperCut application server via a network interface (eg. TCP/IP, HTTP, etc). These types of devices are supported on certain vendors multi function devices (MFD) and for fast release print queues. This feature allows a wide range of different authentication technologies to be used at the MFD to unlock devices. This document provides a high level overview for our partners to understand if this approach will work with their authentication solution.

The principal design goal with the network card reader protocol was simplicity to allow the widest possible area of application and the protocol has been in use for a number of years.

PaperCut welcomes feedback and further discussion, please send questions and suggestions to PaperCut support. If you are planning to implement an authentication solution using this approach please register with our team so that we can assist you.

Connection Modes (PaperCut v17.2.3+):

As of version 17.2.3, custom ‘Connection Modes’ have been added for network card readers that are configured through the devices Access Methods. The protocol mentioned above which allows for integration with a partner’s authentication solution is labelled ‘Generic Mode’. Additional ‘Connection Modes’ are listed below.

Users who have a version of PaperCut prior to 17.2.3 will not have the ‘Connection Modes’ feature, and all network card readers will use the ‘Network Card Reader Authentication Protocol’ described below.

‘Generic’ Connection Mode:

Used for e.g. the Elatec TCP Converter 2, RFIdeas 241 (Server mode) and other readers.

How does it work?

The authentication terminal (for example proprietary building access card reader located at each MFD) communicates with PaperCut’s application server over a TCP/IP socket. Each authentication terminal maintains its own socket connection and the connection is initiated by the terminal creating an outbound socket to the PaperCut server.

This means that each TCP address and socket number is associated in PaperCut with a corresponding MFD device to be managed. Note that the MFD uses a different network connection and address to the authentication terminal.

Correspondence between user accounts in PaperCut and the authentication is managed via a card number, which can be any sequence of alphanumeric digits that both systems have associated with the correct accounts.

In Detail:

1. The PaperCut application server opens an outbound blocking TCP/IP socket connection to the authentication terminal (e.g. a card reader)
2. The authentication terminal accepts the inbound socket connection from the correct TCP/IP address and socket
3. The PaperCut server will send various strings to the terminal to probe its capabilities. These are ignored by the terminal
4. An end user approaches an MFD/terminal
5. They authenticate themselves on the terminal as appropriate (e.g. by swiping their card)
6. The authentication system extracts the user’s card number
7. The authentication system satisfies itself of the user’s bona fides (e.g. the card type and car number are valid. The terminal may perform additional validation e.g. biometric data lookup)
8. The card number, plus a trailing newline character (\n), are sent to the PaperCut server via the accepted socket
9. PaperCut reads the card number and looks up the corresponding user account details in the PaperCut database
10. PaperCut unlocks the MFD (if supported) or releases the user’s print job
11. If the socket connection is closed, or fails, the terminal should wait (accept) for further socket connections. The PaperCut server will retry connection automatically on failure
12. PaperCut will send semi regular “keep alive” signals (‘\r’) to the terminal. These can be ignored, but if a response is provided then PaperCut will ignore it.

PaperCut can supply an example Python implementation to illustrate this if needed. Please ask our support team.

Note:

Please contact PaperCut to make sure that this protocol works currently with your proposed MFD solution. Not all multi function devices can be unlocked using an external authentication terminal.

RFIDeas 241 (Client Mode):

(as of v17.2.3+)

This is a custom connection mode for ‘RFIDeas Ethernet 241’ network card readers. This mode makes use of the ‘Client Mode’ feature of 241 devices, documented in the 241 User Manual. In this mode, communication with the network card reader is handled via HTTP requests. The advantage of using this mode is that it can provide greater stability of communications on a network that may be flaky or unstable.

This mode is supported by ‘RFIDeas Ethernet 241’ network card readers with firmware version 2.04+.

Detailed Behaviour:

1. An administrator configures the PaperCut Application Server to use a network card reader with a given hostname in ‘RFIDeas 241 (Client Mode)’ connection mode. Note: Port number is not necessary in ‘RFIDeas 241 (Client Mode)’
2. PaperCut application server performs a series of HTTP GET requests to configure the 241 device at the given hostname with the appropriate settings
3. Upon successful configuration, the PaperCut Application Server performs checks to ensure that the 241 device is correctly configured at regular intervals. If the 241 device is found to have an incorrect configuration, it will be reconfigured by the same method as in step 2.
4. When a user swipes a card on the card reader, the 241 device will send a HTTPS GET request to the PaperCut Application Server containing the card number. The PaperCut Application Server will process this request and unlock the device or release the users jobs.
5. If the PaperCut Application Server is unable to connect to the 241 device, it will display an error on the device page, and retry connecting at regular intervals.