Network Card Reader Technical Overview

KB Home   |   Network Card Reader Technical Overview

Main.NetworkCardReaderProtocol History

Hide minor edits - Show changes to output

June 03, 2019, at 06:17 AM by Tim Shimmin - fix typos
Changed lines 9-10 from:
PaperCut welcome 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.
to:
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.
Changed lines 25-28 from:
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 outbount 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
to:
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.
Changed line 34 from:
# The PaperCut will send various strings to the terminal to probe it's capabilities. These are ignored by the terminal
to:
# The PaperCut server will send various strings to the terminal to probe its capabilities. These are ignored by the terminal
Changed line 39 from:
# The card number, plus a trailing newline character (\n), is sent to the PaperCut server via the accepted socket
to:
# The card number, plus a trailing newline character (\n), are sent to the PaperCut server via the accepted socket
Changed lines 49-50 from:
Our protocol can work with the only basic card number above as described above.
to:
Our protocol can work with only basic card numbers as described above.
Changed line 53 from:
When PaperCut sends the 'v' command then additional "features" can be enabled by emulating a Elatec device running PaperCut's
to:
When PaperCut sends the 'v' command then additional "features" can be enabled by emulating an Elatec device running PaperCut's
Changed line 15 from:
As of version 17.2.3, custom ‘Connection Modes’ have been added for network card readers that are attached to devices directly. The protocol mentioned above which allows for integration with a partner’s authentication solution is labelled ‘Generic Mode’. Additional ‘Connection Modes’ are listed below.
to:
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.
Changed line 15 from:
As of version 17.2.3, custom ‘Connection Modes’ have been added for network card readers. The protocol mentioned above which allows for integration with a partner’s authentication solution is labelled ‘Generic Mode’. Additional ‘Connection Modes’ are listed below.
to:
As of version 17.2.3, custom ‘Connection Modes’ have been added for network card readers that are attached to devices directly. The protocol mentioned above which allows for integration with a partner’s authentication solution is labelled ‘Generic Mode’. Additional ‘Connection Modes’ are listed below.
Changed lines 20-23 from:
''(as of  v17.2.3+)''

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

'''Used for e.g. the Elatec TCP Converter 2, [=RFIdeas=] 241 (Server mode) and other readers. '''
Changed lines 74-77 from:
!! [=RFIDeas=] 241 (Client Mode): (Since 17.2.3)
to:
!! [=RFIDeas=] 241 (Client Mode):

''(as of  v17
.2.3+)''
Changed line 92 from:
[-Keywords: card reader, network authentication,rfideas,241-]
to:
[-Keywords: card reader, network authentication,rfideas,241-]
July 31, 2017, at 07:06 PM by timg - Updated to include Elatec examples.
Changed lines 19-20 from:
!! The Network Card Reader Authentication Protocol:
'''Note: known as ‘Generic’ connection mode as of  v17.2.3+'''
to:
!! 'Generic' Connection Mode:
''(as of v17.2.3+)''

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

