RomanCh

Гм, случилась какая-то незадача с хостингом - содержимое сайта там есть, но не показывается, разбираюсь. В ближайшие дни будет новая сборка, с поддержкой FB и выполнением внешних скриптов.

Вообще-то изначально задумывалось именно как сервер работающий с СУБД. А получается правда какой-то комбайн если все пожелания выполнить :) Если скрипты только оставить - откуда данные серверу брать? А поддержку скриптов как правильно вкрутить - подумаю, может и на этапе конфигурирования, хотя по сути там же всё будет на стандартных библиотеках, так что это не так актуально как с поддержкой БД. Ну, вообще-то "универсального" изначально не задумывалось.

Включённый кэш спасёт ваш умучанный тяжкими трудами sql сервер :) Из личного опыта могу сказать что один не шибко мощный сервер без особых вопросов обслуживает порядка 10к клиентов без особых напрягов если включено кэширование. При этом он ещё и другими делами занимается. Ну так вас ни кто и не просит писать, пишу я :) Вообще пробовали эти варианты, но по указанным выше причинам многих они не удовлетворяют. Да, это обязательно будет доработано. Да, было бы интересно подумать кто что хочет видеть. Лично я вижу это так: 1. Скрипты могут быть pre/post типов. Т.е. запускающиеся перед выполнением запроса в БД и после запроса. 2. Выполнение скриптов может быть синхронным и асинхронным. Код возврата выполнения асинхронных скриптов не учитывается, код возврата выполнения синхронных скриптов может учитываться и на основании его может быть принято решение делать или нет запрос в БД (что-нибудь ещё может?) 3. В скрипты могут быть переданы статические параметры (задано в конфиге) и динамические - те же переменные что используются в запросах.

Рассматриваю конечно :) Но только после того как будет в общих чертах всё работать правильно. Как раз к концу года надеюсь и до IPv6 дойдут руки.

Так их и не надо заводить. Сервер пойдёт в БД за данными, ничего там не найдёт и "промолчит" на запрос от неизвестного клиента. Или я не понял что всё-таки имелось ввиду :)

Ну, вероятно как и любой другой процесс в unix-like системе :) kill <process_pid> или killall db2dhcp Да, кстати надо будет не забыть сделать что бы демон pid свой писал в файл. Зачем? Если сервер не обслуживает запросы с какого-либо интерфейса, то он просто не должен находить для них данных в базе, а значит и ответов клиентам тоже не будет. Что-то я подзашился в делах своих, но вот выкроил ещё время. Новая версия: http://netpatch.ru/projects/db2dhcp/db2dhcp-0.1.a.9.tar.bz2 Внешних изменений в общем-то ни каких нет. Но кэш теперь базируется на RBTree. Кажется помогло со странностями, хотя пока что мало тестировал, рано делать выводы. Всем заинтересованным просьба проверить работу сервера с кэшом.

Rupreht, я правильно понимаю что вас смущают вот эти строки: Т.е. не соответствие MAC адресов? Посмотрел в код, там на самом деле логическая неувязка. После слов "for client" пишется не MAC адрес клиента, а MAC адрес хоста доставившего запрос непосредственно серверу. Т.е. в вашем случае - это адрес агента пересылки. В общем-то на работу ни как не влияет, в сеть уходит пакет с правильными данными. В коде багу поправил, в следующей версии её не будет. Или в чём-то ещё была проблема? Если да, то пожалуйста мне дамп трафика (tcpdump -i ... -nvvves0 port 67) на почту. Изучу. Но вообще - кэш действительно какой-то странный (хотя приведённая бага к этому не относится), заменяю механизм хранилища. Пока лучше работать без кэша.

value должно быть в 16тиричном виде. Т.е. все числа переводим в 16тиричное представление. Правильное значение можно получить например так: $ perl -e '@a = (16,172,16,10,16,40,100); foreach (@a) { printf("%02x", $_) } ; print "\n"' 10ac100a102864 Про работу с включённым кэшом - Voronok проверил, падает по прежнему. Буду переделывать на rbtree.

