+7 495 320-55-52
- Назад
- Телефоны
- +7 495 320-55-52
- Заказать звонок
info@mikrotik.moscow
г. Москва, ул. Бакунинская, 84
Пн-Пт: 09-00 до 18-00
Сб-Вс: выходной

Информация о SFP не отображается / контрольная сумма EEPROM неверна.

Информация о SFP не отображается / контрольная сумма EEPROM неверна., RouterOS

nekitoss

Guest

29.10.2023 20:48:00

Только что купил RB5009 вместо ISP ONU+hapAc 2. Модуль — C-Data FD511GX-RM0 (почти такой же, как VSOL V2801F). Роутер был с прошивкой v7.8, всё работало на авто-согласовании, но когда попытался переключить на принудительный режим (1G, full-duplex) — перестало работать, IP не выдавался, и доступ к веб-интерфейсу/telnet SFP отсутствовал. При обновлении роутера до последней стабильной версии 7.11.2 авто-согласование продолжало не работать, а принудительный режим тоже не запускался. Даже ручная настройка IP не помогла. Мой ISP использует MAC-адрес/SN для аутентификации и выдачи IP/ethernet (если я правильно помню, у них FTTH). Я написал тикет в поддержку mikrotik — они остановились на том, что в консоли мой модуль показывает «eeprom-checksum: bad» и настояли, что, возможно, модуль неисправен, попросили попробовать другой. Мне это показалось странным — спросил у провайдера, и они сказали, что ничего не меняли и не прошивали, «он родной».

Используя это, это (много информации внутри) и это, я изучил основы работы с модулем и обновил его почти до последней версии V1.9.0-201104 (вначале стояла самая старая — V1.9.0-191015) (Последняя V1.9.0-220425 поддерживает 2.5G, но я немного боялся необходимости настраивать LAN_SDS_MODE — чтобы не потерять связь с модулем). После этого модуль заработал в принудительном режиме! Таким образом, я смог обновить mikrotik до 7.11.2 — авто-согласование по-прежнему не работало, но модуль хотя бы работал на принудительном 1G.

Я настроил маршрут до sfp-sfpplus1, чтобы иметь доступ к вэб-интерфейсу и telnet модуля даже при работе в интернете. Но после всего этого у меня всё ещё остаётся eeprom-checksum: bad и нет информации на sfp-странице:

/interface/ethernet monitor sfp-sfpplus1
name: sfp-sfpplus1
status: link-ok
rate: 1Gbps
full-duplex: yes
tx-flow-control: no
rx-flow-control: no
sfp-module-present: yes
sfp-rx-loss: no
sfp-tx-fault: no
sfp-type: SFP/SFP+/SFP28
eeprom-checksum: bad
eeprom:
0000: 03 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........ ........
0010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........ ........
0020: 20 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ....... ........
0030: 52 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 R....... ........
0040: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........ ........
0050: 31 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 1....... ........
0060: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........ ........

Отдельно хочу отметить, что до обновления, когда я был на ROS v7.8, в разделе eeprom показывалось больше информации:

/interface/ethernet monitor sfp-sfpplus1
name: sfp-sfpplus1
status: link-ok
rate: 1Gbps
full-duplex: yes
tx-flow-control: no
rx-flow-control: no
sfp-module-present: yes
sfp-rx-loss: no
sfp-tx-fault: no
eeprom-checksum: bad
eeprom:
0000: 03 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........ ........
0010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........ ........
0020: 20 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ....... ........
0030: 52 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 R....... ........
0040: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........ ........
0050: 31 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 1....... ........
0060: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........ ........
0080: 5a 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Z....... ........
0090: 92 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........ ........
00a0: 06 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........ ........
00b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........ ........
00d0: 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........ ........
00e0: 38 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 8....... ........
00f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........ ........

(Не знаю, связано ли это с обновлением ROS, которое показывает меньше, или с обновлением, которое меньше читает).

Также я нашёл здесь интересную деталь: эти чипы Realtek имеют сломанный эмулятор EEPROM, который при чтении N байт возвращает только первый байт данных EEPROM, а остальные N-1 байт заполняет нулями. (Как известно — ONU SFP на самом деле это linux-машинка в очень маленьком форм-факторе…)

Мои вопросы: Кто-нибудь работал с такими модулями — у всех ли на mikrotik «bad checksum», или только у меня так? Кто-нибудь решал проблему с плохой контрольной суммой, как пользователь в этой теме? Стоит ли пробовать? Есть ли у всех в mikrotik на вкладке sfp мало информации? Или это только у меня? Или это последствия плохой контрольной суммы? Или плохая контрольная сумма — признак ошибки чтения модуля? Буду благодарен за любые советы, идеи, рекомендации или вопросы!

nekitoss

Guest

19.11.2023 18:24:00

