Перейти к содержимому
Калькуляторы

Прошивка CWDM, образы SFP прошивка и образы SFP

Подскажите, кто знает, как рассчитывается контрольная сумма в прошивке SFP?

И есть-ли какой-либо материал, чтобы разобраться в структуре прошивки?

Контрольная сумма в байте 63 равна младшему октету суммы байт 0 - 62 включительно.

Контрольная сумма в байте 95 равна младшему октету суммы байт 64 - 94 включительно.

В документе SFF-8472 каждый байт расписан.

Изменено пользователем evil-man

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Всем привет.

Приобрели указанный программатор, а вот прошивок к нему под джунипер нигде не нашел.

В частности, интересует cwdm-1570.

Никто не поделится?

 

 

http://shop.nag.ru/catalog/00007.Avtomatizatsiya-i-monitoring/05629.Mikrokontrollery/08255.Prog-miniUSB

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Добрый день,

 

Аналогично - наговский программатор, пытаюсь сделать из SFP, которые cisco не читает, такие, которые она примет за compatible :)

Прочитал:

байты 0060....007F заполняются на усмотрение вендора, их и нужно записать правильно, для cisco.

 

у cisco тут записан:

1) байт идентификатора производителя (0x0062: 0x0E это Method, видел еще 0x02 для Finisar)

2) уникальный серийный номер, 0x0063 - обычный md5 от сложения

- один идентифиатора производителя (0x0E, или какой другой) +

- имени производителя (0x10 байт ) +

- серийного номера SFP (0x10 байт )+

- и cisco key для производителя (0x10 байт, всего 0x40 вендоров, при желании можно найти все 0x400 байт,

а для моих Method 0x0E это 4AF86716ED1E2F347CA13C9978AD8CA0, Finisar 0x02 - 8DDAE6A46EC9DEF6100BF185059C3DAB)

 

тоесть вендор, имя, серийник, ключ вендора:

CODE

0000: 0E 43 49 53 43 4F 2D 4D │ 45 54 48 4F 44 45 20 20 ♫CISCO-METHODE

0010: 20 30 30 30 30 30 4D 54 │ 43 31 31 33 38 30 31 53 00000MTC113801S

0020: 53 4A F8 67 16 ED 1E 2F │ 34 7C A1 3C 99 78 AD 8C SJшg■н▲/4|Ў<Tx-_

0030: A0 │

с нее и получается наш уникальный ID имени циско C45D79AB9699E37C20A0CBFBFBA23D70

3) чексумма 0x007С, обычный CRC32 от 0x0С байтов, в дамп токо пишем байты в обратном порядке,

если посчитало 0x12345678, записываем 78 56 34 12

CODE

0060: 00 00 0E C4 5D 79 AB 96 │ 99 E3 7C 20 A0 CB FB FB ♫Д]y<-Tг| Лыы

0070: A2 3D 70 00 00 00 00 00 │ 00 00 00 00

 

и продолжение:

у меня от этого значения, тоесть не от самой Hex строки, а от ее бинарного значения

0E434953434F2D4D4554484F444520202030303030304D544331313338303153534AF86716ED1E2F

347CA13C9978AD8CA0

и выходит C45D79AB9699E37C20A0CBFBFBA23D70

 

cisco key - не знаю как правильно он называется, но это тот ключ - что передается cisco каждому производителю sfp.

его можно найти путем медитации над прошивкой 3560.

 

не совсем так, нужно брать все 12 байт, но не сначала eeprom, а тот md5 что мы токошо расчитали,

ну и вначале производитель и нули вконце, тоесть

00 00 0E C4 5D 79 AB 96 99 E3 7C 20 A0 CB FB FB A2 3D 70 00 00 00 00 00 00 00 00 00

и считать от них. (обрати внимание, что расчитанный crc в eeprom записывается в обратном порядке)

 

3) чексумма 0x007С, обычный CRC32 от 0x0С байтов, в дамп токо пишем байты в обратном порядке

