Перейти к содержимому
Калькуляторы

RomanCh

Активный участник
 Просмотреть профиль  Активность

  • Публикации

    108

  • Зарегистрирован

  • Посещение

 Тип публикации 

Сообщения, опубликованные пользователем RomanCh

  1. Опубликовано · Жалоба на ответ

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

  2. Опубликовано · Жалоба на ответ

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

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

    А поддержку скриптов как правильно вкрутить - подумаю, может и на этапе конфигурирования, хотя по сути там же всё будет на стандартных библиотеках, так что это не так актуально как с поддержкой БД.

    а универсальный dhcp сервер.

    Ну, вообще-то "универсального" изначально не задумывалось.

  3. Опубликовано · Изменено пользователем RomanCh · Жалоба на ответ

    Согласен, но ей далеко не по барабану, как часто это делается. В случае выполнения тяжёлого запроса одним из клиентов БД, дополнительные маленькие запросы DHCP в этот момент могут тупо уложить сервак БД на несколько минут (может и дольше), нагрузка на проц будет возрастать по экспоненте, вы сами можете себе представить вероятные последствия этого.

    Включённый кэш спасёт ваш умучанный тяжкими трудами sql сервер :) Из личного опыта могу сказать что один не шибко мощный сервер без особых вопросов обслуживает порядка 10к клиентов без особых напрягов если включено кэширование. При этом он ещё и другими делами занимается.

     

    А напрямую в базу... Да, красиво - поменяли мак, сразу перевыдалось... Но стоит ли? Мне как то проще использовать стандартный демон, чем писать свое ;)

    Ну так вас ни кто и не просит писать, пишу я :) Вообще пробовали эти варианты, но по указанным выше причинам многих они не удовлетворяют.

     

    ' timestamp='1303757210' post=608972]

    минус пока тока один, нужна поддержка в сервере резервного линка к базе.

    Да, это обязательно будет доработано.

     

    В продолжение разговора о скриптах добавлю своих предложений, возможно ктото присоединится к моему пожеланию

    Да, было бы интересно подумать кто что хочет видеть.

     

    Лично я вижу это так:

    1. Скрипты могут быть pre/post типов. Т.е. запускающиеся перед выполнением запроса в БД и после запроса.

    2. Выполнение скриптов может быть синхронным и асинхронным. Код возврата выполнения асинхронных скриптов не учитывается, код возврата выполнения синхронных скриптов может учитываться и на основании его может быть принято решение делать или нет запрос в БД (что-нибудь ещё может?)

    3. В скрипты могут быть переданы статические параметры (задано в конфиге) и динамические - те же переменные что используются в запросах.

  4. Опубликовано · Жалоба на ответ

    адресов протокола v4 уже не хватит до конца года, не рассматриваете возможность поддержки протокола v6?

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

  5. Опубликовано · Изменено пользователем RomanCh · Жалоба на ответ

    Возможно - для того, чтобы сервер не молчал на неизвестные ИП, а слал реджекты, дабы DHCP подсети сторонние не заводились?

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

  6. Опубликовано · Жалоба на ответ

    1. Запустил сервер командой: ./db2dhcp -o db2dhcp.conf eth0, а как его остановить без перезагрузки?

    Ну, вероятно как и любой другой процесс в unix-like системе :) 

    kill <process_pid>

    или 

    killall db2dhcp

    Да, кстати надо будет не забыть сделать что бы демон pid свой писал в файл.

     

     

    2. Как в конфиге выставить: authoritative

    Зачем? Если сервер не обслуживает запросы с какого-либо интерфейса, то он просто не должен находить для них данных в базе, а значит и ответов клиентам тоже не будет.

     

    Что-то я подзашился в делах своих, но вот выкроил ещё время.

    Новая версия: http://netpatch.ru/projects/db2dhcp/db2dhcp-0.1.a.9.tar.bz2

    Внешних изменений в общем-то ни каких нет. Но кэш теперь базируется на RBTree. Кажется помогло со странностями, хотя пока что мало тестировал, рано делать выводы.

    Всем заинтересованным просьба проверить работу сервера с кэшом.

  7. Опубликовано · Жалоба на ответ

    Rupreht, я правильно понимаю что вас смущают вот эти строки:

    2011-03-29 17:01:58 [40737:34376864192] Found response for client 00:19:5B:14:7D:82 from relay 10.1.1.2 in DHCP cache.