Можешь пояснить свой вопрос? Сейчас у меня стоит стабильная версия 7.12. Что именно хочешь, чтобы я проверил? Ты имеешь в виду работу модуля после перезагрузки роутера? Мне не удавалось подключиться к нему по «внешнему» адресу микротика (тому, который назначает ISP на SFP). Чтобы получить доступ, нужно сначала знать, на каком IP-адресе твой SFP-модуль «ожидает». В моём случае я знаю (из репозитория на GitHub и это видно в настройках модуля после входа), что это будет ровно 192.168.1.1 (не через DHCP — просто модуль сам ставит себе этот статический адрес). Внутренняя домашняя сеть у меня использует стандартную сеть 192.168.88.0/24. Поэтому я просто вручную выставил другой (второй(!), одновременно с тем, что получен от ISP по DHCP) IP для интерфейса SFP:

/ip address
add address=192.168.1.50 interface=sfp-sfpplus1 network=192.168.1.1

Это автоматически добавило маршрут на 192.168.1.1/32:

/ip/route/print
Flags: D - DYNAMIC; A - ACTIVE; c - CONNECT, d - DHCP
Columns: DST-ADDRESS, GATEWAY, DISTANCE
DST-ADDRESS GATEWAY DISTANCE
DAd 0.0.0.0/0 172.xxx.xxx.1 1
DAc 172.xxx.xxx.0/20 sfp-sfpplus1 0
DAc 192.168.1.1/32 sfp-sfpplus1 0
DAc 192.168.88.0/24 bridge 0

После этого я могу ввести в браузере http://192.168.1.1/ (в моём случае) и, используя стандартный логин и пароль (у меня — из гита), войти в web-интерфейс и работать через telnet с моего ПК.

smotrov Guest	#3 0 02.12.2023 22:09:00 Спасибо за подробную информацию! Наконец-то я туда добрался! Но я просто не могу найти никаких инструментов для обновления прошивки в WebUI. Текущая версия — Firmware Version V1.9.0-191015

smotrov

Guest

03.12.2023 14:23:00

Большое спасибо за подробное объяснение! Я обновил прошивку, но, похоже, теперь у меня проблемы. Перед обновлением прошивки я проверил LAN_SDS_MODE и установил его на 1 (раньше было 5):
# flash get LAN_SDS_MODE
LAN_SDS_MODE=5
# flash set LAN_SDS_MODE 1
LAN_SDS_MODE=1

После обновления прошивки я смог зайти в WebUI и Telnet. Решил вернуть LAN_SDS_MODE обратно на 5. После перезагрузки не могу подключиться к провайдеру, а также получить доступ к WebUI и Telnet (при ручной установке 2.5 Гбит/с есть какой-то Tx, но доступа к провайдеру нет). Есть ли возможность попасть в WebUI, учитывая, что он работает, но доступа к провайдеру нет?

mkx

Guest

03.12.2023 14:52:00

Помогает ли полный аппаратный сброс? Например, отключить модуль SFP и подключить его обратно примерно через минуту. То же самое с роутером: выключить его и отключить питание. После минуты включить обратно. Идея в том, что смена режима работы SFP может остаться незамеченной на другом конце SFP-соединения, из-за чего связь может пропасть. Отключение и повторное подключение заставляет заново согласовывать параметры канала.

smotrov Guest	#6 0 03.12.2023 19:04:00 Спасибо! Помогло!

nekitoss

Guest

10.12.2023 06:54:00

Что касается ROS 7.12.1, я не вижу, чтобы перезагрузка Mikrotik также перезагружала SFP — время работы SFP не меняется. В моём случае для V2801F с последней прошивкой (кажется, от Anime4000 — я её не заливал) обязательно нужно выставить LAN_SDS_MODE в 1, но это только для самой последней версии. Почему ты снова вернул значение в 1? И пробовал ли ты после этого принудительно ставить 1G? Потому что у моего SFP-модуля sds_5=2.5Gb MAC, а sds_1=1GbaseX (но у меня все принудительные варианты 1G на Mikrotik работали), и на github про возврат ничего не написано. Ещё момент, на который стоит обратить внимание — у SFP обычно две прошивки, если одна ломается. Советую проверить, какая именно у тебя сейчас стоит (возможно, после установки sds_1 обновлённая прошивка отказала, и после переустановки SFP сменился блок прошивки, но я не знаю, что именно запускает смену). И ещё: насколько я знаю, к SFP нельзя получить доступ, пока не вставлен оптический кабель. У меня после отключения питания Mikrotik однажды пришлось заново вставить SFP, чтобы он заработал — странно, но это случилось только один раз, плюс Mikrotik у меня на ИБП.

smotrov Guest	#8 0 20.12.2023 16:57:00 Так получается, что при каждом повторном подключении он перебирает два прошивки?

nekitoss Guest	#9 0 12.03.2024 11:49:00 Рад сообщить, что в новой стабильной версии Mikrotik 7.14.1 (технически в 7.14) добавили однобайтовые I2C операции чтения. Это решило проблему с «битой EEPROM». Теперь он читает мой SFP-модуль FD511GX-RM0 и показывает его данные в окне информации! Спасибо, команда Mikrotik! Я так не думаю. Верю, что переключение происходит только по команде. Или — может быть — если новая прошивка не загрузится.

Читают тему

Главная Каталог 0 Корзина 0 Избранные Кабинет 0 Сравнение Акции Контакты Услуги Бренды Отзывы Компания Лицензии Документы Реквизиты Поиск Блог Обзоры