уже ближе к делу. сейчас проанализирую пакеты на наличие ID определенного вендора(пусть даже виртуальной вмваре), вот только нетворк монитор незапускается, как что нибудь выясню отпишусь.DHCP (Define vendor classes).
-
minion
Re: DHCP (Define vendor classes).
wertyg,
уже ближе к делу. сейчас проанализирую пакеты на наличие ID определенного вендора(пусть даже виртуальной вмваре), вот только нетворк монитор незапускается, как что нибудь выясню отпишусь.
уже ближе к делу. сейчас проанализирую пакеты на наличие ID определенного вендора(пусть даже виртуальной вмваре), вот только нетворк монитор незапускается, как что нибудь выясню отпишусь.-
wertyg
Re: DHCP (Define vendor classes).
да без резервирования вроде не обойтись.(
для пояснения немного вспомним как работает ДХСП. я не буду подробно обьяснять и рассматривать все возможные варианты развития событиий, всё это можно прочитать в инете, а возьму самый простой.
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
для пояснения немного вспомним как работает ДХСП. я не буду подробно обьяснять и рассматривать все возможные варианты развития событиий, всё это можно прочитать в инете, а возьму самый простой.
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
Re: DHCP (Define vendor classes).
wertyg,
Задача решима тем же самым резервированием, но мне было инетересно зачем создали тогда вендор класс, а вот client class information все же есть в пакете дхсп, и я почти уверен что он являеться ИД железки, или клиента дхсп как ты говарил. Просто нет железок что бы это все проверить(
Задача решима тем же самым резервированием, но мне было инетересно зачем создали тогда вендор класс, а вот client class information все же есть в пакете дхсп, и я почти уверен что он являеться ИД железки, или клиента дхсп как ты говарил. Просто нет железок что бы это все проверить(
-
wertyg
Re: DHCP (Define vendor classes).
minion, ну так я проверил. это таки
Цитата minion:
клиента дхсп как ты говарил
о чем и написал
Цитата wertyg:
вендор класс это опция номер 60. я так понял это производитель программы клиента ДХСП решает быть ей или нет. и соответственно она меняеться в зависимости от операционки(класс разработчика клиента) а не от производителя железа. например клиент ДХСП в голой FreeBSD
во Freebsd не передаёться по умолчанию ни вендор ни пользовательский классы. пишутся они вручную.
Цитата minion:
но мне было инетересно зачем создали тогда вендор класс
обрати внимание на специфические опции например: адреса серверов Х. это для клиента *никсов и смысла нет передавать их винде. так же как и опции относящиеся к нетбиосу(приимущественно это к виндовому взаимодействию) передпвать кленту на *никсах.
судя по всему это и было сделано чтоб гиганские пакеты с порой ненужной информацией не гуляли по сети. а каждому клииенту передовалась только ему необходимая часть. логично?
почему два класса? ну тот что руками настраевается(пользовательский) это понятно - удобно. сам администратор настраевает вручную. но если сеть большая? очень большая? тут на помощ приходит вендор класс. уверен у разных винд он разный. ну я имею ввиду это самое "5.0" вот и работы уменьшилось.
а теперь вопрос в зрительный зал.) кто нить использовал данную возможность на практике?(если вдруг кто то знающий заглянет в пост)
значит тема остаётся открытой.)
Цитата minion:
клиента дхсп как ты говарил
DHCP (Define vendor classes).
о чем и написал
Цитата wertyg:
вендор класс это опция номер 60. я так понял это производитель программы клиента ДХСП решает быть ей или нет. и соответственно она меняеться в зависимости от операционки(класс разработчика клиента) а не от производителя железа. например клиент ДХСП в голой FreeBSD
DHCP (Define vendor classes).
во Freebsd не передаёться по умолчанию ни вендор ни пользовательский классы. пишутся они вручную.
Цитата minion:
но мне было инетересно зачем создали тогда вендор класс
DHCP (Define vendor classes).
обрати внимание на специфические опции например: адреса серверов Х. это для клиента *никсов и смысла нет передавать их винде. так же как и опции относящиеся к нетбиосу(приимущественно это к виндовому взаимодействию) передпвать кленту на *никсах.
судя по всему это и было сделано чтоб гиганские пакеты с порой ненужной информацией не гуляли по сети. а каждому клииенту передовалась только ему необходимая часть. логично?
почему два класса? ну тот что руками настраевается(пользовательский) это понятно - удобно. сам администратор настраевает вручную. но если сеть большая? очень большая? тут на помощ приходит вендор класс. уверен у разных винд он разный. ну я имею ввиду это самое "5.0" вот и работы уменьшилось.
а теперь вопрос в зрительный зал.) кто нить использовал данную возможность на практике?(если вдруг кто то знающий заглянет в пост)
значит тема остаётся открытой.)