на самом деле должно быть написано

Цитата

3) чексумма 0x007С, обычный CRC32 от 0x1С байтов, в дамп токо пишем байты в обратном порядке

Мелочь, но голову поломали :)

 

У меня SFP: 10/100/1000BaseT. Прочитал прошивку с рабочего SFP:

...
60:30303032303230323032303030323032
70:30323035333436353032443534323032
...

 

1) итак, байт производителя у меня (по адресу 0x0062) это 0x0030.

 

2) для md5 нужно:

a) байт идентификатора производителя: 30

b) имя производителя, пусть будет как в примере: 43 49 53 43 4F 2D 4D 45 54 48 4F 44 45 20 20 20, т.е. - CISCO-METHODE

c) серийный номер SFP, пусть будет 32 30 31 33 30 38 32 33 31 33 34 32 30 30 30 31, т.е. - 2013082313420001

в) cisco key производителя, пусть будет как в примере: 4A F8 67 16 ED 1E 2F 34 7C A1 3C 99 78 AD 8C A0

 

итого 30434953434F2D4D4554484F4445202020323031333038323331333432303030314AF86716ED1E2F347CA13C9978AD8CA0

md5 будет 2e2a7f0ba193902ee1dd9c529e2f27ca, вписываем это значение (заменяя текущие значения) начиная с позиции 0x063 и получаем:

60: 3030302E2A7F0BA193902EE1DD9C529E
70: 2F27CA35333436353032443534323032

 

3) нужно crc32 всех новых 0x1C байтов начиная с 0x060 (включительно) и до 0x07B (включительно), т.е. строка: 3030302E2A7F0BA193902EE1DD9C529E2F27CA353334363530324435

crc32 будет: 0x9cfbe420, меняем байты наоборот и получаем: 20e4fb9c, вписываем значение по адресу 0x07C (затирая текущие значения) и получаем:

60: 3030302E2A7F0BA193902EE1DD9C529E
70: 2F27CA35333436353032443520E4FB9C

 

Все? Сохраняю файл, пытаюсь открыть IcProg... получаю Error: "Checksum error on line 0020h. The checksum read is 26h but it should be 95h"

Что это такое? Я вообще не редактировал эту строку! И на ней нет hex значения 26! Бррр... и откуда IcProg знает что в этом файле crc должен лежать по этому адресу? Ведь для него это просто файл с данными. И crc чего именно он там ищет?

Изменено пользователем survivor

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Почитал ftp://ftp.seagate.com/sff/SFF-8472.PDF там нет никакого crc для всего файла. Только те, о которых упомянул evil-man:

Контрольная сумма в байте 63 равна младшему октету суммы байт 0 - 62 включительно.

Контрольная сумма в байте 95 равна младшему октету суммы байт 64 - 94 включительно.

но я то те байты не трогал.

 

Получается что IcProg не принимает файл, в котором в любом месте что-то изменено. Но как он об этом узнает - crc то нету!

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Похоже на баг... если исправить первый байт 0x3A на 0x31 (не спрашивайте как я до этого дошел) то все изменения IcProg принимаются на ура... Версия 1.06C (последняя). Попробовал 1.05 - то же самое.

Но первый байт мне нужно оставить неизмененным, вообщем ничего не понимаю. Если у кого получалось - помогите плз, чего не так делаю?

Изменено пользователем survivor

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

я делал еще в начале топика, и больше к этой тем не возвращался.

писал сначала chipprog+/beeprog, через ISP - но как-то напряжно выходило,

в итоге - собрал на LPT - намного удобнее. счас бы USB канешно.

 

может IcProg или ты - пытаешься засунуть BIN вместо HEX, или наоборот.

 

я всегда писал только бинарники, HEX файлы - просто так не пишутся,

они должны быть в интел-моторола-етс формате, и там действительно - есть чексума.

но это чексумма, HEX файла, в флешки - она не попадает.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

carver Спасибо за ответ :)