2011-03-29 17:01:58 [40737:34376559296] Sending DHCPACK (5) to 00:1B:11:B5:DE:D5/10.1.1.252 via 10.1.21.104 (relay 10.1.1.2)
requests: 0

    Т.е. не соответствие MAC адресов? Посмотрел в код, там на самом деле логическая неувязка. После слов "for client" пишется не MAC адрес клиента, а MAC адрес хоста доставившего запрос непосредственно серверу. Т.е. в вашем случае - это адрес агента пересылки. В общем-то на работу ни как не влияет, в сеть уходит пакет с правильными данными. В коде багу поправил, в следующей версии её не будет.

     

    Или в чём-то ещё была проблема? Если да, то пожалуйста мне дамп трафика (tcpdump -i ... -nvvves0 port 67) на почту. Изучу.

     

    Но вообще - кэш действительно какой-то странный (хотя приведённая бага к этому не относится), заменяю механизм хранилища. Пока лучше работать без кэша.

  8. Опубликовано · Жалоба на ответ

    А тут попробовал в базе добавить эти маршруты, type=3, а в value=16, 172,16, 10,16,40,100

    И никак не отдает...

    value должно быть в 16тиричном виде. Т.е. все числа переводим в 16тиричное представление. Правильное значение можно получить например так:

    $ perl -e '@a = (16,172,16,10,16,40,100); foreach (@a) { printf("%02x", $_) } ; print "\n"'
