Сегодня полдня было потрачено на то, чтобы запустить рутер на МТК пакете ГО2... проблема в неполучении ип-адреса от ДХЦП-сервера.... причем выборочном неполучении.... винда, фрибсд и убунту линукс его получают отлично, а вот микротик и модем хуавей ну никак...
То есть, сперва модем стоял в режиме "pure bridge" и на микротике в ДХЦП-клиенте было настроено что надо получать ИП на этом интерфейсе... висит "searching"и все... запущен сниффер... микротик раз в 5 секунд шлет пакет на 255.255.255.255:67.. в ответ тишина... на винде, фряхе и бунту, как писал раньше, проблем с точно такими же настройками модема никаких... если вписать МТ вручную ип из нужной подсети и дефолт рут, инет пашет....
шаг 2 - поставить модем как рутер, чтобы получал ип, НАТил в локальный и дальше на МТ идет шейпинг и все такое... то есть имеем еще один хоп в сети - коряво, но работает... нифига... модем переведен в режим DHCP - но ип он не получает... час мучались с настройками модема, вроде все в норме, опять же вписываем статику - все пашет скачали с сайта МТК мануал по настройке этого модема как рутера - у нас все как положено.... звоним в суппорт.. сказать, что так и так, не можем получить ип по дхцп.... в суппорте прошли курс молодого бойца как менять ип-адрес на виндовом компе, потом узнали что на модеме включен дхцп-сервер, сказали что это не дело и он не правильный, потому что он клиентам ДНС-ов не дает ) в общем ничего нового..... помучались еще полчаса... щас на серваке том ставится фря... но факт остается фактом... где-то глюк... и явно не у нас.... дома у меня МТ отлично получает ип через ДХЦП... правда модем не такой... зато вспомнил, что у другого человека на той же 44 станции тоже не удалось на таком же модеме (хуавей мт800) поднять рутинг....
На это мне ответил Padre с возможным вариантом проблемы:
Итак, из изложенного выше следует:
DHCP клиенты систем Windows, FreeBSD, Linux (Ubintu) получают ip адрес от DHCP сервера.
DHCP клиенты устройств Huawei MT800 и Микротик, подключаемые к той же линии ip адреса не получают.
Возможная причина: устройства не корректно обрабатывают DHCP extended поля, как то CLIENT ID, OPTIONS, поэтому не получают DHCPOFFER от сервера.
Буквально вчера появилась аналогичная проблема... Кто виноват и что делать - решайте сами...
Бэкграунд: пропал инет, Микротик (уже 3.17) не может получить ип по ДХЦП... ип вписан вручную - проработало некоторое время и поломалось тоже (максфибер, как я понимаю, просто на свитче перекрыло доступ из-за того что закончилась авторизация по option61, это сейчас не столь важно). Попытки просниффить дали следующее: Идет запрос, на него идет явно ответ....
Согласно Википедии
(конечно это все описано в RFC2132, но в вики красивее) http://en.wikipedia.org/wiki/Dhcp#Technical_details Мы имеем, что:
1. Клиент отсылает запрос с DHCPDISCOVER
2. Сервер ему отвечает с DHCPOFFER с IP-адресом и некоторыми опциями в нем
3. Клиент на это отсылает DHCPREQUEST, где может согласиться с предложенным адресом или указать предпочитаемый IP-адрес
4. Сервер на это отвечает DHCPACK в котором еще раз присылает все опции (как в DHCPOFFER).
При разборе отловленных пакетов было установено, что запрос, который идет, это естественно DHCPDISCOVER - option 53:1, а ответ на него - DHCPOFFER - option 53:2... Но есть одна мелочь в этом пакете, которая меня смутила - вот детальный разбор опций:
- Код: Выделить всё
6382 5363 Magic cookie 35 -option 53 DHCP msg type 01 length 02 - offer 36 - option 54, Server id 04 - length 00000000 - !! 33 - option 51, lease time 04 -length 00000e10 - time, sec 01 - option mask 04 - length ffffff00 - mask 03 option router 04- length 5c729d01 - 92.114... 06 - option DNS 08 - length ac1b890a - dns1 ac1b8914 - dns2 ff - end
Так вот, почему ServerID - 0.0.0.0? Ведь по РФЦ2132 -
9.7. Server Identifier
This option is used in DHCPOFFER and DHCPREQUEST messages, and may
optionally be included in the DHCPACK and DHCPNAK messages. DHCP
servers include this option in the DHCPOFFER in order to allow the
client to distinguish between lease offers. DHCP clients use the
contents of the 'server identifier' field as the destination address
for any DHCP messages unicast to the DHCP server. DHCP clients also
indicate which of several lease offers is being accepted by including
this option in a DHCPREQUEST message.
The identifier is the IP address of the selected server.
The code for this option is 54, and its length is 4.
То есть, если он уже указан, то он должен быть ип-адресом сервера, предложившего адрес. А указан он в DHCPOFFER должен быть обязательно. Мне кажется именно это и переклинивает Микротиковский дхцп-клиент и заставляет его разорвать процесс получения адреса и начать его заново. При этом, на винде, как и в прошлом случае, все работает.. на фрибсд и линуксе не проверялось, но скорее всего тоже. Винда в состоянии подключения адрес ДХЦП-сервера не показывает, хотя обычно (когда этот адрес правильный
) она это делает...
В чем баг - решайте сами... только не надо плс криков что "Телеком решил бороться с сетками"
сами прекрасно понимаете - это все прекрасно обходится с помощью рутеров на ФриБСД, винде, линуксе и т.д. или транзитном между микротиком и телекомом или в качестве основного.... Да и в миротик можно письмо написать по идее, чтобы была возможность игнорить это поле в ответе Почему я 2 года назад не видел ответов с DHCPOFFER - может не так ловил
Не пинайте за много букв
Врываются люди в масках, всем лежать! - а ты админ иди сюда - исправляй ответ дхцп сервера ServerID 
! и без шуток!!! у нас бомба 
Айтек выше писал, что МТ пока беспокоить не хотят.... круг замкнулся 