Я читаю IcProg'ом прошивку с SFP (так что формат должен быть верный), затем winhex'ом правлю какой-нибудь один байт и... все - IcProg больше этот файл не открывает. Причем если первый байт (двоеточие) изменить - все ok, IcProg принимает любые изменения. Программатор у меня наговский.

Застрял на вот такой фигне.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

может твое двоеточие - это как-раз HEX формат, не имеючий никакого отношения к SFP.

там свои чексуммы, которые нужно пересчитывать.

 

формат файла с двоеточиями есть тут http://ru.wikipedia.org/wiki/Intel_HEX

 

попробуй читать в обычный BIN, там чистый дамп с SFP, без HEX-мусора.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

carver спасибо большое! Сохранил из IcProg как bin, редактирую winhex'ом - IcProg принимает любые изменения. Про hex формат не знал, думал что имеется ввиду просто отображение бинарных данных ввиде их hex значений, а оно вот как оказывается...

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Теперь немного по существу :) первая прошивка дала следующее: cisco показывает SFP как unknown, show idprom вообще ничего не читает...

У меня в бине прошивка с рабочего SFP выглядит так:

00:0304070000000800000000010D000000
10:000064004F454D202020202020202020
20:20202020002020205346502D54202020
30:202020202020202031312E30000000F3
40:000000004E3130393038313332202020
50:2020202030393132323620200000003A
60:000011E899C6EE8ADB500573157A00D3
70:B27C2600000000000000000037D3F236

соответственно, код производителя - 0x011, по видимому его нужно поменять на что-то знакомое циске? тот же 0x0e?

насчет других значений (имя производителя, SFP serial, cisco key производителя) - пишется же в прошивку только их md5 хеш, откуда циска узнает какие значения я там использовал (cisco key или имя еще допустим она может узнать по коду производителя, который идет в открытом виде, но серийник?!) чтобы самой составить хеш и сравнить с тем что я прошил? Значит в прошивку нужно в открытом виде куда-то вписать и эти значения? Посмотрел: ftp://ftp.seagate.com/sff/SFF-8472.PDF

 

20-35  SFP vendor name (ASCII)
27-39  SFP vendor IEEE company ID
40-55  Part number provided by SFP vendor (ASCII)

Это?

Изменено пользователем survivor

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

я бы взял несколько дампов с этого топика,

у которых 0x0062 байт 0xE или 0x2, взял соответствующий ключ,

и пересчитал подпись, шоб вышла такая-же как в дампе.

 

для новых - будет тогда проще считать.

 

но, это только подпись, на каких-то SFP и прошивках - ее достаточно,

но если чайна-SFP работает не по стандарту, или индусы не дописаль ту часть стандарта в прошивку,

то вполне возможно что некоторым модулям - подись не поможет.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Ok, логично, взял дамп (работающий, проверил) с methode вендором. В принципе единственное что мне нужно - это поменять серийник.

Еще до того как править хеш и crc в диапазоне 0x063-0x7f я правлю серийник по адресу 68-83 (адреса - decimal как я понимаю). Потом нужно по адресу 95 (decimal) вписать 1 байт (low order 8 bit) crc, полученного от значений по адресам 64-94 (decimal). Вот неизмененный дамп:

64: 000000004D3832333534352020202020
80: 20202020303331303137303100000035

т.е. crc = 35 от строки 000000004D3832333534352020202020202020203033313031373031000000

Как они это получили?

 

http://crc32-checksum.waraxe.us/ дает 0x9B2DDEFA

http://www.codenet.ru/services/crc32/ дает 0x9b2ddefa

http://www.lammertbies.nl/comm/info/crc-calculation.html дает для hex вводных данных

1 byte checksum 28 
CRC-16 0x970F 
CRC-16 (Modbus) 0x3C0E 
CRC-16 (Sick) 0x7BA6 
CRC-CCITT (XModem) 0xA72B 
CRC-CCITT (0xFFFF) 0x6EF0 
CRC-CCITT (0x1D0F) 0x71F1 
CRC-CCITT (Kermit) 0x6C80 
CRC-DNP 0x5ED7 
CRC-32 0x9B2DDEFA 

