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 по этому поводу написано.

Есть RFC и этого достаточно, что бы не плодить своих "стандартов" и оставлять потомкам счастье разгребать нашу самодеятельность. Задержка конечно будет. И она предусмотрена в RFC и соответственно в клиентах. [-Alt-], спасибо. Да, похоже что бага в логике сервера. Буду смотреть сегодня/завтра. Дампы трафика всё равно не помешают.

Сейчас не хочется. Не думаю что это реально сузит область поиска. Это какой-то недокэш ИМХО :) Но хуже от этого не станет. В самом плохом случае - мы просто не получим ICMP echo response от уже существующего адреса и тогда клиент нам пришлёт DHCPDECLINE. В лучшем - сразу разберёмся что там что-то не так, может даже предложим другой адрес.

Вот оно так и сделано. Тем методом которым мне это видится разумным. Не вижу резона делать иначе. Очень ОС зависимо, придётся под каждую ОС свой код писать, при чём не самый тривиальный. Оставлено на далёкое и счастливое коммунистическое будущее. Я уже описал в чём проблемы подобного подхода. Перед тем как давать такие советы - не плохо бы почитать документацию на libpcap ;) Не все ОС имеют возможность использования select'образных функций с pcap сокетами. Только не надо предлагать отказываться от использования libpcap. Сейчас заботы о портировании в нативный код для конкретной ОС на плечах libpcap и её разработчиков, велосипедировать не собираюсь. Да и опять же, как показывает жизненный опыт - код использующий select (и подобное) становится сложнее для понимания и отладки при весьма слабом (в пределах нескольких процентов) выигрыше по ресурсам/скорости. В данном случае скорость практически не важна и от выигранных долей миллисекунд мы ничего не получим - это не hi-load продукт предназначенный для обработки десятков килоRPS (как nginx например). Не очень понимаю как это может помочь. Искать багу надо в условиях максимально приближённых к реальным. Может быть. Только наверное имелось ввиду DUID. Но в принципе то что есть сейчас должно работать нормально не зависимо от версии клиента (если я ночью не налажал в коде :) ). Такой кэш будет работать только для первого DHCPREQUEST от данного клиента. Следующие DHCPREQUEST генерируются с другим xid. Коли уж говорим о соответствии RFC, то делать всё а не то что проще/понравилось. Удивительно... Но я всё равно не люблю FreeBSD :) 1. Не грамотный пользователь в таком софте всё равно обязательно что-нибудь сломает. 2. Функция to_cidr используется только в 2х местах и данные которые она обрабатывает предоставляются libpcap. Уж если там будут маски с "дырками", то можно сразу убиваться. Ну вообще в todo написано про то что надо делать QueryRej если клиент выбрал другой север, и ориентироваться всегда предполагалось именно на это. Всем всем: выяснил, бага описанная выше (выявляющаяся при подсчёте udp checsum) не связана с последними правками, в предыдущей версии тоже было. Так что хуже чем в прошлой версии быть не должно. Ну а багу - конечно буду выковыривать... [-Alt-], для начала проверьте новую версию, может это было из-за баги в работе кэша (хотя если кэш по прежнему не используется то нет смысла). Если не поможет то пожалуйста сделайте следующее: 1. Запустите с debug логом. Весь лог проблемной транзакции мне на мыло. 2. Сделайте пожалуйста бинарный дамп проблемной DHCP транзакции через tcpdump -s0 -w dump-file <filter>. Фильтр должен быть такой что бы было видно и запросы и ответы, лучше пусть будет что-то лишнее, сам если что потом отфильтрую. Полученный dump-file тоже мне на мыло.

На IP адрес указанный в giaddr не зависимо от IP адреса с которого пришёл пакет. Ethernet адрес разумеется будет использован тот с которого получен пакет. Новая версия: http://netpatch.ru/projects/db2dhcp/db2dhcp-0.1.a.6.tar.bz2 Изменения: Изменения в работе кэша - переделана функция сравнения и поиска кэшированных ответов. Устранён мелкий баг позволяющий дважды два раза добавить запрос в очередь от одного и того же клиента. Добавлено отладочного вывода при работе с кэшом. Если будут продолжаться проблемы - надеюсь поможет. Был замечен какой-то баг при расчёте udp checksum (valgrind ругнулся, но ничего не упало), в итоге в ответе клиенту улетело что-то неправильное и он его не смог обработать. Случается похоже крайне редко. Буду разбираться. PS Что-то плохо работает голова уже, эта версия могла получиться более бажной чем предыдущая ;) Возможно багу с подсчётом udp checksum сейчас добавил. Но проверить надо, и без кэша, и особенно - с кэшом. PPS [-Alt-] 0.0.0.0 потому что DHCPNAK. А вот почему DHCPNAK исходя из лога понять сложно, по дампу вроде всё правильно, надо в код смотреть. Выше ни каких строчек по этому поводу не было? Проблема проявляется с данным клиентом постоянно? Уже нет сил разбираться сейчас...

