Какие контрольные суммы EEPROM нужно пересчитать после редактирования имени вендора и PN в образе SFP
Работа на стенде: перекодирую небольшую партию модулей SFP+, чтобы они несли строку вендора и партномер, которые ожидает оборудование заказчика. Само редактирование в hex-редакторе тривиально, запись проходит, обратное чтение совпадает побайтово с тем, что я записал - а хост всё равно выбрасывает модуль.
- обычные модули SFP+, страница A0 отредактирована вручную
- программатор на базе CH341 с инструментом, который шёл в комплекте
- отредактированные поля: имя вендора и партномер вендора, больше ничего не трогал
- нетронутый дамп, записанный обратно в тот же модуль, работает нормально, так что сам путь записи не проблема
Что я сравнил после редактирования:
edited fields : vendor name, vendor PN
byte 63 CC_BASE : identical to the original image
byte 95 CC_EXT : identical to the original image
host : rejects the module, checksum errorТо есть байты сумм явно не сдвинулись, когда сдвинулась полезная нагрузка. Прежде чем писать собственный инструмент под это: какие диапазоны байтов реально покрывают эти две суммы, это простые аддитивные суммы или что-то в духе CRC, и есть ли поддерживаемая утилита, которая их пересчитывает, чтобы не считать вручную на каждом модуле?
Show original (English)
Also available in: English
العربية
Deutsch
Español
Français
हिन्दी
Bahasa Indonesia
Italiano
日本語
한국어
Nederlands
Polski
Português
Русский
Türkçe
Tiếng Việt
简体中文
Comments 4
Ваш программатор делает то, что обычно делают инструменты на базе CH341, то есть ничего. Они записывают байты, которые вы им передаёте, и никогда не трогают поля контрольных сумм. Фирменные программаторы пересчитывают их при записи, поэтому те, кто пользуется только ими, никогда с этим не сталкиваются и убеждены, что вся тема выдумана.
Прежде чем писать инструмент, стоит выяснить две вещи. Во-первых, что читало образ обратно после записи - тот же инструмент, который писал, или что-то независимое? Читалка, отдающая вам собственный кэш, с радостью покажет байт, который так и не попал в чип. Во-вторых, вы сами посчитали сумму по байтам 0-62 отредактированного образа и сравнили её с байтом 63, или только сравнили байт 63 с оригинальным дампом? "Не изменился" и "правильный" - не один и тот же тест, а по вашим записям видно только первое.
Также стоит назвать хост, который отклоняет модуль. Одни читают поля идентификации и ничего не проверяют, другие валидируют строго и сбрасывают модуль в момент, когда сумма не сходится. Один и тот же образ - разный вердикт.
Их две, и это тупые 8-битные суммы, никакого CRC нигде нет.
Имя вендора и партномер вендора оба лежат в базовой области, так что ваше редактирование сделало недействительным CC_BASE, а CC_EXT остался законно верным. Редактирование серийного номера и даты выпуска, наоборот, попадает в расширенный диапазон, и тогда устаревает байт 95. Пересчёт любого из них - это две строчки по буферу: просуммировать диапазон, замаскировать 0xFF, записать в байт суммы.
Если не хотите писать вручную, есть инструменты. py-sfp-eeprom собирает и проверяет образы EEPROM из Python (
python3 -m sfp_eeprom), аsfppiработает на Raspberry Pi, проверяет суммы и предлагает их исправить. Любой из них - более здоровая привычка, чем hex-редактор плюс арифметика в уме, потому что отказ происходит тихо: модуль читается ровно так, как вы записали, и жалуется только хост.Правильно посчитать две суммы MSA необходимо, но, в зависимости от того, в чей порт вы вставляете, недостаточно.
Cisco - хорошо знакомый пример: проверка идентичности - это не только строки. Кто-то давно выяснил, что значение, которое несёт модуль, закодированный Cisco, воспроизводится ничем более экзотичным, чем
xxd -r -p | md5sum, скормленным байту кода вендора, а затем байтам имени. В этих дампах код и имя привязаны друг к другу - Finisar сидит за 02, Methode за 0E. Пусть эти два разойдутся, и Catalyst 2960X снова выплюнет модуль, независимо от команд разблокировки.Обычно именно поэтому дамп, скопированный с работающего модуля, перестаёт работать, как только кто-то вставил в него другую строку вендора. Суммы в порядке, а идентичность больше не самосогласована.
Небольшая поправка к формулировке "исправь две суммы и готово": это верно для полей MSA, но не для представления каждого вендора о валидном образе.
HP - постоянный контрпример. Отредактируйте серийный номер в образе J4858B, байты 68-83, и байты 124-127 в A0 тоже изменятся - фирменная контрольная сумма, сидящая за байтами MSA CC_BASE и CC_EXT. Это обсуждалось долго, и алгоритм так никто и не опубликовал; люди подтвердили, что эти байты важны, и тема на этом закончилась. Та же история сообщалась про J4859C и J9150A. Более позднее оборудование HP и Aruba перешло на схему запрос-ответ (HPIDv2), которую в EEPROM подделать вообще нельзя.
Так что прежде чем вкладываться в инструменты, выясните, что проверяет целевой хост: две аддитивные суммы для обычного хоста, внутренне согласованную идентичность для Catalyst, а на некоторых компонентах HP - недокументированное поле, которое вы не воспроизведёте.