и для ASCII строки:

1 byte checksum 28 
CRC-16 0x970F 
CRC-16 (Modbus) 0x3C0E 
CRC-16 (Sick) 0x7BA6 
CRC-CCITT (XModem) 0xA72B 
CRC-CCITT (0xFFFF) 0x6EF0 
CRC-CCITT (0x1D0F) 0x71F1 
CRC-CCITT (Kermit) 0x6C80 
CRC-DNP 0x5ED7 
CRC-32 0x9B2DDEFA 

 

 

35 не получается!

Изменено пользователем survivor

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Вот картинка из IC-Prog. На синем фоне у меня информация о серийнике, жёлтым подчёркнут сам серийник, в красной рамочке - контрольная сумма серийника. Контрольную сумму можно посчитать виндовсовским калькулятором, выставить HEX и 1 байт. Но можно вспомнить математику :) - от перемены мест слагаемых сумма не меняется. То есть, в данном случае серийник ABLBDS00D. Такая же контрольная сумма будет у ABLBDS0D0 и ABLBDSD00. Можно поменять местами значения 30 и 44 (подчёркнутые зелёным). На калькуляторе пересчитывать лучше вдвоём, ибо можно пропустить какой-то байт или посчитать его два раза.

 

600x6001379318747599.png

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Ищется дамп SFP+ для Extreme, который не будет по sh ports conf писать, что воткнут Unsupported optic module. (знак !)

 

UPD. Разобрался с прошивкой, чтобы Extreme считал модуль родным.

Изменено пользователем nashvill

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

HP J4858C

HP J4858C.txt

Изменено пользователем BlackSnow

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Можете скинуть десяток прошивок с разными серийниками для GBIC для циски?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Коллеги, поделитесь дампами HP J4859C, а лучше расскажите способ самому расчитать байты верификации 124-127, пожалуйста.

 

Все, помог доблестный саппорт SNR, спасибо ему за это.

Изменено пользователем almuerto

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Добрый день! нужны прошивки для HP X112 100M SFP LC BX-D Transceiver (J9099B)

есть прошивки для 4859С и для Cisco 30-1299-01

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Добрый день.

Перечитал всю сетку.

Есть два таких модуля Finisar

http://www.sanspot.com/v/vspfiles/pdfs/Finisar/FTLX1471D3BCL.pdf

На программаторе при изменении любого байта и пересчете чем сумм по нужным местам (это делает сам программатор) записать обратно не возможно.

Но если записать в него же его же прошивку пишет, что все нормально.

Дампы прикладываю.

 

Извините если мало информации в вопросе. Могу раскурочить сфотографировать.

 

a93ee3707f89.jpg

 

Надпись на EEPROM 532WP B742 (тут или B или цифра 8, не могу различить)

