sav_ua (05.12.2012 10:52, просмотров: 8902)-
- еще одно, на старом форуме cygnal.org некий гуру (по всей видимости относящийся к писателям данных библиотек) sav_ua(274 знак., 05.12.2012 15:43)
- Это проблема DHCP сервера а не клиентов. Нормальный DHCP сервер сначала проверяет свободен ли IP а потом его выдает. У вас на чем поднят DHCP сервер? на маршрутизаторе? тогда какой у вас маршрутизатор? - OlegPowerC(05.12.2012 14:00)
- проверял на длинк-300, заказчик проверял еще на каком-то... - sav_ua(05.12.2012 15:34)
- Это проблема клиента, а не сервера: клиент принимает чужой IP за свой, так как не проверяет MAC адрес. Ещё варианты? - SciFi(05.12.2012 14:26)
- это запросто: СР220х не фильтрует аппаратно младший байт МАС koyodza(411 знак., 05.12.2012 15:12)
- В сервере тупо ошибка: параллельные запросы обрабатываются в параллельных потоках, например, и не обновляет синхронно список занятых адресов. Почему не вариант? Я имел ввиду, что сервером может выступать дешёвый роутер и качество ПО там может fk0(52 знак., 05.12.2012 14:40)
- Вот и я того же мнения - сервер заменить на другой и проверить. - OlegPowerC(05.12.2012 14:43)
- Тоесть клиент не проверяет кому DHCP пакет от сервера пришел? (там кстати не только мак адрес, но и некая последовательность есть). Если так то переписать DHCP клиента, могу дать исходники своего. - OlegPowerC(05.12.2012 14:30)
- Если не сложно давай - Diele(05.01.2013 13:53,
)
- OK сегодня пороюсь и постараюсь выложить - OlegPowerC(11.01.2013 16:18)
- Если не сложно давай - Diele(05.01.2013 13:53,
- Попробовать другой DHCP-сервер. Возможно, проблема в нём. Причём, лучше, софтовый (для ПК) с включенными функциями диагностики. - fk0(05.12.2012 13:03)
- Ввести задержку после включения питания до старта DHCP. Для каждого устройства должны быть разные, например пропорционально младшим знакам серийного номера. - Roman M.(05.12.2012 12:44, )
- :) такой вариант рассматривался, но если питание пропадет и на приборчиках и на роутере, то пока роутер войдет в сеть, все задержки закончатся и железяки, опять-таки, будут ломиться в него почти одновременно. - sav_ua(05.12.2012 13:06)
- Возможно, что глюкавый 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)
- :) такой вариант рассматривался, но если питание пропадет и на приборчиках и на роутере, то пока роутер войдет в сеть, все задержки закончатся и железяки, опять-таки, будут ломиться в него почти одновременно. - sav_ua(05.12.2012 13:06)
- Чтобы не гадать, надо сниффером посмотреть. Wireshark в помощь. - SciFi(05.12.2012 11:45)