[PyKota] [pykota-techsupport] [URGENT] Hardware accounting bypass

Jerome Alet alet at librelogiciel.com
Wed Oct 4 00:38:59 CEST 2006


Hi again,

On Tue, Oct 03, 2006 at 08:39:38PM +0200, Jerome Alet wrote:
> 
> Due to a severe misdesign in a change added last January to PyKota's 
> hardware accounting code, there's a way to bypass hardware accounting 
> entirely without needing any access to a PyKota print server. 
> 
> MoDax has just reported a simple way for any user, even stupid ones, 
> to bypass PyKota's SNMP and PJL accounting and print for free. 

Fortunately this particular case could only occur on some faulty 
printers. The problem was reported on a Samsung ML2551n, which 
doesn't report any error status when the paper tray is open or empty 
(and now you know how to bypass hardware accounting, if you do it 
with the right timing). 

But unfortunately, I discovered another similar possibility I'm not 
very proud of, which could cause the same result with non-buggy 
printers (I'll let you guess this one though, for fear of looking 
stupid). 

I believe the problem is now fixed in the latest development
tree, and I urge you to upgrade if you plan to use hardware
accounting :

        $ cd /tmp
        $ svn export svn://svn.librelogiciel.com/pykota/trunk pykota
        $ cd pykota
        $ python setup.py install

You can then restore your old configuration wrt hardware
accounting in pykota.conf 

I mostly worked on improving the reliability of SNMP accounting,
because I wasn't able to reproduce the problem with PJL accounting.

This doesn't mean that PJL code doesn't still suffer from similar
problems, time and many testers will tell I hope...

The code changes I did include the handling of corner cases, as well 
as the addition of the 'noprintingmaxdelay' directive, to workaround 
the buggy printers mentionned above. If you set this directive to 0, 
then PyKota will wait indefinitely until the printer is in 
'printing' mode once the job has been sent to it. If you set it to 
another value, PyKota will wait at most this duration in seconds, 
will then abort, and use the latest internal page counter value seen 
during probes. If you don't set it, the previously hardcoded value 
of 60 seconds is used.

The value of 0 restores PyKota's behavior from before January 2006, 
so in fact downgrading to a very old version would have fixed the 
problem as well ;-) 

Please report any problem with these changes ASAP.

Thanks for your patience.

Jerome Alet



More information about the pykota mailing list