Исправление: http://netpatch.ru/projects/db2dhcp/db2dhcp-0.1.a.8.tar.bz2 Нашёл и убрал багу которая иногда портила пакеты и отправляла в сеть случайные данные. Появилась после добавления "зеркалирования" опции 82 сервером обратно в relay. Больше пока вроде бы ни каких багов не находится. С кэшем кто-нибудь тестировал работу?

Лучше так не делать. Потому что даже если поможет - через неделю юзер переустанавливает винды и всё начинается с начала. Новая сетевуха как мне кажется стоит гораздо меньше потенциально возможных проблем.

К сожалению на этих выходных всё-таки не получилось серьёзно поработать над кодом. Но исправлена вот эта бага: Результат: http://netpatch.ru/projects/db2dhcp/db2dhcp-0.1.a.7.tar.bz2

Если меняются только первые два октета адреса, то исходя из моего опыта есть два варианта: 1. Шибко умный абонент который зачем-то делает это руками. Может где-то банится и пытается получить другой адрес по DHCP, например. 2. Глючная сетевуха. Бывают такие - могут при каждой перезагрузке менять MAC адрес. Вывод - лучше всего позвонить юзеру и попробовать узнать что там у него происходит.

Вы можете получить любое поле из заголовка DHCP запроса клиента и любую опцию (а так же её часть по выбранному смещению) и использовать полученные данные в SQL запросе. Это значит что да - можно по ID VLAN работать, можно по MAC адресу клиента, можно по порту, можно по ID коммутатора, можно по IP адресу релея (коммутатора). Вообще по любым данным переданым в DHCP запросе клиентом (релеем).Почитайте документацию, не поленитесь :) Там написано как это делается. Раздел про "Пользовательские переменные". Кроме того есть встроенные переменные сервера в которые входят например имя, адрес, маска интерфейса на котором получен запрос, и их тоже можно использовать в SQL выражениях. На сайте нет в примере VLAN ID потому что при подобной гибкости функционала в принципе нереально наверное привести все возможные конфигурации. Нужно просто понять принцип по которому можно строить запросы. Остальное - зависит от вашей фантази. Ну мой тестовый стенд - Linux (настоящий) или FreeBSD (в виртуалке), dhcrelay от ISC, для проверки работы с опцией 82 - свитч D-Link 3526. Конфиг - см. документацию. База разумеется строго тестовая. Как и конфиг - для демонстрации основных возможностей. Поняв принцип - сами с лёгкостью напишете и конфиг и запросы. У кого-нибудь есть результаты испытаний последней версии с включённым кэшом? На выходных будет время заниматься устранением багов, потому лучше о них сообщить сейчас.

Налицо косяк в обработке запроса с установленным флагом Broadcast пришедшим через relay. Хотя вроде прорабатывал ситуацию но видимо что-то недоглядел. Спасибо, поправлю. А про DHCPNAC - на самом деле очень интересно почему клиент на него не реагировал. Надо будет попробовать как-то воспроизвести эту ситуацию. У меня клиенты после получения DHCPNAK переставали использовать перезапрашивали адрес. Может опять что-то недоработано с использованием relay - без relay отправка DHCPNAK должна производиться на широковещательный адрес, возможно что и с relay броадкастит, потому ничего не получается. Не помню тестировал-ли такую ситуацию через него. UPD На счёт неправильной udp checksum от ISC - честно говоря не понимаю почему так у вас получается. По идее пакет с битой чексуммой должен быть отброшен клиентом (виндовый не проверял а dhcpcd действительно отбрасывает их). Если сервер её не рассчитал то он должен установить там 0. Ну да ладно, это к счастью чужие проблемы :)

Мельком глянул сейчас, не удержался. По идее такое может происходить только при соблюдении условия: if(*requested_ip != offered_ip) opt_pt = set_dhcpnak(&dhcp_packet->dhcp_data, server_id); Т.е. получается что клиент запрашивает не то что ему предложили. Дамп обязательно надо посмотреть. И наверное надо внимательно мне посмотреть что в RFC по этому поводу написано.