Таблетка от жадности для производителей струйных принтеров
kayo — Чт, 15/03/2018 - 16:18
Есть такая штука: утилизация неиспользованных чернил. Ввиду конструкции и от части специфики использования при печати без полей и особенно в процессе очистки сопел некоторая часть чернил неизбежно расходуется впустую и попадает в специальные области со впитывающим материалом. Гипотетически в определённый момент эти резервуары могут переполниться чернилами и привести к поломке устройства. Производители не стали особо заморачиваться с определением этого момента и просто завели счётчики, инкрементирующиеся программно с привязкой к числу отпечатанных страниц и проходов очистки. Теоретически всё разумно, а вот на практике ситуация доходит до абсурда: один из счётчиков переполняется и устройство отказывается работать дальше, даже если на деле до настоящего переполнения ещё очень далеко. Ситуация усугубляется тем, что производитель не предоставляет никаких решений, позволяющих вернуть устройство к жизни. Именно с этим случаем столкнулся владелец одного из таких принтеров Epson XP-435. Что ж, будем лечить.
Решений от производителя, как было отмечено выше, нет. То есть нет от слова совсем. Для некоторых офисных моделей предоставляется утилита для однократного сброса счётчиков, для других же нет ничего, кроме предложения сдать устройство по программе утилизации. А что если у владельца проблема возникла уже через пол года использования, и осмотр внутренностей показал, что до переполнения аппарат может проработать ещё в 5 раз дольше? Или если владелец произвёл чистку аппарата своими силами и желает продолжить его использование?
Но техподдержка разводит руками, топ-менеджмент пухнет от жадности, подсчитывая прибыли, строя дальнейшие планы по запланированному устареванию. А сервисники не аффилированные с производителями тем временем находят способы сброса этих внутренних счётчиков и делают свой бизнес на решении взявшихся из ниоткуда проблем, которых в нормальном здоровом обществе не должно быть в принципе. Некоторые сервисники пошли дальше других, предоставляя пользователям утилиты для сброса, требующие по ~10 USD за каждую такую операцию, которая ничего особенного из себя не представляет.
Можно было бы вполне обойтись здесь без всех этих рассуждений, но меня, как человека, далёкого от подобного рода устройств с их проблемами, данная ситуация не мало удивила. А помочь владельцу решить проблему переполнения счётчиков раз и на всегда тем не менее хотелось.
Исследуем процедуру чтения и записи значений
Для начала нужно было понять, как происходит работа обслуживающего софта с принтером. Для этого мы запустили одну из сторонних программ и попытались считать значения счётчиков. Но мы не обычные пользователи, а инженеры, поэтому программу запустили под strace, захватывая весь сетевой трафик между хостом и устройством wireshark-ом.
Удалось выяснить, что обмен происходит с использованием исключительно get запросов протокола SNMP v1 с community: public. Demo сброс позволил захватить трафик записи значений, а последующее чтение помогло интерпретировать формат данных.
Чтение значений счётчиков отработки
Вот как происходит чтение регистра счётчика:
get запрос <oid-префикс>.<адрес-регистра> get ответ <префикс><адрес-регистра><байт данных><суффикс>
Запрос делается на некий идентификатор объекта, состоящий из двух частей. В таблице ниже приведены их значения для Epson XP-435:
| oid-префикс | 1.3.6.1.4.1.1248.1.2.2.44.1.1.2. 1.124.124.7.0.133.5.65.190.160 |
| младший байт первого счётчика | 24.0 (0x0018) |
| старший байт первого счётчика | 25.0 (0x0019) |
| дополнительный байт первого счётчика | 30.0 (0x001E) |
| младший байт второго счётчика | 26.0 (0x001A) |
| старший байт второго счётчика | 27.0 (0x001B) |
| дополнительный байт второго счётчика | 34.0 (0x0022) |
Ответ приходит в виде строки октетов (а по сути текстом) в следующей форме:
\0@BDC PS\r\nEE:001899;\f // младший байт первого счётчика \0@BDC PS\r\nEE:00190F;\f // старший байт первого счётчика \0@BDC PS\r\nEE:001E00;\f // дополнительный байт
Здесь приведены ответы на три запроса: в первом значение регистра 0x0018 (24.0), равное 0x99, во втором значение регистра 0x0019 (25.0), равное 0x0F, а в третьем нулевое значение регистра 0x001E (30.0). Я не понял, для чего нужны дополнительные байты, но их читают и пишут, и значения всегда нулевые.
Интерпретация значений счётчиков
Теперь осталось интерпретировать значения. Для начала предположим что счётчики считают от нуля, а поскольку о порогах переполнения нам ничего не известно, то будем определять их косвенно через текущие значения. Значение одного из счётчиков достигло порога, а значит максимальное значение можно принять за 100%. Это в нашем случае был первый счётчик. Порог другого счётчика определить сложнее, поскольку он ещё не достиг стадии срабатывания. Мы можем либо положиться на данные из сторонних обслуживающих программ, либо опытным путём попробовать вызвать переполнение.
У меня получились следующие пороги срабатывания:
| Счётчик | Пороговое значение |
| Первый | 0x0f96 |
| Второй | 0x0cb6 |
Запись значений счётчиков отработки
Запись происходит также посредством get запросов SNMP. Инженегры из Epson, как видим, не стали особо заморачиваться с привязкой переменных (variable-bindings), и данные передаются непосредственно в идентификаторах объектов.
Вот как происходит запись регистра:
get запрос <oid-префикс>.<адрес-регистра>.<значение>.<oid-суффикс> get ответ \0||:42:OK;\f
Адреса регистров кодируются в oid также, как в запросах на чтение. В таблице ниже представлены значения oid префикса и суффикса для Epson XP-435:
| oid-префикс | 1.3.6.1.4.1.1248.1.2.2.44.1.1.2.1.124.124.16.0.133.5.66.189.33 |
| oid-суффикс | 81.112.109.122.121.102.111.98 |
Ниже пример перезаписи значения первого счётчика:
get запрос oid-префикс.24.0.0.oid-суффикс get ответ \0||:42:OK;\f // младший байт = 0 get запрос oid-префикс.25.0.0.oid-суффикс get ответ \0||:42:OK;\f // старший байт = 0 get запрос oid-префикс.30.0.0.oid-суффикс get ответ \0||:42:OK;\f // дополнительный байт = 0
И это ещё не всё, утилиты для сброса выполняют некоторые команды обнуления регистров, назначение которых мне пока не очень понятно. Однако сброс происходит успешно и проблему владельца сего агрегата решает.
Собирая всё вместе
Прототип утилиты чтения и записи счётчиков чернильных отходов я по-быстрому наваял на TypeScript под платформу NodeJS и выложил на гитхаб.
github.com:katyo/printer-waste-counter
В репозитории также присутствуют образцы захваченных пакетов SNMP.
Если кому-то интересно, то можно добавить поддержку других принтеров кроме Epson XP-432/XP-435. Для этого требуется захватить wireshark-ом хотя бы сетевой трафик процедуры чтения значений счётчиков какой-нибудь сторонней утилитой и желательно ещё записи, если имеется данная возможность.
И разумеется, я заведомо снимаю с себя ответственность за любые ваши действия со своими устройствами, включая рекомендованные мною как в этой статье, так и лично.
Отправить комментарий