Даташита этой микросхемы найти не могу(((

Но по всей видимости, исходя из даташитов других модулей, защита висит на седьмой ноге.

Я вот подумал, а не можно ли просто порезать дорожку указанную на рисунке стрелкой?

Вроде как нога должна оказаться в воздухе.

AH20B1H.txt

PD13N65.txt

Изменено пользователем SpasiboMne

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Нет ли у кого-нибудь того, что продается как HP 453151-B21 (пара модулей)?

В quickspecs из гиговых написана совместимость только с этой парой, да с парой медных, а отдельных модулей 1000base-SX, увы, не указано.

В сети не могу найти, эквивалентен ли этот набор двум модулям HP J4858C.

 

Не могли бы вы содержимое idprom именно такого модуля (453151-B21) выложить сюда или скинуть в ЛС?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Поставил себе в ДЦ свитч HP procurve, но отказался принимать наговские модули, ну чтож, заказл наговский программатор, пришел, считал, а что делать дальше? Да ктож его знает)

Выпросил у ***** еепром для хпшного модуля AGJ00JBH0P.bin, вшил, работает, круто, но в чем прикол? Заинтересовало, наткнулся на один блог, там был расписан еепром на русском.

Заинтересовало, стал рыть дальше, нашел SFF-8472, почитал, еще больше заинтересовало, и таким образом накатал небольшой сайтец, который хранит базу, можно смотреть еепромы из базы (базу собрал на форуме нага), можно заливать свою, он распарсит, можно какое-нибудь значение исправить и слить уже сгенерированный новый еепром.

 

Ну сообствено начал эксперементировать с модулем, делая минимум изменений и смотреть на реакцию, в итоге пришел к тому что хп смотрит на 3 значения! Это:

Vendor SN:

Data code:

Vendor Specific:

Слил прошивку с наговского модуля и оптициноского, поменял эти 3 значения, залил назад, вставил в хпшку, вуаля, распазнало) удивительно, решил поискать закономерность

Вот выкладываю файлик http://sfpdb.freetime.su/hp_algoritm'>http://sfpdb.freetime.su/hp_algoritm , это анализ нескольких хпшных еепромов, вдруг у кого-нибудь появяться мысли по генерации этого вендор специфик.

 

Идея вообщем в след. Заливаешь еепром от своего модуля, жмешь "работать на хп", он меняет значения и полетели, сейчас уже могу реализовать это, заменяя 3 значения, но хотелось бы узнать алгоритм и оставляя дату и сн прошивки, а генерировать только вендор специфик. Кто алгоритм распознает!?!?

 

В чем суть, если можно залить прошивку от хпшного модуля? А я считаю в том что неправильно заливать с новыми опциями которые не поддерживает модуль, например раздел диагностики, опции включены - а модуль не умеет - не хорошо както:)

 

Ну и сам сайт получился такой http://sfpdb.freetime.su/

 

Заливая свои прошивки, они остаются в базе, и отображаются на главной странице.

 

P.S: Так же хотелось бы услышать предложения по улучшению, чтобы собрать хорошую базу для анализа алгоритмов.

 

Vendor specific block

Его редактировать пока что нельзя, но в будущем добавлю hex редактор на js, что даст возможность редактировать эти поля, но стоит ли оно того? если будут алгоритмы, достаочно будет залить свою прошивку. и скачать под нужный вендер...

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

серийник + дата = 4м последним байтам от 128 в минусовую сторону.

это как раз как кодирует HP.

по факту очень схоже с CRC32 тем не менее есть еще что-то.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Добрый день, подскажите пожалуйста, есть коммутатор HP < JE007A> V1910-24G-PoE, какой неоригинальный модуль SFP для него можно приобрести? Нужен гигабит и под одномодовое волокно. Нашёл на сайте такой - SNR-SFP-W35-20-DDM. Где можно взять прошивку под этот модуль? Может где то уже продают прошитые под конкретную модель?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

вдруг у кого-нибудь появяться мысли по генерации этого вендор специфик.

Тут была мысль:

алгоритм воспроизводим, но шото длинный,

Эх, проверить бы, работают ли CISCO-совместимые модули в HP ...

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Добрый день, подскажите пожалуйста, есть коммутатор HP < JE007A> V1910-24G-PoE, какой неоригинальный модуль SFP для него можно приобрести? Нужен гигабит и под одномодовое волокно. Нашёл на сайте такой - SNR-SFP-W35-20-DDM. Где можно взять прошивку под этот модуль? Может где то уже продают прошитые под конкретную модель?

У меня стоит такое, без POE, это копипаст 3ком свитча, ему вообще похер какие сфп модули стоят!

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Гость
Ответить в тему...

×   Вставлено в виде отформатированного текста.   Вставить в виде обычного текста

  Разрешено не более 75 смайлов.

×   Ваша ссылка была автоматически встроена.   Отобразить как ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставить изображения напрямую. Загрузите или вставьте изображения по ссылке.