Papercut Card ID and Ricoh

[bigal06]

Hi,

 

We have just put in new Ricoh copiers with new card readers and they are not giving the same numbers as stored in Papercut which means that all users will have to re-associate their badges but we also use that number from Papercut to import into the door access systems and of course the new number doesn't relate to the door readers even after running conversions by reversing bits and/or decimal to Hex.

 

I have reprogrammed the card readers and they new put out the correct number when testing in a notepad - this number matches the number in Papercut and the number produced by the old card readers but Papercut is not having it. For example - card reader output to text field as testing is: 937675940 and this matched the number stored in the primary id in Papercut but somewhere the number gets mangled and Papercut sees it as Unknown Card/ID number entered on external device. Card/ID No: 1055154890231841895472 which bears no resemblance to the one coming from the reader. I have a script that can convert Hex to Decimal and also reverse the Bits but this number does not compute. Out of interest I have tried the old card reader on the new copier and it produces the same incorrect number so it must be something to do with the Ricoh copier mangling the number? I have also plugged in the old Sharp copiers and they are still working.

 

Can anyone shed any light on this?

 

Many thanks

Allan

[localzuk]

Do you have anything in the advanced config "ext-device-card-no-converter" or "ext-device-card-no-regex"? Either on the device, or in the global advanced settings?

[bigal06]

Thanks for your reply - no we don't have anything in those settings although I was thinking of somehow using those somehow to get the number back to how it should be.

 

* EDIT - Apologies, I did have something in one of those for testing to try and fix it but removing it still produces the wrong number.

Edited August 17, 2023 by bigal06

[Jawloms]

Our PaperCut install looks to the Secondary "Card/Identity numbers" field when we beep badges. No idea why, always thought it odd, but is that where yours is looking?

[bigal06]

Our PaperCut install looks to the Secondary "Card/Identity numbers" field when we beep badges. No idea why, always thought it odd, but is that where yours is looking?

 

Ours look at primary and always has done. Everything fine until Ricoh printers

[localzuk]

What readers do you have, and what type of RFID card are you using?

[bigal06]

What readers do you have, and what type of RFID card are you using?

 

Hi, they are ELATEC TWN4 and we use Mifare. I have reprogrammed the readers to produce the correct digital number from the device matching the ones stored in the primary CardID in Papercut. This matches the old readers output and the old readers go wrong on the new copiers too.

 

I made a mistake on the first post but the number from the card when scanned on the reader is 937675940 and papercut sees it as 393337363735393430 which is useless as our door readers can't fathom that one out despite various conversions I have tried.

 

Thanks

Allan

[localzuk]

So, Ricoh is inserting extra 3s.

 

393337363735393430

 

You could convert this with the following javascript in a custom js file I think? And then call that file via ext-device.card-no-converter.

function convert(cardNumber) {
return extractOddLetters(cardNumber);
}
const extractOddLetters = (string) => {        
for (var i = 0; i < string.length; i++) { 
       // If current index is odd       
if (i % 2 === 1) {
            // Skip the character
           continue;        
}         // Otherwise, append the        
// character        
new_string += string[i];        
}        
return new_string;    
}
}
;

Edited August 17, 2023 by localzuk

[PotNoodleTech]

That's a strange one - my Ricoh copiers and papercut store the correct number in papercut. Using mifare cards for both MFDs and building access. Are they mifare cards as they are 100% supported?

 

Maybe the new copier card readers are having trouble with your cards?

[bigal06]

So, Ricoh is inserting extra 3s.

 

393337363735393430

 

You could convert this with the following javascript in a custom js file I think? And then call that file via ext-device.card-no-converter.

function convert(cardNumber) {
return extractOddLetters(cardNumber);
}
const extractOddLetters = (string) => {        
for (var i = 0; i < string.length; i++) { 
       // If current index is odd       
if (i % 2 === 1) {
            // Skip the character
           continue;        
}         // Otherwise, append the        
// character        
new_string += string[i];        
}        
return new_string;    
}
}
;

 

