[legioner0]

Только сейчас осознал, что у связки freeradius+dhcp в текущем виде есть серьезная проблема.

По логике freeradius нормальная сессия проходит по следующему сценарию: Access-Request -> Access-Accept -> Accounting-Start -> Accounting-Request -> Accounting-Response -> ... -> Accounting-Stop.

В патче для dhcp реализована только часть: Access-Request -> Access-Accept.

В результате в freeradius начинают скапливаться недо-сессии dhcp, постепенно поглощая все больше и больше памяти.

[kayot]

Да нет, аккаунтинг freeradius'у и нафиг не нужен для нормальной работы. А память он жрет из-за багов конкретной версии, попробуйте другие.

[Sonne]

Гоняем связку Mikrotik DHCP сервер + Freeradius.

[legioner0]

Да нет, аккаунтинг freeradius'у и нафиг не нужен для нормальной работы. А память он жрет из-за багов конкретной версии, попробуйте другие.

Странно. Попробую обновить на досуге

[_Wolf_]

Здравствуйте, коллеги...

 

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

 

Около года использовал этот сервер версии 0.1.a.10 на сегменте сети. Вцелом, все работало. Хотя на одну странность обратил внимание сразу же. Но поначалу она не мешала, а вот сейчас стала "камнем преткновения".

 

В параметрах запуска сервера присутствует указание интерфейса, на котором он якобы должен "слушать". Но! если после успешного запуска посмотреть вывод netstat -lnn , то видно, что на самом то деле "привязывается" он ко всем адресам (0.0.0.0:67)...

 

До сих пор это не мешало, но сейчас возникла потребность запустить на этом же сервере рядом еще и ISC DHCP, слушающий на другом физическом интерфейсе.

 

И вот "второй" DHCP запускаться отказался с сообщением, что адрес, к которому ему предлагается биндиться, уже занят... ну и по netstat видно, что но действительно так и понятно кем....

 

Просмотр исходников db2dhcp показал нечто странное... (повторюсь - я вообще 0 в сетевом программировании):

 

вызов bind() нашелся только в одном месте (файл dhcp_process.c)

<-cut->

struct sockaddr_in udp_sock;

bzero(&udp_sock, sizeof(udp_sock));

udp_sock.sin_family = AF_INET;

udp_sock.sin_port = htons(port);

udp_sock.sin_addr.s_addr = INADDR_ANY;

 

if( bind(dummy_socket, (const struct sockaddr *) & udp_sock, sizeof(udp_sock)) )

<-cut->

 

и тут тоже видно, что сокет привязывается к INADDR_ANY, что соответствует показаниям от netstat.

При этом интерфейсы из параметров строки запуска исправно парсятся... в таком случае не понятно - зачем, если биндимся все равно "ко всему"...

 

Пришла мысль "пофиксить это безобразие"... полез дальше...

 

приведенный фрагмент присутствует в функции:

 

static int make_dummy_socket(uint16_t port)

 

т.е. у нее параметр тоже только 1 - порт... адрес привязки не предполагается... опять же вопрос - зачем указываются интерфейсы при запуске сервера????

 

в свою очередь вызов make_dummy_socket нашелся тоже только в одном месте.. dhcp_process.c

/* Make dummy socket for suppress ICMP-port unreacheble messagess on unicast DHCP messages */

CHECK_VALUE(make_dummy_socket(config->dhcp_server_port), "Can't create dummy socket.", 0);

 

и вот тут меня очень смутил авторский комментарий относительно потенциальных проблем с юникастными DHCP-сообщениями...

 

можно ли все таки "поправить" функцию make_dummy_socket и ее вызовы на предмет использования второго параметра (конкретного адреса интерфейса)

или это чревато проблемами, о которых я не знаю и о которых не сказано в "руководствах для начинающих по программированию сокетов"?

 

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

 

В общем, я в недоумении...

Изменено 14 августа, 2013 пользователем Wolf-psk

[Ivan_83]

