что втварь хочет от dhcp уже после старта ядра?

[Rgpr]

хочу запустить втварь из другой сети/vlan, (как вариант pxe загрузки, а не только её)
в свой #!ipxe прописываю так же как в оригинале

:wtware
set wtware-url http://192.168.27.10:789/wtware
boot ${wtware-url}/6.0.73/packages/kernel BOOT_IMAGE=${wtware-url}/6.0.73/packages/kernel quiet

оно всё скачивает и стартует, но кончает

Безымянный.png (53.16 КБ) 19059 просмотров

на DEL кстати не реагирует
чего оно хочет если адрес уже есть (да не из 27й и не от втварьного dhcp) и даже ядро запущено.
само ядро-то как дальнейшее качает?

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

[Rgpr]

с маршрутизацией и т.д. всё ОК. ибо если "с диска" запускать из этой же подсети то всё грузится и т.п.

[Rgpr]

Код: Выделить всё

:wtware
set next-server 192.168.27.10
set wtware-url http://${next-server}:789/wtware
boot   ${wtware-url}/6.0.73/packages/kernel BOOT_IMAGE=${wtware-url}/6.0.73/packages/kernel quiet

и даже такой "финт ушами" не спасает. такое же поведение.

[aka]

Втварь хочет от dhcp после старта ядра свой IP. Информация, которую получил загрузчик от dhcp, погибает вместе с загрузчиком. И конфиг загрузчика тоже погибнет вместе с загрузчиком. После загрузчика остаётся только командная строка линуксового ядра. Втварь спрашивает у dhcp всё заново, и вопрос задаёт ширше.

Какие проблемы у dhcp ответить ещё раз?

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

[Rgpr]

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

я понимаю почему сеть пропадает, инициализация дройвера сети, все дела. но почему не восстанавливается?
и в чём именно новый запрос более-ширее?
даже за вычетом 60\66\67 параметров, сам адрес что мешает получать?
см.выше - возможность его выдачи таки есть, иначе бы как ядро грузилось.

делал символьную ссыль с другого tftp\http на http втвари с сохранением структуры каталогов - но толку то если до выдачи адреса не доходит..

[Rgpr]

я даже разобрался что втварь хочет если стартовать с wtware.pxe/http
оно ищет cfg с тем же именем. (и тут понятно влияние 66и67)
но дальше то - из конфига грузит ядро, и?
в чём дальнейшая разница в плане опроса dhcp?
я бы понял что если бы 66 далее использовался, но был бы неверен, но почему оно - вообще адрес не хочит получить(как минимум тот же что при загрузке - не пингуется)

[aka]

я понимаю почему сеть пропадает, инициализация дройвера сети, все дела. но почему не восстанавливается?

1. Драйвер сетевой карты в втвари не договорился с сетевой картой.
2. Или второй вариант - с сетью всё нормально, но DHCP-сервер почему-то не отвечает.

Если DHCP майкрософтовый, то посмотри на первый скриншот в статье: https://wtware.ru/docs5/httpboot.html

даже за вычетом 60\66\67 параметров, сам адрес что мешает получать?

Они вместе ходят, в одном ответе от DHCP.

Снифер пакетов сможешь поставить и посмотреть на пакеты DHCP в сети? Должен быть запрос DHCP от биоса. На него ответ сервера. Эти два пакета явно есть, раз ядро качается. Затем должен быть похожий запрос уже от втвари, и ещё один ответ от dhcp сервера (на самом деле должно быть четыре пакета - втварь шлёт dhcp discover, сервер отвечает dhcp offer, втварь шлёт dhcp request, сервер отвечает dhcp ack). Если нет запроса от втвари, значит проблема в драйвере сетевой карты у втвари. Если нет ответа от dhcp сревера, значит неправильно настроен dhcp сервер.

И ещё хорошо бы добыть лог втвари. Там, где втварь пишет "нет ответа от DHCP", надо нажать Esc. Несколько раз, и ждать, оно тупит, но со временем должно раступиться и дать командную строку. Из командной строки снять лог последним методом из статьи, "когда на терминале нет сети": http://wtware.ru/logs.html

[Rgpr]

-с железом \ дройвером всё ок = на боевом терминале тестил (на трёх) менял только сеть (vlan=>адреса)
-удивляет лишь что на 3х совсем разных, 3 опять же совсем разные флешки (таки да фат32) => 9 комбинаций хер примаунтились (вставлял и до и после загрузки) и даже разные методы эмуляции в бивисе не спасли
так что логов - ноль. (команда log исполняется)
-на DEL тоже игнор.
+в dhcp нолик как на картинке был изначально проставлен

с tcpdump - хер нагуглишь как чтобы и по маку(макам) и бродкаст\мультикаст одновременно фильтровал

потому пускал сразу в 2х местах одновременно
вот с маком dhcp (и это не tftp)

Код: Выделить всё

root@pve:~# tcpdump ether host 00:15:5d:19:96:07
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on enp3s0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
01:55:58.649417 IP spb-bel-dc1.afk.local.bootps > 255.255.255.255.bootpc: BOOTP/DHCP, Reply, length 306
01:55:58.715520 IP pve.afk.local.40039 > spb-bel-dc1.afk.local.domain: 3887+ PTR? 255.255.255.255.in-addr.arpa. (46)
01:55:58.716159 IP spb-bel-dc1.afk.local.domain > pve.afk.local.40039: 3887 NXDomain* 0/1/0 (130)
01:55:58.716234 IP pve.afk.local.59777 > spb-bel-dc1.afk.local.domain: 17720+ PTR? 20.25.168.192.in-addr.arpa. (44)
01:55:58.716718 IP spb-bel-dc1.afk.local.domain > pve.afk.local.59777: 17720* 1/0/0 PTR spb-bel-dc1.afk.local. (79)
01:55:59.647198 IP spb-bel-dc1.afk.local.bootps > 255.255.255.255.bootpc: BOOTP/DHCP, Reply, length 306
01:56:03.569134 ARP, Request who-has pve.afk.local (2c:56:dc:fb:e8:fb (oui Unknown)) tell spb-bel-dc1.afk.local, length 46
01:56:03.569143 ARP, Reply pve.afk.local is-at 2c:56:dc:fb:e8:fb (oui Unknown), length 28
01:56:03.955165 ARP, Request who-has spb-bel-dc1.afk.local tell pve.afk.local, length 28
01:56:03.955513 ARP, Reply spb-bel-dc1.afk.local is-at 00:15:5d:19:96:07 (oui Unknown), length 46
01:56:06.363079 IP spb-bel-dc1.afk.local.bootps > 255.255.255.255.bootpc: BOOTP/DHCP, Reply, length 306
01:56:07.363189 IP spb-bel-dc1.afk.local.bootps > 255.255.255.255.bootpc: BOOTP/DHCP, Reply, length 306
01:56:11.425136 IP spb-bel-dc1.afk.local.bootps > 255.255.255.255.bootpc: BOOTP/DHCP, Reply, length 300
01:56:13.470901 IP spb-bel-dc1.afk.local.bootps > 255.255.255.255.bootpc: BOOTP/DHCP, Reply, length 316
01:56:14.499022 IP spb-bel-dc1.afk.local.bootps > 255.255.255.255.bootpc: BOOTP/DHCP, Reply, length 316
01:56:15.534821 IP spb-bel-dc1.afk.local.bootps > 255.255.255.255.bootpc: BOOTP/DHCP, Reply, length 316
01:56:16.570678 IP spb-bel-dc1.afk.local.bootps > 255.255.255.255.bootpc: BOOTP/DHCP, Reply, length 316
01:56:17.602996 IP spb-bel-dc1.afk.local.bootps > 255.255.255.255.bootpc: BOOTP/DHCP, Reply, length 316
01:56:18.630951 IP spb-bel-dc1.afk.local.bootps > 255.255.255.255.bootpc: BOOTP/DHCP, Reply, length 316
01:56:19.658774 IP spb-bel-dc1.afk.local.bootps > 255.255.255.255.bootpc: BOOTP/DHCP, Reply, length 316
01:56:20.691100 IP spb-bel-dc1.afk.local.bootps > 255.255.255.255.bootpc: BOOTP/DHCP, Reply, length 316
и до бесконечности такиеже

а это мак терминала

Код: Выделить всё

root@nc:~# tcpdump  ether host C6:F4:36:91:8F:8B
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
22:55:58.647344 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from c6:f4:36:91:8f:8b (oui Unknown), length 397
22:55:59.645282 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from c6:f4:36:91:8f:8b (oui Unknown), length 409
22:55:59.646140 ARP, Request who-has 192.168.25.148 tell 192.168.25.148, length 46
22:55:59.646141 ARP, Request who-has spb-kon-rtr1.afk.local tell 192.168.25.148, length 46
22:56:00.181730 ARP, Request who-has 192.168.25.148 tell 192.168.25.148, length 46
22:56:00.181730 ARP, Request who-has spb-kon-rtr1.afk.local tell 192.168.25.148, length 46
22:56:06.361380 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from c6:f4:36:91:8f:8b (oui Unknown), length 400
22:56:07.360865 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from c6:f4:36:91:8f:8b (oui Unknown), length 412
22:56:07.362131 ARP, Request who-has 192.168.25.148 tell 192.168.25.148, length 46
22:56:07.362131 ARP, Request who-has spb-kon-rtr1.afk.local tell 192.168.25.148, length 46
22:56:13.469000 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from c6:f4:36:91:8f:8b (oui Unknown), length 548
22:56:14.497108 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from c6:f4:36:91:8f:8b (oui Unknown), length 548
22:56:15.533050 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from c6:f4:36:91:8f:8b (oui Unknown), length 548
22:56:16.569072 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from c6:f4:36:91:8f:8b (oui Unknown), length 548
22:56:17.601094 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from c6:f4:36:91:8f:8b (oui Unknown), length 548
22:56:18.628966 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from c6:f4:36:91:8f:8b (oui Unknown), length 548
22:56:19.657010 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from c6:f4:36:91:8f:8b (oui Unknown), length 548
и стопицотмилионов повторов

т.е. 1й просит - 2й даёт - а результату нет

tftp за всё время очередной попытки только 2 бродкаста шлёт - т.е. видать как раз 66\67

Код: Выделить всё

23:24:42.124146 IP spb-kon-rtr1.afk.local.bootps > 255.255.255.255.bootpc: BOOTP/DHCP, Reply, length 300
23:24:52.924640 IP spb-kon-rtr1.afk.local.bootps > 255.255.255.255.bootpc: BOOTP/DHCP, Reply, length 300

[Rgpr]

вспомнил - попробовал в ещё более-другой третей сетке. там tftp\wds тот же но dhcp другой, микрот vs m$, но результат такой же.

72 и 73 последние ядра - без разницы

[aka]

Если загружаешься через http, то там ещё и ipxe (wtware.http) свои запросы шлёт. Я черточками разделял: первая пара строк от BIOS, потом шесть строк от ipxe, потом запросы от втвари.

Код: Выделить всё

# tcpdump -n port 67 and port 68
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
20:58:32.281942 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 00:0c:29:7d:fb:0b, length 548
20:58:32.583492 IP 10.1.1.102.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, length 354
20:58:34.628215 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 00:0c:29:7d:fb:0b, length 548
20:58:34.630743 IP 10.1.1.102.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, length 354
===
20:58:34.771423 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 00:0c:29:7d:fb:0b, length 395
20:58:34.778704 IP 10.1.1.102.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, length 319
20:58:35.582172 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 00:0c:29:7d:fb:0b, length 395
20:58:35.602571 IP 10.1.1.102.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, length 319
20:58:37.368491 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 00:0c:29:7d:fb:0b, length 407
20:58:37.370613 IP 10.1.1.102.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, length 319
===
20:58:39.738099 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 00:0c:29:7d:fb:0b, length 548
20:58:40.042109 IP 10.1.1.102.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, length 354
20:58:41.316134 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 00:0c:29:7d:fb:0b, length 548
20:58:41.319723 IP 10.1.1.102.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, length 354
20:58:42.021477 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 00:0c:29:7d:fb:0b, length 548
20:58:42.024930 IP 10.1.1.102.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, length 354
20:58:42.061538 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 00:0c:29:7d:fb:0b, length 548
20:58:42.065117 IP 10.1.1.102.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, length 354
20:58:42.096664 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 00:0c:29:7d:fb:0b, length 548
20:58:42.100101 IP 10.1.1.102.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, length 354

[Rgpr]

I) в том то и дело что я сразу ядро гружу, а не wtware.pxe или wtware.http (за вычетом варика с uefi)
a) wtware.pxe так и не смогло свой конфиг найти
б) wtware.http смог подсунуть с извратом, но толку?? оно загрузило ядро===> вернулись к тому же самому

само ядро из ipxe и по tftp и по http из своего меню ipxe. для тесту и из pxelinux грузил, опять же сразу ядро = монописуально.

II)вот код (спс за подсмотренную команду)загрузка до меню выбора втвари
(ограничимся тока legacy вариантом)

Код: Выделить всё

listening on enp3s0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
23:33:59.615546 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from c6:f4:36:91:8f:8b, length 397
23:33:59.616525 IP 192.168.25.20.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, length 306
23:33:59.744697 IP 192.168.25.1.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, length 300
23:34:00.614076 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from c6:f4:36:91:8f:8b, length 409
23:34:00.615235 IP 192.168.25.20.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, length 306
23:34:07.831230 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from c6:f4:36:91:8f:8b, length 400
23:34:07.832471 IP 192.168.25.20.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, length 306
23:34:07.846254 IP 192.168.25.1.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, length 300
23:34:08.830531 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from c6:f4:36:91:8f:8b, length 412
23:34:08.831801 IP 192.168.25.20.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, length 306

терминалу отвечают и dhcp и wds

жмём загрузку = ядро скачивается и стартует

Код: Выделить всё

root@pve:~# tcpdump -n port 67 and port 68
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on enp3s0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
23:47:07.220556 IP 192.168.25.114.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 90:2b:34:ca:e7:c9, length 300
23:47:08.231306 IP 192.168.25.108.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 00:15:5d:19:96:03, length 300
23:47:08.231992 IP 192.168.25.20.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, length 300
23:47:16.340485 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from c6:f4:36:91:8f:8b, length 548
23:47:16.341448 IP 192.168.25.20.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, length 316
23:47:17.372467 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from c6:f4:36:91:8f:8b, length 548
23:47:17.373572 IP 192.168.25.20.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, length 316
23:47:18.404447 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from c6:f4:36:91:8f:8b, length 548
23:47:18.405578 IP 192.168.25.20.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, length 316
23:47:19.126205 IP 192.168.25.107.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 50:46:5d:4e:68:ea, length 300
23:47:19.436490 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from c6:f4:36:91:8f:8b, length 548
23:47:19.437353 IP 192.168.25.20.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, length 316
23:47:20.468461 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from c6:f4:36:91:8f:8b, length 548
23:47:20.469550 IP 192.168.25.20.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, length 316
23:47:21.500491 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from c6:f4:36:91:8f:8b, length 548
23:47:21.501669 IP 192.168.25.20.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, length 316
23:47:22.532494 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from c6:f4:36:91:8f:8b, length 548
23:47:22.533188 IP 192.168.25.20.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, length 316
23:47:23.175396 IP 192.168.25.79.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 08:60:6e:88:db:34, length 300
23:47:23.176391 IP 192.168.25.20.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, length 300
23:47:23.564490 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from c6:f4:36:91:8f:8b, length 548
23:47:23.565294 IP 192.168.25.20.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, length 316
23:47:24.592504 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from c6:f4:36:91:8f:8b, length 548
23:47:24.593414 IP 192.168.25.20.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, length 316
23:47:25.624497 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from c6:f4:36:91:8f:8b, length 548
23:47:25.625639 IP 192.168.25.20.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, length 316
23:47:26.656493 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from c6:f4:36:91:8f:8b, length 548
23:47:26.657564 IP 192.168.25.20.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, length 316
23:47:27.692540 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from c6:f4:36:91:8f:8b, length 548
23:47:27.693538 IP 192.168.25.20.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, length 316
23:47:28.724543 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from c6:f4:36:91:8f:8b, length 548
23:47:28.725748 IP 192.168.25.20.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, length 316
23:47:29.760481 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from c6:f4:36:91:8f:8b, length 548
23:47:29.761251 IP 192.168.25.20.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, length 316
23:47:30.796483 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from c6:f4:36:91:8f:8b, length 548
23:47:30.797170 IP 192.168.25.20.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, length 316
23:47:31.828506 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from c6:f4:36:91:8f:8b, length 548
23:47:31.829411 IP 192.168.25.20.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, length 316
23:47:32.860505 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from c6:f4:36:91:8f:8b, length 548
23:47:32.861455 IP 192.168.25.20.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, length 316
23:47:33.892501 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from c6:f4:36:91:8f:8b, length 548
23:47:33.893398 IP 192.168.25.20.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, length 316
23:47:34.928528 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from c6:f4:36:91:8f:8b, length 548
23:47:34.929508 IP 192.168.25.20.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, length 316
23:47:35.960512 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from c6:f4:36:91:8f:8b, length 548
23:47:35.961593 IP 192.168.25.20.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, length 316
23:47:36.992484 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from c6:f4:36:91:8f:8b, length 548
23:47:36.993220 IP 192.168.25.20.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, length 316
23:47:38.024485 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from c6:f4:36:91:8f:8b, length 548
23:47:38.025463 IP 192.168.25.20.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, length 316
23:47:39.056532 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from c6:f4:36:91:8f:8b, length 548
23:47:39.057453 IP 192.168.25.20.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, length 316
23:47:40.088529 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from c6:f4:36:91:8f:8b, length 548
23:47:40.089536 IP 192.168.25.20.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, length 316
23:47:41.120505 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from c6:f4:36:91:8f:8b, length 548
23:47:41.121567 IP 192.168.25.20.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, length 316
23:47:42.152472 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from c6:f4:36:91:8f:8b, length 548
23:47:42.153314 IP 192.168.25.20.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, length 316
23:47:43.184524 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from c6:f4:36:91:8f:8b, length 548
23:47:43.185252 IP 192.168.25.20.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, length 316

и собственно всё (вклинились ещё левые хосты, но чистить лог уж не стал)

почему они друг друга не любят?

повторюсь - пробовал с ещё более другим dhcp = такой же зависон (но пакеты там не заснифить)

[aka]

Код: Выделить всё

listening on enp3s0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
23:33:59.615546 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from c6:f4:36:91:8f:8b, length 397
23:33:59.616525 IP 192.168.25.20.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, length 306
23:33:59.744697 IP 192.168.25.1.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, length 300

терминалу отвечают и dhcp и wds

жмём загрузку = ядро скачивается и стартует

Код: Выделить всё

...
23:47:08.231992 IP 192.168.25.20.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, length 300
23:47:16.341448 IP 192.168.25.20.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, length 316
23:47:17.373572 IP 192.168.25.20.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, length 316

Примета у меня есть: два dhcp в одной сети не живут. Теоретически могут, практически заканчивается крышесносительными косяками.

192.168.25.20.67 это кто?

Добавь в tcpdump флаг -v.

Код: Выделить всё

tcpdump -vn port 67 and port 68

Будет очень много букв. Проверим, что в ответе 192.168.25.20.67 есть опции 066 и 067, без них втварь игнорирует ответ.

[Rgpr]

ессно что разные dhcp в разных (под)сетях\vlan. так же как и втварный в своём vlan
но маршрутизация меж ними есть есть. +wds общий (исключая втварь vlan)

25.20 это m$ dhcp
25.1 шлюз а по факту relay от wds

опции 066 и 067, без них втварь игнорирует ответ.

ну не прошло и три года как ответ даден.

примерно про это и хотел услышать с первого раза.
от m$ нет ответа с 66 и 67. они тока от wds.
не баг а фича.
dhcp и wds разные ip
потому осознано и пусто в 60\66\67 на dhcp
wds из коробки uefi \ legacy клиентов детектит и разное отвечает.
всё за счёт brodcast само делается.

значит обломинго, как я это вижу. если только не подскажешь что можно ещё сделать.

[aka]

примерно про это и хотел услышать с первого раза.
от m$ нет ответа с 66 и 67. они тока от wds.

Это один из этапов защиты от двух dhcp. Если втварь загрузилась по сети, значит есть dhcp, который сказал биосу IP TFTP-сервера и загузочный файл. Втварь ждёт такого же ответа.