Yes! I didn't even see that.......

 

Let me try with your script.

 

Thanks so much for spotting that!

 

Allan

[localzuk]

Note - I haven't tested that script, so it may not work, but the concept should work.

[bigal06]

Note - I haven't tested that script, so it may not work, but the concept should work.

 

Yeah, no worries. It might be a REGEX or something but at least you found the number for me...

 

Thanks

[bigal06]

Thanks all especially @localzuk for seeing the pattern in the number. After speaking to Papercut Support is appears that although I have set the card reader to output in decimal the Ricoh copier is ASCII encoding that (adding 3's) and then passing it to Papercut so:

 

1. Log in to the PaperCut MF Admin web interface.

2. Navigate to Devices.

3. Select the required device.

4. Click Advanced Config

5. Search for "ext-device.card-no-converter" it may be set to "GLOBAL"

6. Switch "GLOBAL" to "ascii-enc" then click "update all"

7. Test it to see if ll the 3s get removed

 

Works like a treat!

 

Allan

[Space_Munkey]

Sorry if this counts as necro but the thread helped me with out new Ricoh printers and I wanted to give back to the community.

 

Essentially, I've had to use all 3 conversion methods in order to get the correct string.

 

ascii-enc was the first, which as above mentioned removes the 3's. Then I was left with a decimal number which needed to be converted to hexidecimal - dec2hex. This is where the headbanging began because it was giving me the correct string, only it was reversed and each pair were also reversed for example:

 

ascii-enc|dex2hex - C42EA3EA

 

Actual card serial number - EAA32EC4

 

I then began trying to add javascript: custom/converter.js into the mix. I tried so many different variations but none seemed to work... until yesterday, I guess I finally gave the correct prompt to ChatGPT and it spat out the following:

 

function convert(cardNumber) {

return cardNumber.match(/(.{1,2})/g).reverse().join('');

}

I changed the security.properties file in /server/ in the papercut installation folder from allowing custom converter script to be allowed from anywhere * to only that directory. I also restarted the application service.

 

I then changed the printer config to: ascii-enc | dec2hex | javascript: custom/converter.js

 

This now appears to show the correct card number!

 

Only took 3 months to work out.

Edited February 21, 2024 by Space_Munkey

[Bankesy]

So my suggestion might be way off but we had something similar when upgrading our Ricoh printers recently because the old card readers had a kind of SIM card in them that converted the number on the card.

 

We don't use MiFare though, these 'SIM cards' were effectively making our HID iClass cards work.

[Space_Munkey]

Returning to add some more helpful info / an update.

 

I was able to use python to convert the number with 3's to decimal, then to hexadecimal to match the serial format we needed. These scripts used "pandas" which is a python library used for large scientific data crunching but seemed to make mince meat of export converted numbers into a csv.

 

I then did a batch update of all users primary card number via the print server.

 

However shortly after putting the previous post's changes into effect over the half term just gone, we had some staff reporting the need to re-associate their cards.

 

On inspection, it seems that their Card number was showing the correct characters, just in the wrong order (which is what I found with mine, and why I created the card conversion javascript the way I did). Myself and my managers cards were both showing correctly as well as a number of cards we had laying around.

 

I've now spent some time researching this and believe that it could be that the card type are ever so slightly different. Essentially some cards are being read as least important byte first and other most important byte first. I believe this translates alos in to big endian and little endian (my conversion script converts the resulting hex card numbers into little endian rules).

 

I also did some poking around in the printer settings to look at the card readers options, to see if I could just swap the protocol - but after breaking it and having to call Ricoh, our engineer basically explained that because we have a proximity reader, we cannot change the way the number is read without purchasing / replacing with an NFC reader.

 

So yeah, back to the drawing board ...

[Chris_Cook]

Are all your card readrs the same? And the device settings on papercut?