Changed lines 75-76 from:
!! Additional Connection Modes (v17.2.3+):
!!! [=RFIDeas=] 241 (Client Mode):
to:
!! [=RFIDeas=] 241 (Client Mode): (Since 17.2.3)
July 24, 2017, at 06:51 AM by 139.130.165.134 -
Changed lines 73-77 from:
!!! RFIDeas 241 (Client Mode):
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 [[https://www.rfideas.com/files/downloads/manuals/Ethernet241_USB-Serial_Manual.pdf | 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+.
to:
!!! [=RFIDeas=] 241 (Client Mode):
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 [[https://www.rfideas.com/files/downloads/manuals/Ethernet241_USB-Serial_Manual.pdf | 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+.
Changed line 79 from:
# 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)’
to:
# 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)’
July 24, 2017, at 12:42 AM by 139.130.165.134 -
Changed lines 5-6 from:
Network card readers are network connected card readers that communicate directly with the PaperCut application server over TCP/IP. 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.
to:
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.
Changed line 8 from:
 
to:
Changed lines 11-12 from:
!! How does it work?
to:
!!!! Connection Modes (PaperCut v17.2.3+):

Attach:connection_types.png

As of version 17.2.3, custom ‘Connection Modes’ have been added for network card readers. 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.

!! The Network Card Reader Authentication Protocol:
'''Note: known as ‘Generic’ connection mode as of  v17.2.3+'''
!!
!! How does it work?
Changed lines 29-30 from:
!! In Detail
to:
!!!! In Detail:
Changed line 69 from:
!! Note
to:
!!!! Note:
Changed lines 72-84 from:
to:
!! Additional Connection Modes (v17.2.3+):
!!! RFIDeas 241 (Client Mode):
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 [[https://www.rfideas.com/files/downloads/manuals/Ethernet241_USB-Serial_Manual.pdf | 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:
# 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)’
# PaperCut application server performs a series of HTTP GET requests to configure the 241 device at the given hostname with the appropriate settings
# 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.
# 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.
# 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.

Changed line 88 from:
[-Keywords: card reader, network authentication-]
to:
[-Keywords: card reader, network authentication,rfideas,241-]
February 24, 2015, at 12:58 AM by Alec - Updated to be more accurate and remove things not supported by generic card reader type
Added line 23:
# The PaperCut will send various strings to the terminal to probe it's capabilities. These are ignored by the terminal
Changed lines 26-27 from:
# The authentication system locates the users card number
# The authentication system satisfies itself of the user's bona fides (e.g. the card type and car number are valid)
to:
# The authentication system extracts the user's card number
# 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)
Changed lines 29-33 from:
# PaperCut reads the card number and looks up the corresponding user account details
# PaperCut unlocks the MFD and the users access is managed.
# 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.

to:
# PaperCut reads the card number and looks up the corresponding user account details in the PaperCut database
# PaperCut unlocks the MFD or releases
the user's print job
# 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
# 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.

(:if false:)

Changed lines 38-39 from:
Our protocol can work with the only basic card number above. However there are some additional features that may be useful.
* PaperCut can send the following characters to the authentication system.
to:
Our protocol can work with the only basic card number above as described above.

However there are some additional features that may be
useful.

When PaperCut sends the 'v' command then additional "features" can be enabled by emulating a Elatec device running PaperCut's
custom script, as follows:

When the 'v' command is received the terminal should respond with a string that starts "PC-ELA." and then has a custom ID. e.g. "PC-ELA.Custom Script"

* PaperCut can then send the following characters to the terminal
system.
Changed lines 49-51 from:
** ‘v’ used to request a version string terminated by a ‘\n’
** ‘e’ traditionally used to light an error indicator
* The Authentication system can send the character ‘E’ followed by ‘\n’ to PaperCut to indicate an error has occurred.
to:
** ‘e’ traditionally used to light red or green LEDs
*** 'e22 -- Invalid card
*** 'e12' -- valid card and pending jobs have been released
*** 'e21' -- valid card but no jobs pending release

This is a lie! 
* The Authentication system can send the character ‘E’ followed by ‘\n’ to PaperCut to indicate an error has occurred.
Added lines 56-57:
(:ifend:)
July 14, 2014, at 05:45 AM by Alec - Tidy up
Changed lines 21-32 from:
  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. An end user approaches an MFD/terminal
  4. They authenticate themselves on the terminal as appropriate (e.g. by swiping their card)
  5. The authentication system locates the users card number
  6. The authentication system satisfies itself of the user's bona fides (e.g. the card type and car number are valid)
  7. The card number, plus a trailing newline character (\n), is sent to the PaperCut server via the accepted socket
  8. PaperCut reads the card number and looks up the corresponding user account details
  9. PaperCut unlocks the MFD and the users access is managed.
  10. 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.

to:
# The PaperCut application server opens an outbound blocking TCP/IP socket connection to the authentication terminal (e.g. a card reader)
# The authentication terminal accepts the inbound socket connection from the correct TCP/IP address and socket
# An end user approaches an MFD/terminal
# They authenticate themselves on the terminal as appropriate (e.g. by swiping their card)
# The authentication system locates the users card number
# The authentication system satisfies itself of the user's bona fides (e.g. the card type and car number are valid)
# The card number, plus a trailing newline character (\n), is sent to the PaperCut server via the accepted socket
# PaperCut reads the card number and looks up the corresponding user account details
# PaperCut unlocks the MFD and the users access is managed.
# 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.

Changed lines 36-40 from:
  * PaperCut can send the following characters to the authentication system.
    * ‘b’ traditionally used to make a “beep” sound
    * ‘v’ used to request a version string terminated by a ‘\n’
    * ‘e’ traditionally used to light an error indicator
 
* The Authentication system can send the character ‘E’ followed by ‘\n’ to PaperCut to indicate an error has occurred.
to:
* PaperCut can send the following characters to the authentication system.
** ‘b’ traditionally used to make a “beep” sound
** ‘v’ used to request a version string terminated by a ‘\n’
** ‘e’ traditionally used to light an error indicator
*
The Authentication system can send the character ‘E’ followed by ‘\n’ to PaperCut to indicate an error has occurred.
Deleted lines 47-48:
TODO link your page here: https://www.papercut.com/kb/Main/Miscellaneous
July 14, 2014, at 03:58 AM by Alec - Added New Page
Added lines 1-53:
(:title Network Card Reader Technical Overview:)

!! Introduction

Network card readers are network connected card readers that communicate directly with the PaperCut application server over TCP/IP. 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 welcome 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.

!! 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 outbount 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. An end user approaches an MFD/terminal
  4. They authenticate themselves on the terminal as appropriate (e.g. by swiping their card)
  5. The authentication system locates the users card number
  6. The authentication system satisfies itself of the user's bona fides (e.g. the card type and car number are valid)
  7. The card number, plus a trailing newline character (\n), is sent to the PaperCut server via the accepted socket
  8. PaperCut reads the card number and looks up the corresponding user account details
  9. PaperCut unlocks the MFD and the users access is managed.
  10.  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.


!! Additional Features

Our protocol can work with the only basic card number above. However there are some additional features that may be useful.
  * PaperCut can send the following characters to the authentication system.
    * ‘b’ traditionally used to make a “beep” sound
    * ‘v’ used to request a version string terminated by a ‘\n’
    * ‘e’ traditionally used to light an error indicator
  * The Authentication system can send the character ‘E’ followed by ‘\n’ to PaperCut to indicate an error has occurred.
 
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.


TODO link your page here: https://www.papercut.com/kb/Main/Miscellaneous

----
''Categories:'' [[Category.API|+]]
----
[-Keywords: card reader, network authentication-]

Comments

Share your findings and experience with other PaperCut users. Feel free to add comments and suggestions about this Knowledge Base article. Please don't use this for support requests.

Article last modified on June 03, 2019, at 06:17 AM
Printable View   |   Article History   |   Edit Article