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

[Запрос Feather] Игнорировать некорректный DHCPv6 DUID

[Запрос Feather] Игнорировать некорректный DHCPv6 DUID, RouterOS

mantouboji

Guest

10.09.2023 07:42:00

Где-то на материковом Китае один провайдер присылает клиентам необычный ответ DHCPv6 DUID, из-за чего устройство на RouterOS не может получить корректный IPv6-префикс, тогда как OpenWRT и другие DHCPv6-клиенты справляются. Возможно, Mikrotik стоит добавить новую опцию для игнорирования таких плохих DUID, чтобы получать префикс. Спасибо. https://www.77bx.com/358.html

next365 Guest	#2 0 19.06.2024 10:38:00 Пожалуйста, добавьте эту функцию и проигнорируйте этот duid, чтобы мы могли продолжать покупать Mikrotik, или просто купим чертов Huawei ZTE.

next365

Guest

21.12.2023 05:15:00

299 2023-12-16 13:49:37 память dhcp, отладка, пакет отправлен pppoe-out1 -> ff02::1:2%17
300 2023-12-16 13:49:37 память dhcp, отладка, тип пакета: solicit
301 2023-12-16 13:49:37 память dhcp, отладка, transaction-id пакета: d38fde
302 2023-12-16 13:49:37 память dhcp, отладка, пакет -> clientid: 00030001 c4ad3450 1746
303 2023-12-16 13:49:37 память dhcp, отладка, пакет -> elapsed_time: 1
304 2023-12-16 13:49:37 память dhcp, отладка, пакет -> rapid_commit: [пусто]
305 2023-12-16 13:49:37 память dhcp, отладка, пакет -> ia_pd:
306 2023-12-16 13:49:37 память dhcp, отладка, пакет t1: 1800
307 2023-12-16 13:49:37 память dhcp, отладка, пакет t2: 2880
308 2023-12-16 13:49:37 память dhcp, отладка, пакет id: 0x11
309 2023-12-16 13:49:37 память dhcp, отладка, пакет получен от клиента: pppoe-out1 fe80::d6c1:c8ff:fe9a:7700 -> fe80::c6ad:34b1:fc50:1746
310 2023-12-16 13:49:37 память dhcp, отладка, тип пакета: reply
311 2023-12-16 13:49:37 память dhcp, отладка, transaction-id пакета: d38fde
312 2023-12-16 13:49:37 память dhcp, отладка, пакет -> clientid: 00030001 c4ad3450 1746
313 2023-12-16 13:49:37 память dhcp, отладка, пакет -> serverid: 6660
314 2023-12-16 13:49:37 память dhcp, отладка, пакет -> rapid_commit: [пусто]
315 2023-12-16 13:49:37 память dhcp, отладка, пакет -> dns_servers:
316 2023-12-16 13:49:37 память dhcp, отладка, пакет 240e:56:4000:8000::69
317 2023-12-16 13:49:37 память dhcp, отладка, пакет 240e:56:4000::218
318 2023-12-16 13:49:37 память dhcp, отладка, пакет -> ia_pd:
319 2023-12-16 13:49:37 память dhcp, отладка, пакет t1: 43200
320 2023-12-16 13:49:37 память dhcp, отладка, пакет t2: 69120
321 2023-12-16 13:49:37 память dhcp, отладка, пакет id: 0x11
322 2023-12-16 13:49:37 память dhcp, отладка, пакет -> статус: 0 - успех
323 2023-12-16 13:49:37 память dhcp, отладка, пакет сообщение: SUCCESS
324 2023-12-16 13:49:37 память dhcp, отладка, пакет -> ia_prefix:
325 2023-12-16 13:49:37 память dhcp, отладка, пакет префикс: 240e:39a:edb:9b60::/60
326 2023-12-16 13:49:37 память dhcp, отладка, пакет время действия: 86400
327 2023-12-16 13:49:37 память dhcp, отладка, пакет время предпочтения: 86400
328 2023-12-16 13:49:37 память dhcp, отладка плохой server DUID
329 2023-12-16 13:49:39 память dhcp, отладка повторная отправка.. Такая же проблема будет масштабно повторяться, когда начнется постепенный переход на новый vBRAS. Эту проблему стоит как можно быстрее игнорировать в ros, если только она не нужна для конкретного рынка, иначе эти устройства станут бесполезными. Active AC Name SC-CD-EY4F-vBRAS.C-1.NMAN.V6000

strods

Guest

03.05.2024 06:49:00

