[minion]

Есть подозрения что в пакете Discover строка client class information несет в себе ID, оно выглядит: 4d 53 46 54 20 35 2e 30 в ASCII это MSFT 5.0 тобишь класс вендора софтверного win2k/XP, вот заюзать железяку что б посматреть код запроса немогу((, нет пока возможности, кто нить капнет дальше?

[wertyg]

да без резервирования вроде не обойтись.(

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

1 - клиент dhcpdiscovery(органиченно широковещательно) ищет сервер в сети. в этом пакете он передаёт список опций клиента. опция номер 55 перечень запрашиваемых опций. опция номер 77 - пользовательский класс. опция 60 класс производителя.
2 - сервер dhcpoffer(ограниченно широковещательно) сервер отвечаеть клиенту предложением.
3 - клиент dhcpreqvest(ограниченно широковещательно) клиент согласен с предложением просит подтверждения
4 - сервер dhcpack(ограниченно широковещательно) серверу нет причин отказать.
...
5 - клиент dhcpreqvest(серверу) по истечении времени аренды обращаеться к серверу за продлением.
6 - сервер dhcpack(клиенту) серверу нет причин отказать.

анализ пакета dhcpdiscovery показывает что переопределяються\дополняються опции. т.е. любое значение в поле опций пакета ДХСП. в то время как адрес устройствам передаёться не в опциях а в спец. поле ДХСП пакета. изменить\переопределить его с помощью опций невозможно.

вендор класс это опция номер 60. я так понял это производитель программы клиента ДХСП решает быть ей или нет. и соответственно она меняеться в зависимости от операционки(класс разработчика клиента) а не от производителя железа. например клиент ДХСП в голой FreeBSD не передаёт вендор класс в пакете(хотя опция такая всё же есть, только её нужно явно задать. и явно присвоить ей значение). вероятность того что маршрутизатор передаёт эту опцию ещё меньше.( ну а про юзер класс который присваеваеться вручную для маршрутизатора вообще молчу. к сожалению проверить немогу - маршрутизатора нет. но это уже не важно.)

вообщем не получаеться задавать\переопределять получаемые хостом ИП адреса с помощью вендор\юзер классов.(

з.ы. в результате эксперемента было обнаруженно следующие:
1 - FreeBSD клиент передаёт пакет продления аренды(5), на канальном уровне, не серверу у которого он её получил а ограниченно широковещательно, в отличии от MS клиента который пакет продления аренды(5) посылает, на канальном уровне, серверу. на что MS сервер не реагирует.) и соответственно не продлевает аренду пакетом (6).
2 - после истечения времени аренды FreeBSD всё ещё продолжает использовать полученный адрес. я так понял что у неё ввремя аренды отличаеться от предложенного сервером времени.
3 - команда ipconfig /showclassid <имя интерфейса> показывает допустимые классы пользователя определённые на ДХСП сервере(я думал что она должна показывать класс закреплённый за интерфейсом.). а класс закреплённый за интерфейсом она почемуто не показывает.
4 - команда ipconfig /setclassid <имя интерфейса> <имя класса> присваевает интерфейсу любое имя класса. т.е. без проверки есть ли такой на сервере. так на будущее. который передаёться в опции 77 пакета(1).
5 - команда ipconfig /setclassid <имя интерфейса> <без пробела нет ничего> сбрасывает присвоенный класс. опция 77 впредь отсутствует в пакетах(1).

з.з.ы я в никсах новичёк, возможно что то сделал не так(клиента ДХСП не настраевал вообще, просто включил и всё. но обратите внимание что настроек клиента в винде ещё меньше.)) ). если что поправьте.

з.з.з.ы слушай minion, а зачем такая необходимость? изложи задачу. возможно она решаеться ещё кокимто образом? ведь если маршрутизатор получит ИП из другой сети он не может взаимодействовать с хостами этой сети. и чтоже это за маршрутизатор такой, если им нельзя воспользоваться.

*работа ДХСП сервера описана в RFC номер 1541

[minion]

wertyg,
Задача решима тем же самым резервированием, но мне было инетересно зачем создали тогда вендор класс, а вот client class information все же есть в пакете дхсп, и я почти уверен что он являеться ИД железки, или клиента дхсп как ты говарил. Просто нет железок что бы это все проверить(

[wertyg]

minion, ну так я проверил. это таки

клиента дхсп как ты говарил »

о чем и написал

вендор класс это опция номер 60. я так понял это производитель программы клиента ДХСП решает быть ей или нет. и соответственно она меняеться в зависимости от операционки(класс разработчика клиента) а не от производителя железа. например клиент ДХСП в голой FreeBSD »

во Freebsd не передаёться по умолчанию ни вендор ни пользовательский классы. пишутся они вручную.

но мне было инетересно зачем создали тогда вендор класс »

обрати внимание на специфические опции например: адреса серверов Х. это для клиента *никсов и смысла нет передавать их винде. так же как и опции относящиеся к нетбиосу(приимущественно это к виндовому взаимодействию) передпвать кленту на *никсах.
судя по всему это и было сделано чтоб гиганские пакеты с порой ненужной информацией не гуляли по сети. а каждому клииенту передовалась только ему необходимая часть. логично?
почему два класса? ну тот что руками настраевается(пользовательский) это понятно - удобно. сам администратор настраевает вручную. но если сеть большая? очень большая? тут на помощ приходит вендор класс. уверен у разных винд он разный. ну я имею ввиду это самое "5.0" вот и работы уменьшилось.

а теперь вопрос в зрительный зал.) кто нить использовал данную возможность на практике?(если вдруг кто то знающий заглянет в пост)

значит тема остаётся открытой.)