[Rgpr]

а что из нового ответа втварь юзает? ядро в самом деле в душе не знает откуда и как оно запустилось? что ему надо чтобы продолжить скачку?

[aka]

Правильный способ продолжить скачку - получить такой же ответ от того же DHCP, с которого началась загрузка. Так будет гарантия, что терминал получит тот же IP, с которым начал загрузку. Проверка сделана для того, чтобы не хватать ответы от других DHCP, а дождаться того ответа, по которому начинал загрузку биос. Я не вижу никакого способа определить "тот же" ответ кроме наличия 066 и 067.

Без UEFI втварь по командной строке ядра определяет, откуда загрузилась. Никакой другой информации, кроме командной строки ядра, под Legacy BIOS нет.

[Rgpr]

вот. уже хлеб.
я из своего ipxe, да и в ориге BOOT_IMAGE=${wtware-url}/6.0.73/packages/kernel quiet передаю
не будь защиты от дурака, ядро должно продолжать.
не вполне узнаю "язык" из pxe.cfg (syslinux?) но и там в append помимо quiet можно присунуть путь откуда брать следующее.

как с uefi быть х.з. хотя если тот же http.efi(bootx64.efi) вызывать не из бродкаста, а из стороннего меню => любой параметр опять же можно передать, вопрос лишь, схавает ли.

[aka]

не будь защиты от дурака, ядро должно продолжать.

Да. Требование 066 и 067 в ответе dhcp это защита от дурака, от второго DHCP. В параметре BOOT_IMAGE=http://... достаточно информации чтобы продолжать загрузку по HTTP.

не вполне узнаю "язык" из pxe.cfg (syslinux?) но и там в append помимо quiet можно присунуть путь откуда брать следующее.

Можно. Если туда вписать правильный BOOT_IMAGE=http://... то syslinux скачает ядро по TFTP, а втварь всё следующее будет качать по HTTP. Потому что втварь не знает, кто её загрузил - ipxe из wtware.http или syslinux из wtware.pxe. Втварь под Legacy BIOS знает только то, что в командной строке ядра.

как с uefi быть х.з. хотя если тот же http.efi(bootx64.efi) вызывать не из бродкаста, а из стороннего меню => любой параметр опять же можно передать, вопрос лишь, схавает ли.

Не схавает. Под uefi у втвари грузится сразу ядро, без какого-либо предзагрузчика. Нет предзагрузчика - нет конфига предзагрузчика. Командную строку ядра теоретически можно было бы передать через умный UEFI в матери, но практически умных UEFI в жизни не встречается и втварь ничего в командной строке не ищет. UEFI всегда качает ядро по TFTP, а потом втварь смотрит на 067 параметр. Если в 067 параметре bootx64.efi - втварь качает по TFTP. Если в 067 параметре http.efi (http.efi это тот же файл, что и bootx64.efi), то втварь качает по HTTP.

[Rgpr]

а ежели, дабы не ломать, логику конфигов и т.п. - обучить ядро новым параметрам? т.е. логику оставить как щас, но сделать чтобы реагировало на команды из внешних конфигов и их initrd
что-то вроде

Код: Выделить всё

ANYDHCP

и обнаружив её отрубало защиту. а не обнаружив ессно не отрубало.

а какие ещё параметры кроме

Код: Выделить всё

BOOT_IMAGE=

уже есть?

+из написанного тобою, втварь что, не видит разницы, откуда команда пришла? т.е. из 66\67 или от предварительного конфига?

т.е. объяснения я понимаю, смущают формулировки. про тот же uefi = ессно что через dhcp и его приблуды такое не сделать (разве что заюзать и читать из "свободного" 200+ параметра = но это не наш метод) достаточно, в узкоспецифическом варианте как мой, научить реагированию на initrd ***

[aka]

что-то вроде

Код: Выделить всё

ANYDHCP

и обнаружив её отрубало защиту

Зачем?

[Rgpr]

чтобы иметь способ загрузить втварь "по требованию". а не перемещать комп в (под)сеть терминалов.

[aka]

Не понимаю задачу. Можно подробнее?