Может и так. Просто "в соседнем топике" обсуждается сервер который именно так и делает (+ выборка типа данных) ;) Думаю вы уже заметили, коли достаточно бдительно смотрели в код.

Ну в общем-то "на манер" это не равно "точно так же" ;) Имеется ввиду интерфейс аллокатора, а не внутренняя реализаци. И: Если бы всё было так просто - ни кто не городил бы мультипоточного приложения ;) Очередь тут вовсе не для защиты от переполнения. Очередь служит для асинхронной работы потоков слушающих интерфейсы и потоков работающих с БД. Узлы в неё добавляют потоки-"слушатели" интерфейсов, а разбирают очередь - потоки работающие с БД. Сделано так потому что запросы к БД в общем случае в API разных СУБД синхронны и блокируют поток пока не будет получен результат из базы. Рассказать чем это чревато при медленной работе БД и попытках выполнять эти запросы в том же потоке что слушает интерфейс? В случае с очередью и отдельными потоками работающими с БД несколько залипших запросов (а такое бывает на нагруженных серверах) не заблокируют насмерть сервер, и значение это можно поставить достаточно большим. На многоядерной БД - очень выручит. rd он на то и rd что бы можно было делать много вхождений в один участок, а не ждать когда другой поток там что-то сделает. Не надо трактором грядки пахать. Отключить очистку и ждать когда процесс опухнет и будет убит по перееданию памятью? Тогда можно вообще не пробовать искать утечки памяти - кэш сам по себе будет одной большой утечкой :) Включить реже - значит будет падать но не через несколько часов, а через несколько дней например. Это всё не решения а костыли, неприемлемо. Если не пойму в чём дело то лучше попробую RB Tree от MIT. Вот это кстати очень полезное замечание объясняющее ситуацию с адресами FF:FF:FF:FF:FF:FF в кэше! Там именно адрес заголовка, получилось так потому что изначально код (ещё когда-то очень давно) писался без использования relay агента и в принципе эти значения были эквивалентны, что конечно же верно совсем не всегда. А потом кэш был набросан быстро за один-два вечера и получился ляп. :( Широковещательный адрес в кэше при таком раскладе может оказаться если от локального клиента (без релея) пришло сообщение с установленным флагом Broadcast. Честно говоря мне теперь самому не совсем понятно как кэш умудрялся правильно работать при использовании relay. А как вам такой сценарий развития событий? void dhcp_cache_flush_old(void) { time_t tm_now = time(NULL); if(cache_last_flush + CACHE_FLUSH_PERIOD > tm_now) { return; } /* В этом месте поток А вошедший в функцию, проверивший условие и решивший что ему надо чистить кэш останавливается планировщиком не успев заблокировать кэш и процессор переключается на поток Б. Поток Б тоже входит в выполнение этой функции, проверят условие, видит что оно не верно и нужно чистить кэш. Блокирует кэш и начинает его чистить. После чего тоже останавливается где-то в середине зачистки по переключению например на поток В. После чего управление переходит к потоку А, который просыпается и... Блокируется на вызове cache_wrlock() т.к. её уже выполнил поток Б ныне спящий и по прежнему блокирующий кэш. После чего Б пробуждается, дочищает кэш, снимает блокировку. В итоге поток А опять получает управление, радостно входит в блокировку кэша на запись и пытается почистить только что очищенный кэш. В это время все остальные потоки работающие с кэшом будут ждать пока поток А выполнит уже не нужную операцию зачистки кэша. */ cache_wrlock(); cache_now = tm_now; cache_last_flush = cache_now; Потому сделано так, а не иначе. Например потому что в разных системах эти файлы могут называться немного по разному, как и структуры в них. Да, это можно вылечить при помощи autoconf. Только вот есть проблема - в некоторых ОС этих файлов нет вообще ;) Не совсем так. В RFC написано что сервер должен проверить то что адрес свободен например через ICMP echo request. Но вовсе не обязательно при помощи его. Учитывая что Windows по дефолту старается это заблокировать (как и большинство фаерволлов под неё) - проверка ARP'ом более уместна. Конечно она не реализуема при использовании relay. По возможности допишу проверку через ICMP в случае использования relay, но честно говоря это почти ничего не даст. Вообще не знаю есть-ли смысл писать под что-то отличное от Ethernet, много об этом думал. Хотя для приличия стоит сделать проверку. Брать проверки из FreeBSD либо откуда-то ещё не вижу смысла т.к. они абсолютно примитивны и их реализация - вопрос наличия у меня свободного времени. Да, согласен, там весьма убогий кусок кода и я знаю как делать правильно. Но сделано так потому что "лишь бы работало". Последние версии в виндах вообще не пробовал собирать (PG библиотеки лень ставить), буду собирать когда доведу до ума весь задуманный функционал. Да, именно так. И об этом я тоже знаю. А вы - представляете себе _нормальные_ сетевые маски у которых может быть 0 в середине? Верно замечено - местами вообще ничего не проверяется. Вы даже можете создать переменную в конфигурации со смещением в 100к и длинной в 1 Мб и сервер её съест, после чего вполне вероятно упадёт при обработке запроса.Ещё раз отсылаю вас в первое сообщение этого топика, в котором написано что это очень тестовый код. А так же в раздел "Планируемые доработки" где написано что сервер должен быть приведён в соответствие с требованиями RFC. Сейчас интересно оттестировать базовый (и самый нужный 99% потенциальных пользователей) функционал и убедиться что программа ведёт себя адекватно. Как видите - ряд явных неадекватностей уже успешно выпилен, похоже осталось только с кэшом разобраться. После чего можно будет добавить несколько запрошенных фич (благо они простые), остановить добавление функционала и доводить его до лоска и блеска штудируя в одном окне код, а в другом RFC. Спасибо за подсказку про кэш, но на будущее - предлагаю подобные беседы переносить в e-mail или какой-нибудь IM что-ли, кроме обнаружения явных и 100%ных багов. А то у нас длинный и малоинформативный для большинства читающих тред получается. Всё что найдёте - ваше :) Т.е. будет опубликовано вместе со следующей версией.

Позволю себе вмешаться. dhcpsql есть давно, и соседний топик про тоже самое только с нуля. Не лукавьте. Вы сами пробовали dhcpsql который "есть давно"? Помнится я пытался его когда-то запустить:1. Конфигурабельности - 0. Даже configure не задумано. И настроить гибко на работу с базой тоже вроде не тривиально (давно было, но хороших впечатлений не осталось). 2. Работает только с MySQL. 3. Сборка в FreeBSD: $ make "Makefile", line 32: Need an operator **** много таких строчек **** make: fatal errors encountered -- cannot continue Так что это - не "тоже самое только с нуля". Ну... Мы об этом уже говорили. Мне кажется, или где-то я это уже видел?.. ;)

