PDA

View Full Version : C654 / C754 Account track


Custom Search


EarthKmTech
08-28-2012, 09:18 AM
On what port is the authentication information transferred to the copier ?

In several locations we are having the authentication information being blocked from arriving at the printer and jobs being deleted due to group authentication errors.

Direct printing to the device works flawlessly, this is happening only via a shared printer driver on a server.

emujo
08-28-2012, 02:19 PM
Not 100% sure of this, but if your SNMP setting are not configured correctly, the MFP will not be able to report the proper configuration back to the driver..You may want to start looking at this section. Emujo

EarthKmTech
08-28-2012, 11:47 PM
I did notice when you go into the printer driver preferences, there is considerable SNMP traffic generated when you click on the authentication section to enter in the password.

the previous generation machines in the same section communicate on port 80, which explains why there was an enormous delay in proxied environments unless the copiers IP was added as an exception.

I also noticed some communication on port 50003 on the old generation machine but not on the c654/754.

they have definitely changed the way it works and im yet to figure it out.

(I've been playing with wireshark)

Mr Spock
08-29-2012, 12:09 AM
Also if the enduser does not have rights to change machine settings sometimes this will cause the same issue.

EarthKmTech
09-03-2012, 10:05 AM
Problem solved.

In certain environments (unknown why) the automatic synchronization of the factory preset driver encryption pass phrase between the machine and the driver fails in the background with no error given what so ever.

mfp configuration works perfectly along with automatic detection of all options etc so not sure whats going on.

in these certain environments its a requirement that you set the driver encryption pass phrase to user input and create a 20 character pass phrase for the mfp and the driver.

problem solved instantly.

account track now works as expected with the authentication information arriving at the machine as expected and logging jobs against the correct accounts.

manlyman07
10-18-2012, 12:13 AM
Hi.

I have this problem in an environment where 95% of the PC's are XP and a handful are printing locally using Windows 7. The XP pcs use a shared driver and have no issues using account track. Although when printing via Windows 7 driver it comes up with an authentication issue on the machine. I got it to work creating a encryption pass phrase but then of course it stops the Windows XP machines from printing. I would have to apply the passphrase to the shared driver on the server for it to work on the XP devices but the customers I.T. are reluctant to do this and they are adament that there is another answer for this problem. Any thoughts? I have escalated the call so we'll see what happens.

P.S. Another engineer said that he had the same problem at a customers office and he also created the pass phrase so the customer could print using Windows 7. A month later he was called back because the customer couldn't print again and this time he turned off encryption back to factory default and it worked. He thinks a Windows update or something has been applied to fix the issue but doesn't know what exactly. Hmmm??

Thanks

EarthKmTech
10-18-2012, 09:59 AM
Since doing this, I've never heard back from them so its still working.

If you change pass-phrase from factory default they must match on ALL driver installations otherwise any that don't match WONT work.

In 99.999% of installations it works on factory. There is something blocking the communication between the driver and the mfp in that customer I spoke of and to this date no one knows what it was.

Its not overly clear how the driver communicates any of this information from the MFP. I tried doing a packet capture and couldn't see anything remotely relevant. They've made it so secure we don't even know how to make it work when it doesn't.

I'm the one that passed on the work around to those one escalates to as they couldn't even reproduce the fault, nor did they even believe me at first.

kon
10-19-2012, 12:31 AM
Since doing this, I've never heard back from them so its still working.

If you change pass-phrase from factory default they must match on ALL driver installations otherwise any that don't match WONT work.

In 99.999% of installations it works on factory. There is something blocking the communication between the driver and the mfp in that customer I spoke of and to this date no one knows what it was.

Its not overly clear how the driver communicates any of this information from the MFP. I tried doing a packet capture and couldn't see anything remotely relevant. They've made it so secure we don't even know how to make it work when it doesn't.

I'm the one that passed on the work around to those one escalates to as they couldn't even reproduce the fault, nor did they even believe me at first.

Have you checked what the the network error code is when the problem occurs?
This has been very handy in troubleshooting weird network problems.
Its usage is listed on page K -152 of the 754 -654 service manual.

Custom Search