10ac100a102864

     

     

    Про работу с включённым кэшом - Voronok проверил, падает по прежнему. Буду переделывать на rbtree.

  9. Опубликовано · Жалоба на ответ

    Исправление: http://netpatch.ru/projects/db2dhcp/db2dhcp-0.1.a.8.tar.bz2

    Нашёл и убрал багу которая иногда портила пакеты и отправляла в сеть случайные данные. Появилась после добавления "зеркалирования" опции 82 сервером обратно в relay.

     

    Больше пока вроде бы ни каких багов не находится.

     

    С кэшем кто-нибудь тестировал работу?

  10. Опубликовано · Жалоба на ответ

    статически вбить?

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

  11. Опубликовано · Жалоба на ответ

    К сожалению на этих выходных всё-таки не получилось серьёзно поработать над кодом. Но исправлена вот эта бага:

    Нашел отличие:

    offer db2dhcp 00:1b:21:86:a5:66 > ff:ff:ff:ff:ff:ff

    offer isc 00:1b:21:86:a5:66 > 00:1e:58:a7:2f:70

    Результат: http://netpatch.ru/projects/db2dhcp/db2dhcp-0.1.a.7.tar.bz2

  12. Опубликовано · Жалоба на ответ

    Если меняются только первые два октета адреса, то исходя из моего опыта есть два варианта:

    1. Шибко умный абонент который зачем-то делает это руками. Может где-то банится и пытается получить другой адрес по DHCP, например.

    2. Глючная сетевуха. Бывают такие - могут при каждой перезагрузке менять MAC адрес.

     

    Вывод - лучше всего позвонить юзеру и попробовать узнать что там у него происходит.

  13. Опубликовано · Жалоба на ответ

    Сервер работает с функцией релей 82, я как понял выдача идёт по порту коммутатора, и по маку или ip коммутатора? а по id влана он работает?, удобно было бы использовать его.
    Вы можете получить любое поле из заголовка DHCP запроса клиента и любую опцию (а так же её часть по выбранному смещению) и использовать полученные данные в SQL запросе. Это значит что да - можно по ID VLAN работать, можно по MAC адресу клиента, можно по порту, можно по ID коммутатора, можно по IP адресу релея (коммутатора). Вообще по любым данным переданым в DHCP запросе клиентом (релеем).

    Почитайте документацию, не поленитесь :) Там написано как это делается. Раздел про "Пользовательские переменные".

    Кроме того есть встроенные переменные сервера в которые входят например имя, адрес, маска интерфейса на котором получен запрос, и их тоже можно использовать в SQL выражениях.

     

    На сайте нет в примере VLAN ID потому что при подобной гибкости функционала в принципе нереально наверное привести все возможные конфигурации. Нужно просто понять принцип по которому можно строить запросы. Остальное - зависит от вашей фантази.

     

    Это понятно что здесь обговариваются проблемы в работе сервера, но хоть кто нибудь написал бы с чём его тестируете, какой Биллинг?, какоя OS ?, релей с каким железом, а ёщё бы кто нибудь конфиг привёл, чтобы хоть легче опираться при тестировании было.
    Ну мой тестовый стенд - Linux (настоящий) или FreeBSD (в виртуалке), dhcrelay от ISC, для проверки работы с опцией 82 - свитч D-Link 3526. Конфиг - см. документацию. База разумеется строго тестовая. Как и конфиг - для демонстрации основных возможностей. Поняв принцип - сами с лёгкостью напишете и конфиг и запросы.

     

    У кого-нибудь есть результаты испытаний последней версии с включённым кэшом?

    На выходных будет время заниматься устранением багов, потому лучше о них сообщить сейчас.

  14. Опубликовано · Изменено пользователем RomanCh · Жалоба на ответ

    Нашел отличие:

    offer db2dhcp 00:1b:21:86:a5:66 > ff:ff:ff:ff:ff:ff

    offer isc 00:1b:21:86:a5:66 > 00:1e:58:a7:2f:70

    Налицо косяк в обработке запроса с установленным флагом Broadcast пришедшим через relay. Хотя вроде прорабатывал ситуацию но видимо что-то недоглядел. Спасибо, поправлю.

     

    А про DHCPNAC - на самом деле очень интересно почему клиент на него не реагировал. Надо будет попробовать как-то воспроизвести эту ситуацию. У меня клиенты после получения DHCPNAK переставали использовать перезапрашивали адрес. Может опять что-то недоработано с использованием relay - без relay отправка DHCPNAK должна производиться на широковещательный адрес, возможно что и с relay броадкастит, потому ничего не получается. Не помню тестировал-ли такую ситуацию через него.

     

    UPD На счёт неправильной udp checksum от ISC - честно говоря не понимаю почему так у вас получается. По идее пакет с битой чексуммой должен быть отброшен клиентом (виндовый не проверял а dhcpcd действительно отбрасывает их). Если сервер её не рассчитал то он должен установить там 0. Ну да ладно, это к счастью чужие проблемы :)

  15. Опубликовано · Жалоба на ответ

    Мельком глянул сейчас, не удержался. По идее такое может происходить только при соблюдении условия:

                if(*requested_ip != offered_ip)
                opt_pt = set_dhcpnak(&dhcp_packet->dhcp_data, server_id);

    Т.е. получается что клиент запрашивает не то что ему предложили.

    Дамп обязательно надо посмотреть. И наверное надо внимательно мне посмотреть что в RFC по этому поводу написано.

  16. Опубликовано · Жалоба на ответ

    В случае чего деклайн придёт, а пинг это доп задержка.
    Есть RFC и этого достаточно, что бы не плодить своих "стандартов" и оставлять потомкам счастье разгребать нашу самодеятельность. Задержка конечно будет. И она предусмотрена в RFC и соответственно в клиентах.

     

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

  17. Опубликовано · Жалоба на ответ

    Если очень хочется, есть какая то очень кроссплатформенная либа которая использует под каждую ОС наилучший механизм:

    под фряху kqueue

    под винду IOCompletionPort и тп

    Сейчас не хочется.

     

    Сузить область поиска в коде.
    Не думаю что это реально сузит область поиска.

     

    Это автоматом гарантирует актуальность кеша, и снизит нагрузку на базу: 1 запрос в базу на всё время жизни лизы.
    Это какой-то недокэш ИМХО :)

     

    При некоторых конфигурациях сети это может работать не правильно или не иметь смысла, если пакеты не ходят в те сети откуда релей агенты доставляют запросы.
    Но хуже от этого не станет. В самом плохом случае - мы просто не получим ICMP echo response от уже существующего адреса и тогда клиент нам пришлёт DHCPDECLINE. В лучшем - сразу разберёмся что там что-то не так, может даже предложим другой адрес.

  18. Опубликовано · Жалоба на ответ

    Покуда взаимодействие с базой идёт через сетевое АПИ, его можно было организовать асинхронно, кабы не деффекты при проектировании этих самых апи работы с базой - достаточно чтобы они только формировали и рагребали а отправляло/получало приложение.
    Вот оно так и сделано. Тем методом которым мне это видится разумным. Не вижу резона делать иначе.
    Соотвественно заюзав kqueque или аналог можно сколько угодно запросов обрабатывать одновременно асинхронно хоть в одном потоке.
    Очень ОС зависимо, придётся под каждую ОС свой код писать, при чём не самый тривиальный. Оставлено на далёкое и счастливое коммунистическое будущее.
    У меня решение в прерле проще: все потоки делают полный цикл обработки: принимают пакет с сокета, арзбирают, лезут в базу, шлют ответ и опять снова.
    Я уже описал в чём проблемы подобного подхода.
    Работать с кучей интерфейсов можно попробовать через селект читать в потоках с кучи прибиндиных сокетов.
    Перед тем как давать такие советы - не плохо бы почитать документацию на libpcap ;) Не все ОС имеют возможность использования select'образных функций с pcap сокетами.

    Только не надо предлагать отказываться от использования libpcap. Сейчас заботы о портировании в нативный код для конкретной ОС на плечах libpcap и её разработчиков, велосипедировать не собираюсь. Да и опять же, как показывает жизненный опыт - код использующий select (и подобное) становится сложнее для понимания и отладки при весьма слабом (в пределах нескольких процентов) выигрыше по ресурсам/скорости. В данном случае скорость практически не важна и от выигранных долей миллисекунд мы ничего не получим - это не hi-load продукт предназначенный для обработки десятков килоRPS (как nginx например).

     

    Чтобы понять из за очистки он или где то ещё.
    Не очень понимаю как это может помочь. Искать багу надо в условиях максимально приближённых к реальным.

     

     

    Там бы совсем правильно сделать - это брать клиент идентифир из опций, если нет то из дхцп пакета хваддр.

    В поздних рфк написано что в клиент идентифир в опциях должно писатся DUD которое у клиента должно быть одинкого для в4 и в6 дхцп клиентов, и длинна там больше, чем у хваддр.

    Может быть. Только наверное имелось ввиду DUID. Но в принципе то что есть сейчас должно работать нормально не зависимо от версии клиента (если я ночью не налажал в коде :) ).

     

    Я думал сделатьу себя кеш по проще: время хранения 10-30 сек, идентификация по хваадр и хид
    Такой кэш будет работать только для первого 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 тоже мне на мыло.

     

  19. Опубликовано · Жалоба на ответ

    Есть такой вопрос: Допустим имеется брас(с точки зрения dhcp является релеем), на котором есть 2 пула(1.0.0.0/24 gw 1.0.0.1 и 1.0.1.0 gw 1.0.1.1), есть лупбэк браса 1.1.1.1. В силу ряда причин есть необходимость слать dhcp-пакеты с лупбэка(т.е. ip.src=1.1.1.1, но giaddr=1.0.0.1(для первого пула) и 1.0.1.1(для второго пула)). Куда db2dhcp будет возвращаться пакеты?(на giaddr или ip.src?).
    На IP адрес указанный в giaddr не зависимо от IP адреса с которого пришёл пакет. Ethernet адрес разумеется будет использован тот с которого получен пакет.

     

    Новая версия: http://netpatch.ru/projects/db2dhcp/db2dhcp-0.1.a.6.tar.bz2

    Изменения:

    1. Изменения в работе кэша - переделана функция сравнения и поиска кэшированных ответов.
    2. Устранён мелкий баг позволяющий дважды два раза добавить запрос в очередь от одного и того же клиента.
    3. Добавлено отладочного вывода при работе с кэшом. Если будут продолжаться проблемы - надеюсь поможет.

    Был замечен какой-то баг при расчёте udp checksum (valgrind ругнулся, но ничего не упало), в итоге в ответе клиенту улетело что-то неправильное и он его не смог обработать. Случается похоже крайне редко. Буду разбираться.

     

    PS Что-то плохо работает голова уже, эта версия могла получиться более бажной чем предыдущая ;) Возможно багу с подсчётом udp checksum сейчас добавил. Но проверить надо, и без кэша, и особенно - с кэшом.

     

    PPS [-Alt-] 0.0.0.0 потому что DHCPNAK. А вот почему DHCPNAK исходя из лога понять сложно, по дампу вроде всё правильно, надо в код смотреть. Выше ни каких строчек по этому поводу не было? Проблема проявляется с данным клиентом постоянно? Уже нет сил разбираться сейчас...

  20. Опубликовано · Жалоба на ответ

    Идея выбирать с базы номера опций, вместо названий пришла пока писал и дозрела до момента написания этого сообщения.

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

  21. Опубликовано · Жалоба на ответ

    в сложных случаях можно завести небольшой пул выделенных кусков памяти и так для каждого потока.

    У нгникса сильно другая ситуация, равняться на него не стоит, в данном вопросе.

    Ну в общем-то "на манер" это не равно "точно так же" ;) Имеется ввиду интерфейс аллокатора, а не внутренняя реализаци.

     

    Сделайте проще:

    каждый поток обрабатывает 1 запрос от начала и до конца, тогда можно смело использовать статический буфферы хоть со стёка потока хоть выделенные с кучи при старте потока.

    И:
    А про очередь в программе для принятых пакетов не очень понял зачем: пусть бы каждый поток читал соскета (бпф/пкап), в ядре всё равно есть и синхронизация мнопоточного чтения и очередь.

    В случае переполнения всё равно ничего не изменит.

    Если бы всё было так просто - ни кто не городил бы мультипоточного приложения ;)

    Очередь тут вовсе не для защиты от переполнения. Очередь служит для асинхронной работы потоков слушающих интерфейсы и потоков работающих с БД. Узлы в неё добавляют потоки-"слушатели" интерфейсов, а разбирают очередь - потоки работающие с БД. Сделано так потому что запросы к БД в общем случае в API разных СУБД синхронны и блокируют поток пока не будет получен результат из базы. Рассказать чем это чревато при медленной работе БД и попытках выполнять эти запросы в том же потоке что слушает интерфейс?

    В случае с очередью и отдельными потоками работающими с БД несколько залипших запросов (а такое бывает на нагруженных серверах) не заблокируют насмерть сервер, и значение это можно поставить достаточно большим. На многоядерной БД - очень выручит.

     

    Насчёт падения при включённом кеше:

    dhcp_cache_find

    попробуйте вместо cache_rdlock(); лочить на рв

    ещё можно отключить очистку или сделать её реже и заносить запись в лог перед каждой очисткой, чтобы знать если краш в ней или недалеко после неё.

    rd он на то и rd что бы можно было делать много вхождений в один участок, а не ждать когда другой поток там что-то сделает. Не надо трактором грядки пахать.

    Отключить очистку и ждать когда процесс опухнет и будет убит по перееданию памятью? Тогда можно вообще не пробовать искать утечки памяти - кэш сам по себе будет одной большой утечкой :)

    Включить реже - значит будет падать но не через несколько часов, а через несколько дней например.

    Это всё не решения а костыли, неприемлемо.

     

    Если не пойму в чём дело то лучше попробую RB Tree от MIT.

     

    cmp_nodes

    проверьте что хвадрес там из дхцп пакета а не эзернет заголовка.

    Вот это кстати очень полезное замечание объясняющее ситуацию с адресами 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;

    Потому сделано так, а не иначе.

     

    По работе с сетью:

    не понял зачем было редефайнить все структуры (заголовок эзернета, заголовок арп, заголовок ип и пр), см

    /usr/src/sys/net

    /usr/src/sys/netinet

    Например потому что в разных системах эти файлы могут называться немного по разному, как и структуры в них. Да, это можно вылечить при помощи autoconf. Только вот есть проблема - в некоторых ОС этих файлов нет вообще ;)
    по арп:

    вроде дхцп сервер должен пинг слать на адрес перед выдачей, а потом клиенту адрес выдавать, а клиент арпом проверять адрес и слать деклайн в случае чего

    Не совсем так. В RFC написано что сервер должен проверить то что адрес свободен например через ICMP echo request. Но вовсе не обязательно при помощи его. Учитывая что Windows по дефолту старается это заблокировать (как и большинство фаерволлов под неё) - проверка ARP'ом более уместна. Конечно она не реализуема при использовании relay. По возможности допишу проверку через ICMP в случае использования relay, но честно говоря это почти ничего не даст.

     

    У фряхи есть в заголовочниках макросы для правильного сбора и разбора, с учётом длинны. Можно и забить, если работать только под эзернет, только длину проверять при получении.
    Вообще не знаю есть-ли смысл писать под что-то отличное от Ethernet, много об этом думал. Хотя для приличия стоит сделать проверку. Брать проверки из FreeBSD либо откуда-то ещё не вижу смысла т.к. они абсолютно примитивны и их реализация - вопрос наличия у меня свободного времени.

     

    что касается кусков от для винды:

    корректная инициализация:

    Да, согласен, там весьма убогий кусок кода и я знаю как делать правильно. Но сделано так потому что "лишь бы работало". Последние версии в виндах вообще не пробовал собирать (PG библиотеки лень ставить), буду собирать когда доведу до ума весь задуманный функционал.
    to_cidr - считает биты, не обращает внимание что между 1 может быть 0
    Да, именно так. И об этом я тоже знаю. А вы - представляете себе _нормальные_ сетевые маски у которых может быть 0 в середине?

     

    У вас не проверяется в пришедшем пакете длинны хвлен и плен, да и вообще ничего.
    parse_dhcp_message - делает не все проверки принятого дхцп(?) пакета:...
    Верно замечено - местами вообще ничего не проверяется. Вы даже можете создать переменную в конфигурации со смещением в 100к и длинной в 1 Мб и сервер её съест, после чего вполне вероятно упадёт при обработке запроса.

    Ещё раз отсылаю вас в первое сообщение этого топика, в котором написано что это очень тестовый код. А так же в раздел "Планируемые доработки" где написано что сервер должен быть приведён в соответствие с требованиями RFC. Сейчас интересно оттестировать базовый (и самый нужный 99% потенциальных пользователей) функционал и убедиться что программа ведёт себя адекватно. Как видите - ряд явных неадекватностей уже успешно выпилен, похоже осталось только с кэшом разобраться. После чего можно будет добавить несколько запрошенных фич (благо они простые), остановить добавление функционала и доводить его до лоска и блеска штудируя в одном окне код, а в другом RFC.

     

    Спасибо за подсказку про кэш, но на будущее - предлагаю подобные беседы переносить в e-mail или какой-нибудь IM что-ли, кроме обнаружения явных и 100%ных багов. А то у нас длинный и малоинформативный для большинства читающих тред получается. Всё что найдёте - ваше :) Т.е. будет опубликовано вместе со следующей версией.

  22. Опубликовано · Жалоба на ответ

    Позволю себе вмешаться.

     

    Ivan_83, если Вы его "допилите" вам будут безмерно благодарны сотни администраторов сетей, так как нормального решения DHCP+MySQL на сег. день не существует.
    dhcpsql есть давно, и соседний топик про тоже самое только с нуля.

    Не лукавьте. Вы сами пробовали dhcpsql который "есть давно"? Помнится я пытался его когда-то запустить:

    1. Конфигурабельности - 0. Даже configure не задумано. И настроить гибко на работу с базой тоже вроде не тривиально (давно было, но хороших впечатлений не осталось).

    2. Работает только с MySQL.

    3. Сборка в FreeBSD:

    $ make
"Makefile", line 32: Need an operator
**** много таких строчек ****
make: fatal errors encountered -- cannot continue

    Так что это - не "тоже самое только с нуля".

     

    А нет потому что у всех потребности разные, и упихать в бинарник такую гибкость чтобы всем стало хорошо - сложно.
    Ну... Мы об этом уже говорили.

     

    можно написать запросы в базу что бы прилетало в ответе: код опции - содержимое, и динамически это в скрипте упаковывать, а так же перенести часть логики в базу, тогда можно будет всё конфигурить только с базы, не трогая код что бы добавить опцию или что бы кому то отдавать по 82 опции а кому то просто по маку а кому то вообще статику.
    Мне кажется, или где-то я это уже видел?.. ;)

  23. Опубликовано · Жалоба на ответ

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

     

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

  25. Опубликовано · Жалоба на ответ

    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 сообщений и общего "шума" в сети который тоже может несколько повлиять на работу. В общем - пока подожду ваших результатов.