В параметрах запуска сервера присутствует указание интерфейса, на котором он якобы должен "слушать". Но! если после успешного запуска посмотреть вывод netstat -lnn , то видно, что на самом то деле "привязывается" он ко всем адресам (0.0.0.0:67)... До сих пор это не мешало, но сейчас возникла потребность запустить на этом же сервере рядом еще и ISC DHCP, слушающий на другом физическом интерфейсе.

Скорее всего так сделано вот почему: интерфейсы добавляются и удаляются во время работы, отслеживать и реагировать на это проблематично, поэтому биндится к 0.0.0.0 и потом фильтрует полученные пакеты по if_index.

Попробуйте DNS masq, он вроде биндится именно по интерфейсно.

[_Wolf_]

Скорее всего так сделано вот почему: интерфейсы добавляются и удаляются во время работы, отслеживать и реагировать на это проблематично, поэтому биндится к 0.0.0.0 и потом фильтрует полученные пакеты по if_index.

Попробуйте DNS masq, он вроде биндится именно по интерфейсно.

 

Извините,но!.. по самой логике проекта... так ли уж часто на серверах во время работы добавляются-удаляются сетевые интерфейсы??? И к тому же собственно в параметрах командной строки запуска программы предусмотрен параметр - имя интерфейса. А это вроде бы уже само по себе предполагает жесткую привязку к конкретному интерфейсу и исключает необходимость вообще как-то реагировать на их добавление/удаление во время работы.

 

И собственно основной мой вопрос в том, не грозит ли какими-то неожиданными эффектами если я подправлю авторскую функцию на предмет вызова bind() все таки с указанием конкретного IP-адреса интерфейса....

 

О! Только что подумалось... у автора же предполагается, что в командной строке можно указать несколько имен интерфейсов... а вызов bind() происходит кажется только 1 раз... видимо потому и биндится к ANY для простоты... а потом где-то в другом месте фильтрация как вы говорите...

 

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

 

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

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

[Ivan_83]

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

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

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

 

И к тому же собственно в параметрах командной строки запуска программы предусмотрен параметр - имя интерфейса. А это вроде бы уже само по себе предполагает жесткую привязку к конкретному интерфейсу и исключает необходимость вообще как-то реагировать на их добавление/удаление во время работы.

Такая опция означает что пакеты с указанных интерфейсов будут обработаны и не более.

 

О! Только что подумалось... у автора же предполагается, что в командной строке можно указать несколько имен интерфейсов... а вызов bind() происходит кажется только 1 раз... видимо потому и биндится к ANY для простоты... а потом где-то в другом месте фильтрация как вы говорите...

Да, проще работать с одним сокетом, когда данных там не слишком много летит.

[raveren]

Пользуется ещё кто-нибудь данным сервером?

[big-town]

Уже не первый год использую freeradius+perl+postgresql.

[kayot]

Уже не первый год использую данный сервер, все гуд :)

 

используем perl-dhcp сервер из соседней темы, ошибся

[raveren]

14 часов назад, kayot сказал:

Уже не первый год использую данный сервер, все гуд :)

Под какой ОС, БД, железом? Сколько клиентов обслуживает?

[pppoetest]

debian, mysql, i7 4-го поколения, 4к.

[kayot]

7 часов назад, raveren сказал:

Под какой ОС, БД, железом? Сколько клиентов обслуживает?

Centos, mysql, развернут прямо на БРАСах с accel-pppd. 3-4k клиентов, нагрузка от самого сервиса околонулевая.

[raveren]

Спасибо вам за ответы. Начну внедрять.

[Ivan_83]

Есть ещё вариант чисто на перле, там порог входа сильно ниже.

[pppoetest]

Хммм, а этот вариант не чисто на перле?

 

Итить, виннные парЫ ещё витают, я думал это твоя тема про перловый дхцп.

[Ivan_83]

5 часов назад, pppoetest сказал:

Хммм, а этот вариант не чисто на перле?

Посмотри первое сообщение в теме :)

У меня тут: