sav_ua (05.12.2012 13:06, просмотров: 76) ответил Roman M. на Ввести задержку после включения питания до старта DHCP. Для каждого устройства должны быть разные, например пропорционально младшим знакам серийного номера.-
- Возможно, что глюкавый DHCP клиент в этих lib файлах. Можно сделать надстройку над протоколом, чтобы железки договаривались между собой об очерёдности отправки запросов DHCP на основании своих MACов. - SciFi(05.12.2012 13:43)
- то, что глюкавый - почти очевидно, слабо представляю себе такие "договоры" между железками - sav_ua(05.12.2012 13:48)
- Не надо никаких договоров между железками, это пред полнейший, для решения конфликтов протокол предусматривает стандартные механизмы в виде базы данных на стороне сервера, ограниченном времени аренды адресов и маркировкой пакетов запрос-ответ OlegPowerC(171 знак., 05.12.2012 14:39)
- Лучше, конечно, выбросить фтопку глюкавые библиотеки и написать свой DHCP клиент, это довольно просто. А по поводу "договоров": SciFi(781 знак., 05.12.2012 14:25)
- Вообще то это забота DHCP сервера. Железка только спрашивает "хочу адрес" или может добавить "желательно такой", а сервер должен все проверить и выдать тот который она просит если он свободен, либо другой если он занят. Я не знаю таких клиентов OlegPowerC(161 знак., 05.12.2012 14:29)
- Вы ветку читали? Подсказка: она начинается тут -> - SciFi(05.12.2012 14:32, ссылка)
- Да, все прочитал, теперь внимание вопрос, почему с вашей точки зрения не правильно работает клиент а не сервер? я нигде не увидел чтоб гдето говорилось что он принимает ответы на чужие запросы за свои, если это так то выше уже написал. - OlegPowerC(05.12.2012 14:35)
- Это предположение, которое полностью объясняет все факты. Собственно, предположение про глюкавый сервер тоже объясняет. Но кривизна библиотек в клиенте гораздо вероятнее, чем кривизна маршрутизатора. - SciFi(05.12.2012 14:39)
- Да что вы? если это DDWRT то не факт, там глюков вагон, знаем видели. Про сервер уже отписал, у DHCP два режима работы - либо все broacast либо только запросы а ответы на них unicast с вашим MAC адресом, таким образом другие железки его не получат OlegPowerC(39 знак., 05.12.2012 14:41)
- Логично, черт возьми. Ну где, где этот топикстартер с логом пакетов из Wireshark? Не томи уже! :-) - SciFi(05.12.2012 14:46)
- железа сейчас под рукой нет - sav_ua(05.12.2012 15:28)
- Как всегда, на самом интересном моменте автор топика слился :-) - OlegPowerC(05.12.2012 14:47)
- Логично, черт возьми. Ну где, где этот топикстартер с логом пакетов из Wireshark? Не томи уже! :-) - SciFi(05.12.2012 14:46)
- Да что вы? если это DDWRT то не факт, там глюков вагон, знаем видели. Про сервер уже отписал, у DHCP два режима работы - либо все broacast либо только запросы а ответы на них unicast с вашим MAC адресом, таким образом другие железки его не получат OlegPowerC(39 знак., 05.12.2012 14:41)
- Это предположение, которое полностью объясняет все факты. Собственно, предположение про глюкавый сервер тоже объясняет. Но кривизна библиотек в клиенте гораздо вероятнее, чем кривизна маршрутизатора. - SciFi(05.12.2012 14:39)
- Да, все прочитал, теперь внимание вопрос, почему с вашей точки зрения не правильно работает клиент а не сервер? я нигде не увидел чтоб гдето говорилось что он принимает ответы на чужие запросы за свои, если это так то выше уже написал. - OlegPowerC(05.12.2012 14:35)
- Вы ветку читали? Подсказка: она начинается тут -> - SciFi(05.12.2012 14:32, ссылка)
- Вообще то это забота DHCP сервера. Железка только спрашивает "хочу адрес" или может добавить "желательно такой", а сервер должен все проверить и выдать тот который она просит если он свободен, либо другой если он занят. Я не знаю таких клиентов OlegPowerC(161 знак., 05.12.2012 14:29)
- то, что глюкавый - почти очевидно, слабо представляю себе такие "договоры" между железками - sav_ua(05.12.2012 13:48)
- Возможно, что глюкавый DHCP клиент в этих lib файлах. Можно сделать надстройку над протоколом, чтобы железки договаривались между собой об очерёдности отправки запросов DHCP на основании своих MACов. - SciFi(05.12.2012 13:43)