Voronok, спасибо. Похоже что действительно дело в кэше, у -Alt проработал нормально почти двое суток и не падал пока он сам его не потушил. Правда я так и не могу понять что же делаю не так со стандартными функциями работы с деревьями. Наверное какая-нибудь очередная недокументированная фича... Похоже что придётся самому полностью писать механизм кэширования. PS Внёс небольшие правки в код, на функционал ни как не влияет но функция подсчёта контрольной суммы на некоторых компиляторах выдавала warning'и потому код не собирался (из-за установленной опции -Werror). Теперь должно собираться везде. Версию оставил ту же.

Ну как, у кого-нибудь есть какие-нибудь плохие или хорошие новости?

Voronok, когда снова грохнется (а он наверное грохнется всё же) - можешь запустить с отключенным кэшированием? (DHCPCacheTTL = 0) Очень хочется понять - бага действительно в кэше или что-то где-то в другом месте не правильно работает и повреждает данные кэша из-за чего и происходит сегфолт. Если второй случай - то скорее всего отключение кэша ничего толком не даст и через какое-то время всё равно процесс рухнет. Если же будет работать стабильно (хотя и сильнее нагружать БД), то видимо придётся ещё раз перековырять кэш, может даже отказаться от штатных бинарных деревьев и по своему написать. В любом случае, будет интересно посмотреть вывод gdb на core дамп файл от процесса. Сделать надо так: $ gdb /path/to/db2dhcp -c /path/to/core.dump *** тут всякая мишура, на всякий случай лучше тоже скопировать *** > bt <enter> - самое важное то что будет после этого. [-Alt-], отлично! Кстати на сколько я понимаю - у вас кэширование выключено. Тем лучше, будет проверкой версии о бажности именно кэша. Сейчас изо всех сил пытаюсь уронить демона - создал в БД 2048 псевдоклиентов с разными MAC адресами и запустил процесс получения IP адресов от них через dhcdrop в 8 потоков. В итоге получилось порядка 50 DHCP запросов в секунду (и соответственно столько же ответов), сервер работает уже несколько часов, написал мне более пол гига логов, регулярно чистит кэш (за раз удаляя примерно 70 узлов) и при этом упорно не желает падать. Подозреваю это от того что синтетический тест не реализует всех возможных ситуаций- например DHCPINFORM/DHCPRELEASE сообщений и общего "шума" в сети который тоже может несколько повлиять на работу. В общем - пока подожду ваших результатов.