Как указано в RFC, DUID должен быть длиной 2 октета и сопровождаться как минимум одним октетом с самим идентификатором. То есть минимальная длина ОБЯЗАТЕЛЬНО должна быть 2+1=3 октета: https://datatracker.ietf.org/doc/html/rfc8415#section-11.1

Содержание DUID
DUID состоит из 2-октетного кода типа в сетевом порядке байтов, за которым следует переменное количество октетов, составляющих сам идентификатор. Длина DUID (без учёта кода типа) должна быть не менее 1 октета и не более 128 октетов.

Ссылка на RFC, упомянутая в этой теме («Клиенты и серверы НЕ ДОЛЖНЫ ограничивать DUID только типами, определёнными в этом документе, поскольку в будущем могут быть добавлены дополнительные типы DUID»), говорит о том, что вы НЕ ДОЛЖНЫ ограничивать DUID только их «типами».

Проблема здесь не в «типе». Проблема в том, что за типом не следует «переменное количество октетов, составляющих сам идентификатор». Длина DUID (без кода типа) должна быть минимум 1 октет и максимум 128 октетов. К сожалению, мы не видим, что где-то действует нарушение, ведь за типом нет идентификатора длиной минимум 1 октет, а проблема именно в сервере, а не в клиенте.

infabo

Guest

03.05.2024 09:36:00

https://datatracker.ietf.org/doc/html/rfc8415#section-11 также говорит следующее: Клиенты и серверы ДОЛЖНЫ рассматривать DUID как непрозрачные значения и ДОЛЖНЫ только сравнивать DUID на равенство. Клиенты и серверы НЕ ДОЛЖНЫ каким-либо другим образом интерпретировать DUID. Так почему же ROS вообще «проверяет» DUID? Фраза «ДОЛЖНЫ рассматривать DUID как непрозрачное значение» кажется очень однозначной.

mkx

Guest

03.05.2024 10:52:00

Как объяснил @strods: DUID, который отправляет провайдер @OP, — это не значение DUID, а только тип DUID. Так что, строго говоря, ROS не может воспринимать «DUID как непрозрачное ЗНАЧЕНИЕ», потому что в этом случае значение отсутствует (NULL). Да, наверное, никому бы не помешало, если бы ROS принимала NULL как значение DUID... но поскольку ROS работает правильно (ожидая хотя бы один байт значения DUID), это на самом деле не баг в ROS. Поэтому заголовок этой темы (я прочитал его как «запрос на функцию») очень точно отражает суть. Теперь остаётся только ждать и надеяться, что MT реализует эту функцию.

Kentzo Guest	#7 0 03.05.2024 17:00:00 Я бы всё равно хотел увидеть двоичный дамп проблемного пакета. Возможно, что парсер или проверка в RouterOS сломаны каким-то другим образом.

Lilarcor Guest	#8 0 11.06.2024 07:07:00 Это просто бесит. Пожалуйста, добавьте опцию игнорирования.

capricornxl Guest	#9 0 26.06.2024 14:48:00 Когда я меняю параметры DHCP, чтобы установить clientid, смотрю на строки в конце лога... Если вы разрешаете изменять clientid через опции, зачем тогда отвергать такие изменения?

wastrel

Guest

#10

31.08.2024 16:16:00

Сейчас мое устройство Mikrotik не может получить правильный IPv6 префикс-адрес в Китае. Я пытался найти решение в интернете, но так и не нашел, пока не наткнулся на этот форум. Только теперь я понял причину этой проблемы. Нам действительно нужен IPv6 для доступа в интернет. Как вы знаете, в Китае сложно заставить провайдера что-то изменить. Поэтому мы надеемся, что Mikrotik сможет адаптироваться к этой ошибке — это очень важно для китайских пользователей. Если Mikrotik не планирует поддерживать это, нам придется перейти на OpenWrt или другие совместимые устройства. У нас просто нет другого выхода. Спасибо.

capricornxl

Guest

#11

22.09.2024 08:27:00

Сдавайтесь, уважаемый ROUTEROS ни в коем случае не должен быть совместим с этими проблемами, вся вина лежит на вас, а не на ROUTEROS. Эта проблема была заявлена почти два года назад, но ROUTEROS до сих пор никак не отреагировал.

next365 Guest	#12 0 25.10.2024 03:45:00 Уже октябрь 2024 года, а эта проблема всё ещё не решена — это просто смешно, пора уже выбирать другие варианты.

Читают тему

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