Привет! Как можно использовать роутер Mikrotik для PXE-загрузки? Спасибо!
LordError
Guest
0
01.08.2018 05:24:00
Я сделал это, но в логах Mikrotik отображается ошибка с номером 0!
kkutzera
Guest
0
28.08.2018 19:56:00
Привет! Очень заинтересован в решении. Пытаюсь настроить PXE boot сервер. Для первоначального тестирования сделал отдельную сеть на CCR1009 с OS 6.40.8 — 4 порта в бридже к DHCP-серверу для одной LAN 192.168.0.0/24. Диапазон DHCP-аренд 192.168.0.10-50. Опции выставлены для PXE boot, но пока это не так важно, так как сначала просто хочу заставить tftp работать…
Фаервола и маршрутизации нет. Использовал CCR, чтобы отформатировать SD-карту в fat32. Через FTP скопировал файлы с другого рабочего PXE-сервера. Файлы лежат в disk1/tftpboot. (снова — пока сосредоточен именно на tftp)
Пробовал десятки вариантов синтаксиса для настройки tftp сервера. (Также использовал штатный тftp-клиент Windows и сторонний). /ip tftp add allow-rollover=yes real-filename=disk1/tftpboot/ req-filename=.*
Чтобы хоть что-то получилось, пробовал так: /ip tftp add allow-rollover=yes real-filename=disk1/tftpboot/pxelinux.0 req-filename=pxelinux.0
Иногда указываю allowed для подсети 192.168.0.0/24, иногда 0.0.0.0, чаще оставляю пустым.
Выдаёт три возможных результата: - ERROR code:0 string: permission denied! - ERROR code:1 string: file not found (обычно, когда намеренно запрашиваю несуществующий файл) - ERROR code:8 (без дополнительного текста) — возникает при загрузке NUC в этой LAN, значит DHCP работает.
Если указываю req-filename (конкретный или с подстановкой), команда tftp GET сразу падает (обычно с permission denied). Если req-filename не указывать, команда GET просто виснет, пока не истекут таймауты или попытки.
В итоге мне нужен параметр req-filename пустой или с маской, а real-filename, который укажет папку disk1/tftpboot как корень TFTP. Это не должно быть сложно.
Кто-нибудь уже добивался успеха с этим? Спасибо, Kevin.
pe1chl
Guest
0
29.08.2018 09:38:00
Ну, я считаю, что пробовать — это смело. Удачи! У меня есть небольшой опыт с настройкой PXE-сервера для установки Windows по сети, начиная с загрузки через PXE (далее — диалог с pxelinux, пользователь выбирает и вводит необходимые параметры, в итоге запускается установка). Всё это без использования инструментов Microsoft, которые работают только на Windows Server (а у нас его нет). Мне удалось всё настроить (на Linux-сервере), но там столько мелких нюансов и хитростей, что я даже не представляю, как это сделать на RouterOS… Когда речь заходит об установке Windows, мне ещё интересно, как ты реализуешь Boot Information Negotiation Layer? (я для этого использую программу на Python под названием binlsrv2.py, но как сделать это на RouterOS — понятия не имею). Простое решение: сделать это на Raspberry Pi.
vrgpy
Guest
0
19.06.2023 19:00:00
Все еще не работает в ROS 7.10. Ошибка та же — «доступ запрещен!», в логе это выглядит так: ERROR code:0 string:permission denied! Если увеличить уровень логирования до DEBUG, появляется дополнительная строка перед этим: requested file (binary): pxeboot access: denied. Странно, ведь в роутере никаких ограничений на доступ нет. Если использовать другой внешний TFTP-сервер, то проблем с получением файла загрузки нет, но это ДОЛЖНО работать на ROS.
vrgpy
Guest
0
01.07.2023 20:30:00
Я попытался убрать параметр с IP-адресом, так как это как ACL, но теперь ошибка такая: Error 8 (без дополнительной информации).
wiseroute
Guest
0
02.07.2023 01:22:00
Объяснение кода ошибки tftp: Надеюсь, это поможет.
Всем привет! Хочу поделиться тем, что мне показалось необходимым для того, чтобы заставить TFTP-сеть загрузки нормально работать для тех, кто сталкивается с трудностями. Надеюсь, это поможет.
Для начала: я использую сервер с Proxmox 8.0.4. Я настроил LXC-контейнер с Docker и образом netboot.xyz, чтобы создать TFTP-сервер. После этого могу настроить виртуальную машину для сетевой загрузки. Работает также хорошо и для обычного железного клиента.
Для справки про netboot.xyz:
Linuxserver.io
Конфигурация RouterOS:
Как отметил @jonnes86, нужно задать некоторые DHCP-опции. Обратите внимание, что нужно быть точным в формате значений, иначе RouterOS выбросит ошибку с сообщением "... Unknown data type". Обратите внимание на двойные кавычки вокруг строки в одинарных кавычках.
Далее вы настраиваете Option Set, чтобы включить обе определённые опции.
После этого требуется обновить один, несколько или все сети, чтобы включить Next Server, указывающий на IP вашего PXE-сервера, и выбрать созданный DHCP Option Set. Альтернативно, можно не использовать Option Set, а выбрать сами DHCP-опции.
Я не понимаю, почему необходимо указывать Next Server, если он уже задан в Option Set, и если вы задали DHCP Option Set (или DHCP Options), то логично, что система должна сама понимать, что сеть настроена на TFTP-сервер, но да ладно.
Похоже, у меня похожая проблема. Мой роутер настроен так, как описано здесь, но при этом появляется сообщение: Start PXE over IPv4. Station IO address is 172.16.0.9 Server IP address is 172.16.0.13 NBP filename is netboot.xyz.kpxe ← тут добавляется буква «y» с умлаутом, которую я не могу воспроизвести (см. скриншот)… почему??? NBP filesize is 0 Bytes PXE-E23: Client received TFTP error from server Что я делаю не так? Буду очень благодарен за любые советы!! но в конфиге нет никакой «y» с умлаутом:
Amm0
Guest
0
18.01.2025 18:49:00
Пробовали ли вы установить опцию DHCP через CLI? Полагаю, что в winbox/webfig могли использовать «умные кавычки» или какую-то неизвестную локаль/кодировку/клавиатуру Windows… Это явно обновит любую существующую запись, если там был Unicode, CLI его удалит. /ip dhcp-server option set [find code=67 name=boot-file] value="'netboot.xyz.kpxe'"
BartoszP
Guest
0
18.01.2025 21:06:00
Апостроф (’) в AltCODE вводится как 0255 (4 цифры), но немецкая буква ÿ в Юникоде — 00FF, так что, по моему мнению, если в имени файла есть апостроф, то он превращается в букву y с умлаутом в Юникоде, поскольку 255 = 0xFF, а 0 — просто 0. Похоже, что здесь может быть ошибка, но, возможно, «потребитель» данных неправильно интерпретирует полученную информацию.
Andreaux
Guest
0
18.01.2025 21:33:00
Я изначально настроил всё через CLI, скриншоты сделал уже из GUI. Я думал об этом, ведь «y» с умлаутом — это Alt-0255, как я понял. Тем не менее, похоже, что нужный файл не находится (длина = 0). В чём может быть проблема? И при этом, судя по матчерам, выбран должен быть efi-файл, а не kpxe... Сейчас переделываю всю конфигурацию на основе рабочего примера... посмотрим, что выйдет.
Andreaux
Guest
0
18.01.2025 22:18:00
Хорошо, ошибка всё та же даже с совершенно новой конфигурацией. Единственное, что вроде бы теперь работает — это то, что matcher наконец-то выбирает правильный файл, так что теперь ошибка такая: Я совсем запутался. Клиент — DELL PowerEdge R720… Может быть, это он и есть источник проблем?
Andreaux
Guest
0
18.01.2025 22:31:00
Похоже, если я создам новую виртуальную машину на моём сервере Proxmox и установлю загрузку по сети через SeaBIOS (не UEFI), то всё работает. Так что вопрос теперь в том, почему DELL отказывается загружаться по сети? Извиняюсь, что создаю столько проблем.
jaclaz
Guest
0
18.01.2025 23:18:00
Полу-случайная мысль, но тебе правда нужен файл с «мульточечным» именем? Я понимаю, что добрые старые 90-е давно прошли, но иногда привычный 8.3 формат имени всё ещё помогает. Просто для истории: в те же добрые старые времена BartPe, загрузки с USB на XP и так далее, была популярная шутка — «о нет, это же Dell!» — потому что у Dell были свои нестандартные заморочки на уровне BIOS и драйверов Windows. Странный y, вероятно, это ошибка разбора из-за одинарной кавычки/апострофа, но я понятия не имею, есть ли способ с этим справиться.
Andreaux
Guest
0
18.01.2025 23:27:00
На самом деле я даже не трогал имя файла, это буквально значение по умолчанию в netboot.xyz. Всё работает в режиме UEFI с виртуалкой Proxmox. Фух, сначала у меня выскочила ошибка, но это была настройка на стороне Proxmox («Pre-Enroll Keys» нужно было отключить в System/Advanced при создании ВМ). Начинаю подозревать, что это фишка DELL.
ABMT
Guest
0
29.03.2025 03:07:00
Сегодня наткнулся на очень похожую проблему, когда пытался загрузиться по сети с устаревшей материнской платы Gigabyte на LGA775. Постоянно вылезало сообщение «ERROR code:0 string:permission denied!», хотя на самом деле в RouterOS проблем не было. Чтобы разобраться, решил включить логирование по теме “tftp” в роутере. Вот две попытки загрузки по PXE: одна успешная с более новой платы Gigabyte на UEFI, и одна — с той самой старой LGA775.
С новой платы:
03:18:54 dhcp,info server1 снял назначение 192.168.1.36 для FC:AA:14:70:FE:C2 03:18:58 dhcp,info server1 назначил 192.168.1.36 для FC:AA:14:70:FE:C2 03:18:58 tftp,packet получен тип: 1 размер: 24 03:18:58 tftp,packet чтение имени файла: netboot бинарный: 1 03:18:58 tftp,packet опция: tsize значение: 0 03:18:58 tftp,debug tftpd входящее соединение с 192.168.1.36:2070 на 192.168.1.1 03:18:58 tftp,debug запрошен (бинарный) файл: netboot доступ: разрешён 03:18:58 tftp,debug открыт 192.168.1.1:57783 03:18:58 tftp,packet отправка тип: 6 размер: 15 03:18:58 tftp,packet опция: tsize значение: 374433 03:18:58 tftp,packet получен тип: 5 размер: 17 03:18:58 tftp,packet ошибка: 0 03:18:58 tftp,error ОШИБКА: код 0 03:18:58 tftp,debug закрытие соединения к 192.168.1.36:2070 03:18:58 tftp,packet получен тип: 1 размер: 29 03:18:58 tftp,packet чтение имени файла: netboot бинарный: 1 03:18:58 tftp,packet опция: blksize значение: 1456 03:18:58 tftp,debug tftpd входящее соединение с 192.168.1.36:2071 на 192.168.1.1 03:18:58 tftp,debug запрошен (бинарный) файл: netboot доступ: разрешён 03:18:58 tftp,debug открыт 192.168.1.1:42375 03:18:58 tftp,packet отправка тип: 6 размер: 15 03:18:58 tftp,packet опция: blksize значение: 1456 03:18:58 tftp,packet получен тип: 4 seq: 0 размер: 4 03:18:58 tftp,packet отправка тип: 3 seq: 1 размер: 1460
С старой платы:
03:26:32 dhcp,info server1 снял назначение 192.168.1.32 для 00:1A:4D:46:C6:58 03:26:34 dhcp,info server1 назначил 192.168.1.32 для 00:1A:4D:46:C6:58 03:26:34 tftp,packet получен тип: 1 размер: 25 03:26:34 tftp,packet чтение имени файла: netbootFF бинарный: 1 03:26:34 tftp,packet опция: tsize значение: 0 03:26:34 tftp,debug tftpd входящее соединение с 192.168.1.32:2070 на 192.168.1.1 03:26:34 tftp,debug запрошен (бинарный) файл: netbootFF доступ: запрещён 03:26:34 tftp,error ОШИБКА код:0 строка: permission denied! 03:26:34 tftp,packet отправка тип: 5 размер: 23 03:26:34 tftp,packet ошибка: 0 03:26:34 tftp,packet получен тип: 1 размер: 30 03:26:34 tftp,packet чтение имени файла: netbootFF бинарный: 1 03:26:34 tftp,packet опция: blksize значение: 1456 03:26:34 tftp,debug tftpd входящее соединение с 192.168.1.32:2071 на 192.168.1.1 03:26:34 tftp,debug запрошен (бинарный) файл: netbootFF доступ: запрещён 03:26:34 tftp,error ОШИБКА код:0 строка: permission denied! 03:26:34 tftp,packet отправка тип: 5 размер: 23 03:26:34 tftp,packet ошибка: 0
Запрошенный (бинарный) файл в логе значится как “netbootFF” со старой платы. В просмотрщике логов WinBox он отображается как " read filename: netboot˙ binary: 1". Символ «˙» — это U+02D9 “DOT ABOVE” (). Забавно, что в WinBox он идёт как двухбайтовый символ, хотя в логе указано, что весь пакет всего на один байт длиннее, чем пакет от новой платы, которая загрузилась нормально. Я пробовал эксперименты с именем файла TFTP-запроса и опцией DHCP 67, чтобы заставить эту старую плату загрузиться, но, похоже, это невозможно из-за того, как устроены эти компоненты в RouterOS. Думаю, дело в том, что на старой плате PXE-загрузка реализована очень плохо.
pe1chl
Guest
0
29.03.2025 09:16:00
Проблема в том, что в DHCP поля имеют длину, поэтому имя файла в DHCP-пакете, например, записывается как 03 41 42 43, чтобы указать имя файла ABC с длиной 3. Это не понимают некоторые программисты, которые считают, что такое имя файла хранится как 41 42 43 00, где 00 — это завершающий байт строки. В ответе DHCP, когда имя файла — это последняя опция, следующий байт будет FF, что означает «конец опций», после чего, скорее всего, по ошибке окажется байт 00 (потому что он хранится в буфере, заполненном нулями). В итоге получается имя вроде 41 42 43 FF 00, которое в одном контексте интерпретируется как ABCÿ, а в другом — как какое-то неправильное имя. С этим всегда сложно разобраться.
Хотя я понимаю автора выше, который жалуется на Dell (народ из Dell BIOS — настоящие уроды, которые отказываются признавать свои ошибки), на современных машинах Dell с актуальными версиями BIOS всё работает нормально. Я регулярно загружаю по сети машины Dell. Но если у вас старое неподдерживаемое устройство и нет доступных обновлений BIOS, проблем не избежать. У других производителей ситуация может быть такой же.
Похоже, такие функции часто попросту не тестируют.
Я совсем запутался. Клиент — DELL PowerEdge R720… Может быть, это он и есть источник проблем?